Логирование в Kubernetes: как собирать, хранить, парсить и обрабатывать логи

[bordakovskiy]

Спасибо за материал, весьма позновательно!

[JohnRico]

Спасибо вам за отзыв. И что уделили время.

[shurup]

Пользуясь случаем, упомяну ещё одно готовое решение — loghouse на базе fluentd и ClickHouse в качестве хранилища логов.

[JohnRico]

Спасибо. Тоже интересное решение.

[SlavikF]

Последний раз я пробовал ElastAlert около года назад — он был довольно глючный.

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

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

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

[evg_krsk]

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

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

[JuriM]

Наколько я помню, файлбит в отличии от флуента, не умеет работать в режиме сислог сервера (то есть принимать логи напрямую) и может только парсить логи самого сислога, в силу этого нагружает систему больше чем флуент (правда есть модуль cisco для файлбита, который умеет висеть на порту, но это я не рассматриваю)

[SlavikF]

Я в режиме syslog не пробовал, но документация говорит, что filebeat это может:

www.elastic.co/guide/en/beats/filebeat/master/filebeat-input-syslog.html

Use the syslog input to read events over TCP, UDP, or a Unix stream socket

[JuriM]

Да, действительно умеет, беру свои слова обратно. В кибане очень много завязано на файлбите, те же дашборды siem. imho файлбит более «тяжелый» чем флуент, например индекс файлбита больше сотни полей, у флуент всего чуть больше десятка. Мне у флуент понравилось что он умеет сразу в s3 лить архивы.

[rumanzo]

Использовали fluentd — полностью утилизирует одно ядро, периодически перестаёт реагировать на изменения в некоторых файлах, судя по issue на github проблема встречается часто, её неоднократно фиксят, не всегда успешно.
Перешли на fluentbit, всё бы хорошо, но периодически выжирает всю доступную ему память и рестартится, по несколько раз на дню. Причём лимиты буферов стоят. Открыты issue на github, уже несколько недель как, и пока без ответа.

[heroOfOurTime]

Loki не хранит данные в TSDB, поэтому замечание про долгое хранение неверно.

[M0rdecay]

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

[zirexx]

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