Комментарии 3
К сожалению, команда Filebeat считает, что Filebeat как log shipper-инструмент должен отвечать только за доставку ивентов из файлов. А управлением этими файлами должны заниматься мы, ориентируясь на то, что сами придумаем.
Вообще, довольно логично и вполне в духе линукс-вея, а то и девопсячьей микросервисности.
Насчёт документации лично у меня схожие чувства — она местами у Эластика очень подробная, а местами совсем наоборот и даже при проектировании довольно простого случая сбора и предобработки логов пришлось полазить по форуму и обсуждениям на гитхабе, чтобы разобраться (особенно ярко выражено это для Logstash`а).
У нас файлбит никакие логи не читает, рсислог отдает логи напрямую в filebeat sysog input на порту выше 1024, что позволяет запускать файлбит не под рутом. Мониторинг ELK нод идет через meatricbeat, правда при этом перестают отображаться файлбит ноды на страничке мониторинга кластера в кибане.
Проблема произошла в момент, когда понадобился промежуточный буфер в виде файла и синхронизаций вокруг него. Я все ещё не уверен, что разработанная конфигурация устойчива к любым типам сбоев. Выглядит так, что можно было логи (на самом деле это не логи, не надо людей вводить в заблуждение, а вполне себе бизнес события) в какую нибудь систему вроде Кафки, а уже оттуда потихонечку выгребать любым способом в тот же эластик. Где-то на фоне маячит ещё вопрос - а что произойдёт, если логов не будет в эластике (скажем, по причине сбоя), а на машинах с продюсерами и файлбитов их уже нет? Не рассказаны бизнес требования на вот эту вот загрузку "логов" и требования к их хранению. Очень жаль (
Как мы логшипим в Elasticsearch и что думаем о Filebeat