На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK

Хотелось бы увидеть (возможно в следующих статьях) сравнение стоимости хранения логов в ES по сравнению с другими БД. Мне соотношение стоимости/сервиса у него кажется далеким от оптимального — тем более что Кибаны нам не хватило как в смысле UI, так и в смысле логики запросов.

Какой у вас объем логов? Я пробовал использовать ELK на версиях 2.x для логирования 7tb в сутки и столкнулся с проблемами масштабирования кластера. В результате пришлось отказаться от ELK.

Собираем логи с 10000 коммутаторов. ElasticSearch падает раз в 2 недели примерно. Еще бы GUI для настройки logstash, разобраться с elasticsearch, научиться делать оптимальные индексы через kibana или напрямую и было бы классно

… Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд...

И ни слова про легковесный filebeat, который написан на go и для которого не надо тащить jvm на каждую машину

Движок не так важен как системная работа с логами начиная от написания приложения… Например — достаточно прокинуть идентификатор запроса/события по всем микросервисам и анализ сразу становится на порядок проще… Далее — нужно выделить из текста логов типизированные события и сразу можно искать по номеру договора/порту/товару, что опять же дико упрощает поддержку… Но для всего этого нужно вести локальные контексты логгирования и лепить их к каждому сообщению. Это приводит к тому, что сервера логгирования становятся такими же толстыми как и сами сервера приложений. Но для не шибко крупных компаний (где нет серверных кластеров из десятков/сотен машин) это всё-ещё приемлемо, т.к. позволяет расти и держать продакшн под контролем.

Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.

Для безопасности в ELK есть штатный пакет X-Pack

когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем

На самом деле довольно типичная проблема, нужно настраивать ES кластер, некоторые дефолтные настройки очень консервативны. Иногда сама Кибана выдаёт тайм-аут, это легко регулируется в настроечном файле Кибаны.

Сильно поверхностно описали системы, хочу сказать пару слов за Graylog. Описанная проблема (со старыми версиями эластика), уже давно не такая острая так как они перешли на http-клиент, вместо нативного, с 2.3 (который вышел год назад) они поддерживают ES 5.х (но пока не 6.х, не знаю есть ли там что-то сильно улучшающего процессинг логов).

На предыдущей работе использовали Graylog для хранения логов с разных мест (в основном это были логи Nginx с 40+ разными полями). В день переваривалось порядка 2ТБ данных, которые обрабатывали 2 сервера Graylog и 4 дата сервера ES. На мой взгляд, Graylog был понятней и проще Kibana (сравнивалось давно, сейчас Kibana выглядит более юзер-френдли), настройка его почти минимальна, всё настраивается через веб-интерфейс. Также удобная штука была, это дисковый журнал, в момент когда ES плохо или нужно провести обслуживание, очень помогал (можно было поставить обработку на паузу).