Comments 15
Хотелось бы увидеть (возможно в следующих статьях) сравнение стоимости хранения логов в ES по сравнению с другими БД. Мне соотношение стоимости/сервиса у него кажется далеким от оптимального — тем более что Кибаны нам не хватило как в смысле UI, так и в смысле логики запросов.
+1
Интересно было бы узнать, для чего вам не хватило кибаны?
0
Какой у вас объем логов? Я пробовал использовать ELK на версиях 2.x для логирования 7tb в сутки и столкнулся с проблемами масштабирования кластера. В результате пришлось отказаться от ELK.
0
Собираем логи с 10000 коммутаторов. ElasticSearch падает раз в 2 недели примерно. Еще бы GUI для настройки logstash, разобраться с elasticsearch, научиться делать оптимальные индексы через kibana или напрямую и было бы классно
+1
А можете рассказать о структуре ES? Строили для заказчика ещё на 2.4 версии хранилище для логов и у них, насколько мне известно, всё ещё успешно используется. Сталкивался с проблемой, что нужно отделять HTTP и Мастер/Дата-ноду, в противном случае под нагрузкой ES стабильно падал. Достаточно было просто два сервиса на разных портах поднять и проблема уходила.
0
… Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд...
И ни слова про легковесный filebeat, который написан на go и для которого не надо тащить jvm на каждую машину
+1
Движок не так важен как системная работа с логами начиная от написания приложения… Например — достаточно прокинуть идентификатор запроса/события по всем микросервисам и анализ сразу становится на порядок проще… Далее — нужно выделить из текста логов типизированные события и сразу можно искать по номеру договора/порту/товару, что опять же дико упрощает поддержку… Но для всего этого нужно вести локальные контексты логгирования и лепить их к каждому сообщению. Это приводит к тому, что сервера логгирования становятся такими же толстыми как и сами сервера приложений. Но для не шибко крупных компаний (где нет серверных кластеров из десятков/сотен машин) это всё-ещё приемлемо, т.к. позволяет расти и держать продакшн под контролем.
0
когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем
На самом деле довольно типичная проблема, нужно настраивать ES кластер, некоторые дефолтные настройки очень консервативны. Иногда сама Кибана выдаёт тайм-аут, это легко регулируется в настроечном файле Кибаны.
0
Сильно поверхностно описали системы, хочу сказать пару слов за Graylog. Описанная проблема (со старыми версиями эластика), уже давно не такая острая так как они перешли на http-клиент, вместо нативного, с 2.3 (который вышел год назад) они поддерживают ES 5.х (но пока не 6.х, не знаю есть ли там что-то сильно улучшающего процессинг логов).
На предыдущей работе использовали Graylog для хранения логов с разных мест (в основном это были логи Nginx с 40+ разными полями). В день переваривалось порядка 2ТБ данных, которые обрабатывали 2 сервера Graylog и 4 дата сервера ES. На мой взгляд, Graylog был понятней и проще Kibana (сравнивалось давно, сейчас Kibana выглядит более юзер-френдли), настройка его почти минимальна, всё настраивается через веб-интерфейс. Также удобная штука была, это дисковый журнал, в момент когда ES плохо или нужно провести обслуживание, очень помогал (можно было поставить обработку на паузу).
На предыдущей работе использовали Graylog для хранения логов с разных мест (в основном это были логи Nginx с 40+ разными полями). В день переваривалось порядка 2ТБ данных, которые обрабатывали 2 сервера Graylog и 4 дата сервера ES. На мой взгляд, Graylog был понятней и проще Kibana (сравнивалось давно, сейчас Kibana выглядит более юзер-френдли), настройка его почти минимальна, всё настраивается через веб-интерфейс. Также удобная штука была, это дисковый журнал, в момент когда ES плохо или нужно провести обслуживание, очень помогал (можно было поставить обработку на паузу).
0
Sign up to leave a comment.
На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK