Как стать автором
Обновить

Комментарии 13

Спасибо за материал, весьма позновательно!
Спасибо вам за отзыв. И что уделили время.
Пользуясь случаем, упомяну ещё одно готовое решение — loghouse на базе fluentd и ClickHouse в качестве хранилища логов.
Спасибо. Тоже интересное решение.
Последний раз я пробовал ElastAlert около года назад — он был довольно глючный.

Недавно наткнулся на Alerting от OpenDistro — может быть интересно, возможно буду пробовать на следующем проекте:
opendistro.github.io/for-elasticsearch-docs/docs/alerting

Также в статье не упомянут Filebeat. Не знаю, насколько он лучше/хуже чем Fluent Bit, но в последнее время Elastic добавили туда фишек именно для работы с Kubernetes. У Filebeat есть удобные фильтры и настройки для вытягивания логов из контейнеров.

Я сам Kubernetes не использую, но использую Docker, чтобы хостить сайты разных фрэйморках на одном хосте. Использую связку FileBeat + MetricBeat + AuditBeat => Elastic => Kibana.
Всё работает, не хватает только дэшбоардов в Кибана из коробки, приходится самому немного допиливать.

Действительно, зря не упомянут filebeat. По сравнению с адовыми регэксп-трюками fluentbit-а для разделения k8s ns по индексам эластика простой yaml для такой фильтраций в filebeat — просто подарок.


Справедливости ради, какие-то дашборды из коробки заявлены. Надо только включить.

Наколько я помню, файлбит в отличии от флуента, не умеет работать в режиме сислог сервера (то есть принимать логи напрямую) и может только парсить логи самого сислога, в силу этого нагружает систему больше чем флуент (правда есть модуль cisco для файлбита, который умеет висеть на порту, но это я не рассматриваю)
Да, действительно умеет, беру свои слова обратно. В кибане очень много завязано на файлбите, те же дашборды siem. imho файлбит более «тяжелый» чем флуент, например индекс файлбита больше сотни полей, у флуент всего чуть больше десятка. Мне у флуент понравилось что он умеет сразу в s3 лить архивы.
Использовали fluentd — полностью утилизирует одно ядро, периодически перестаёт реагировать на изменения в некоторых файлах, судя по issue на github проблема встречается часто, её неоднократно фиксят, не всегда успешно.
Перешли на fluentbit, всё бы хорошо, но периодически выжирает всю доступную ему память и рестартится, по несколько раз на дню. Причём лимиты буферов стоят. Открыты issue на github, уже несколько недель как, и пока без ответа.
Loki не хранит данные в TSDB, поэтому замечание про долгое хранение неверно.

Жаль, что не упомянули ILM в части ротации логов, а ведь он хорошо помогает решить проблему баланса между производительностью/потреблением ресурсов эластика и длительностью хранения данных.
По прошествии, например, двух недель пусть индекс переходит в холодную фазу и спокойно лежит на диске, не занимая память — удобно, когда логи необходимо хранить длительное время.

Было бы интересно узнать об опыте организации логов по средам (test, stage, prod etc), а также по отдельным сервисам. Какой подход наиболее правильный?
Скинуть все в один индекс и просто фильтроваться в кибане?
Либо же делить приложения на индексы?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.