Re: Разбор ошибок в логах.
On Thu, 2017-06-22 at 10:31 +0300, Oleksandr Gavenko wrote:
> Я использую Java и логи ограничатся Java.
>
> Постоянно приходиться выяснять причину проблем через содержимое
> логов.
>
> Я встречаю сложности типа:
>
> * длиннючие строки, grep в терминале бессмысленен, через ag в Emacs
> исследую
> * в случае трейсов они многострочные - grep не работает
> * события раскиданы по группе файлов, пока копаешься в одном, фокус
> на тройку
> других теряеться (может многотабовый редактор тут поможет, я не
> уверен)
> * бессмысленная сложность из-за ротации файла
> * из-за ротации файлов теряеться история, лазить в архивах очень
> больно
> * события из разных потоков перемешаны между собою, фильтрация из-за
> многострочных трейсов by grep невозможна
> * для анализа я запаковую файлы и качаю с удаленного хостя
> * время разработчика (меня) теряеться, если будет интуитивно понятный
> Web
> доступ с кнопочками часть инцидентов решит выделенный человек,
> отвечающий за
> поддержку пользователей
>
> В целом иметь базу с возможностью автоматических запросов -
> правильно:
>
> * история становиться линейной - нет ротационных проблем, нет нужды
> стыковать
> время при рассмотрении логов из разных типов логов
> * фильтрация станет милисекундным делом, а не shell-fu подвигом на 10
> мин
> * логи под рукой, забываю про архивирование/копирование
>
> Не хватает только "смотрелки" для базы.
>
> Популярным бесплатным решением есть ELK. Пробовал.
>
> Скажу сразу что не понравилось разношерстность:
>
> * elasticsearch - Java - OK, умею тюнить
> * filebeat - Go - WTF? 50 МБ рантайма для парсера/отправителя логов?
> * Logstash - JRuby - WTF? 1 GiB хипа и хипстерский тормознутый
> рантайм?
> * Kibana - nodejs, бог с ним, это на выделенном сервере и есть
> недокументированый ключик --max-old-space-size=
>
> Парсить логи filebeat неприятно. Особенно если формат расширяем через
> MDC (см
> ниже).
>
> Logstash - дерьмо. Хипстеры, лентяи и тупые ставят. Конкурирующие
> решения не
> без проблем (Apache Flume доку не доделали, читай сорцы называется).
>
> Для добавления полезной информации (типа имени клиента, номера
> телефона,
> номера обрабатываемого документа) есть Mapped Diagnostic Context:
>
> https://logback.qos.ch/manual/mdc.html
>
> Для алертов есть еще маркеры https://www.slf4j.org/api/org/slf4j/Mark
> er.html
>
> Вот это дело хотелось бы куда-то засунуть и как-то визуально
> фильтровать.
>
> Elasticsearch+Kibana решают задачу, но есть проблемы с доставкой
> данных в
> Elasticsearch.
>
> Я хотел бы что бы база стала местом, которому я доверяю.
>
> Самым надежным местом записи есть файл.
>
> Потом парсить файлы опасно внешним процесом. filebeat имеет баг
> репорты когда
> данные пропукались из-за ротации и недоступности Elasticsearch.
>
> Да и парсить изначально структурированные данные, записаные в
> неструктурируемой форме (многострочные трейсы или расширяемые
> парамерты MDC)
> неадекватно.
>
> Есть писатели в рамках Java процеса в Elasticsearch. В случае
> даунтайма
> Elasticsearch они могут копить в буфер в памяти. Если остановить
> сервис -
> данные пропадут.
>
> В рассылке Logback мне сказали что луди только на коленках писали
> решения,
> буферизирующие на диск, пока Elasticsearch. Т.е. готового нету.
>
> Я начал "писать надежную доставлялку" в Elasticsearch стуктурированых
> данных
> логирования в Java и появились вопросы по целесообразности.
>
> ================================================================
>
> Интересно стороннее мнение по написаному выше.
>
> Как обычно решаються перечисленные сложности при анализе
> ошибок/инцидентов по
> логам?
>
> ================================================================
>
> Есть ли Web-морды для фильтрации и просмотра отлогированых событий
> (по типу
> Kibana) но для реляционных хранилищь (MariaDB/PostgreSQL/etc)?
>
> Или может есть "нетраниционные" хралища и морды к ним?
>
> X-Pack для ELK стоит в районе 10к/год, остальные "Ынтырпрайз" больше-
> меньше, не
> рациональная трата для маленькой компании.
>
> ================================================================
>
> Конечно же хочеться интеграции системы алертов с мордой, что бы по
> клику сразу
> попадал в контекст и разбирался.
>
> ================================================================
>
> Согласны ли Вы терять события в случае недоступности колектора логов
> или
> гранилища логов?
>
> Я удивлен что "писатели" в Java мире такого не делают.
>
Ну тут конечно не срача ради но, ява уг это и так понятно. Ява
девелоперам походу большую часть денег за это платят чтобы они в таких
логах рылись. Тут или смирится или перейти на что другое.
Reply to: