Разбор ошибок в логах.
Я использую 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/Marker.html
Вот это дело хотелось бы куда-то засунуть и как-то визуально фильтровать.
Elasticsearch+Kibana решают задачу, но есть проблемы с доставкой данных в
Elasticsearch.
Я хотел бы что бы база стала местом, которому я доверяю.
Самым надежным местом записи есть файл.
Потом парсить файлы опасно внешним процесом. filebeat имеет баг репорты когда
данные пропукались из-за ротации и недоступности Elasticsearch.
Да и парсить изначально структурированные данные, записаные в
неструктурируемой форме (многострочные трейсы или расширяемые парамерты MDC)
неадекватно.
Есть писатели в рамках Java процеса в Elasticsearch. В случае даунтайма
Elasticsearch они могут копить в буфер в памяти. Если остановить сервис -
данные пропадут.
В рассылке Logback мне сказали что луди только на коленках писали решения,
буферизирующие на диск, пока Elasticsearch. Т.е. готового нету.
Я начал "писать надежную доставлялку" в Elasticsearch стуктурированых данных
логирования в Java и появились вопросы по целесообразности.
================================================================
Интересно стороннее мнение по написаному выше.
Как обычно решаються перечисленные сложности при анализе ошибок/инцидентов по
логам?
================================================================
Есть ли Web-морды для фильтрации и просмотра отлогированых событий (по типу
Kibana) но для реляционных хранилищь (MariaDB/PostgreSQL/etc)?
Или может есть "нетраниционные" хралища и морды к ним?
X-Pack для ELK стоит в районе 10к/год, остальные "Ынтырпрайз" больше-меньше, не
рациональная трата для маленькой компании.
================================================================
Конечно же хочеться интеграции системы алертов с мордой, что бы по клику сразу
попадал в контекст и разбирался.
================================================================
Согласны ли Вы терять события в случае недоступности колектора логов или
гранилища логов?
Я удивлен что "писатели" в Java мире такого не делают.
--
http://defun.work/
Reply to: