Comments 25
filebeat.autodiscover:
providers:
- type: docker
templates:
- condition:
contains:
docker.container.name: "vhost-"
config:
- module: nginx
access:
input:
type: container
paths:
- /var/lib/docker/containers/${data.docker.container.id}/*.log
stream: stdout
error:
input:
type: container
paths:
- /var/lib/docker/containers/${data.docker.container.id}/*.log
stream: stderr
В связи с этим возникает вопрос: в чём преимущество Fluent-bit в данном случае?
Ещё одна проблема вот в этой строчке:
access_log /var/log/nginx/access.log
Эта строчка означает, что логи nginx пишутся в файл, который внутри контейнера. То есть в логи самого контейнера ничего не поподёт, и fluentD никаких логов не получит.
Правильный конфиг nginx в докере — писать в stdout, который уходит в логи контейнера:
access_log /dev/stdout
В связи с этим возникает вопрос: в чём преимущество Fluent-bit в данном случае?
Nginx взят в качестве примера, может быть не совсем удачного и сбивающего с толку.
На мой взгляд у filebeat особых преимуществ перед Fluent-bit не дает)
Эта строчка означает, что логи nginx пишутся в файл, который внутри контейнера. То есть в логи самого контейнера ничего не поподёт, и fluentD никаких логов не получит.
Пройдите туториал, все работает как надо)
Спасибо за обратную связь)
возьмите fluentd.
Конечно, filebeat больше аналог fluent-bit, а флюентди скорее аналог логстэша...
здесь вопрос в том на какой стороне вы хотите делать процессинг. Те же Filebeat подсаживают специальную конфигурацию в ингест ноду эластика (если это вообще возможно, а не стоит кафка посередине) и поэтому зачастую в конфигурации Filebeat + ES парсингом занимается ES :-o :-o :-o
А если уж говорить серьезно, то можно взять рсислог — беспроблемное решение из 00-х. Он уже давно стандартный лог шиппер во многих дистрибутивах и есть готовый солюшен для циски
https://www.rsyslog.com/normalizing-cisco-asa-messages/
тема модулей у filebeat всего не решает.
я вот никак не могу решить проблему "фильтрации" сбора логов от определённых контейнеров - по-прежнему забираю логи от всех контейнеров на хосте и уже в фильтрами grok и в kibana выискиваю нужные.
поднял вопрос вот здесь- https://discuss.elastic.co/t/filtering-setup-for-docker-containers-not-working/295573 , но пока не знаю куда дальше двигаться. Очень смутно представляю, может ли это fluent*.
по пути /var/log/nginx/access.log находится симлинк в /dev/stdout
Предлагаю обратить внимание на https://vector.dev/
— Утечка памяти (спокойно сожрало > 30G RAM)
— Переподключение к OUTPUT может повиснуть, что к forward, что к эластику
— Иногда в момент проблемы с переподключением его можно остановить лишь при помощи kill -9
На данный момент у fluent-bit очень много проблем, достаточно глянуть на количество issue в github.
Мне не нравится использование кастомного log driver. Поясню. Есть всего два драйвера, которые не нарушают работу docker logs команды, которая удобна для отладки и локальной разработки — это json-file и journald. Первый — «по умолчанию». Второй мне нравится больше, но интеграция с ним флюента будет сложнее. Касательно настроек для filebeat & json-file SlavikF уже подсказал
Что мне ещё не понравилось — какой-то странный конфиг nginx — зачем мы пишем логи в файл, а потом в stdout? А потом мучаемся, чтобы отделить реальные сообщения об ошибках от логов доступа? Зачем зря процессор грузить? Тут не хватает двух замечаний:
- В дефолтном nginx с докерхаба сделано перенаправление файла лога в stdout/stderr, но это «магия» и нельзя уповать на то, что это будет так в любом приложении и в любом образе
- А чего сразу потоки из приложения сразу не категоризировать сразу?
С вашими замечаниями согласен, мне наверное стоило в начале написать, что этот туториал о том как можно работать с логами с помощью fluent-bit, а не реальный, готовый для продакшена парсинг логов Nginx)
Поясню почему:
Использование парсеров данных в контейнере — это ужас ужасный. REGEX — одна из самых дорогих операций в програмировании, т.е. проц будет жрать, как не в себя. А теперь представьте сайт, или микросервис, у которого вдруг пошёл спайк логов, а такое бывает. Мало того, что он сам перегружает проц, так ещё и флуент на себя тянет… результат- упал контейнерь и логи ушли, т.к. были внутри контейнера. Далее, для более ли менее приличного колличества контейнеров, пойдёт нереальный перегруз по соединениям с Эластиком при малом размере балка. Эластик это очень не любит. Как потенциальный результат — входная очередь в Эластике переполнилась и агенты получают эксепшены. Я не помню есть ли там апарат повторной пересылки, но даже если есть, то это только ещё больше забьёт очередь, а если нет, то потеряете данные. Кроме того, если я правильно понял, у Флюента нет внутреннего лод балансера на посылку в Эластик, т.е. там можно определить только один нод, а это значит, что если нод упал, данных нет. Ну и по мелочам, типа поддержки ECS, увеличенного трафика за счёт полей JSONa и.т.д.
У меня недавно был клиент, который хотел у себя такое имплементировать… слава б-гу отговорил:) В общем категорически не рекомендую.
Если уж вы хотите использовать Флюент (хотя я всё ещё предпочитаю Файлбит), то логи стоит писать на диск, который при падении контейнера не умрёт. Посылать их в том формате, в котором они есть на отдельный контейнер(или несколько) с парсером, а он уже будет кидать их в Эластик. Я обычно ставлю Файлбиты, посылающие на Логсташ и уже он парсит и кидает в Эластик.
И да, совсем не вазноь чьи логи… скажу больше если это кастомнэ логи чьейто аппликации, то писать под них реджексы это тот ещё кайф, уж лучьше гроки:)
Спасибо, нашел важные ответы на свои вопросы в данной статье!
Парсинг логов при помощи Fluent-bit