Настройка централизованного логирования через Fluentd / Fluent Bit

Почему Fluentd теряет логи при пиковой нагрузке

Пиковый трафик ломает сбор логов не в момент записи, а в момент отправки. Агент Fluentd на узле принимает события от приложений быстрее, чем успевает отдать их в хранилище, и складывает их в буфер — сначала в память, потом на диск. Когда отведённое под очередь место заканчивается, срабатывает политика переполнения: агент начинает отбрасывать самые старые блоки. Именно поэтому логи пропадают ровно в тот момент, когда идёт разбор инцидента и нужны они больше всего.

Узкое место сбора редко бывает одно. Разные форматы логов обрабатываются разными фильтрами: структурированный JSON разбирается быстро, а многострочные трассировки и нерегулярный поток от веб-сервера требуют регулярных выражений и склейки по таймауту — на каждой строке это стоит процессорного времени. Чем больше строк в единицу времени, тем медленнее фильтры и тем быстрее растёт очередь.

На разборе инцидента картина повторяется: очередь на узле выросла до предела за считаные минуты, интервал сброса буфера не успевает её разгружать, дисковое хранилище очереди переполнено. Часть событий дошла до центрального хранилища, часть осталась в блоках, которые уже удалены при ротации. Восстановить хронологию по обрезанным данным нельзя — пропала именно граница сбоя.

Разбираем, как это закрывается: считаем реальную пропускную способность агента на узле, задаём буферизацию с запасом по диску, выбираем политику переполнения, которая сохраняет свежие события, и приводим разные форматы логов к единой схеме до отправки.

Что даёт централизованный сбор логов и где выигрыш

Когда логи лежат на каждом узле отдельно, разбор инцидента начинается с обхода машин, а не с гипотезы. Инженер сверяет хосты, часовые пояса и версии, теряет контекст между контейнерами одного запроса — время поиска по логам растёт вместе с числом узлов, а стоимость простоя считают, пока диагноза ещё нет.

Централизованное логирование снимает этот этап. Агент Fluentd собирает вывод контейнеров и системные журналы, склеивает многострочные сообщения в одно событие, добавляет метаданные — узел, сервис, окружение — и раскладывает потоки по тегам, чтобы шум приложения не смешивался с журналом ядра. Буфер на диске переживает недоступность приёмника: при обрыве связи агент притормаживает чтение и доставляет накопленное позже, а не теряет записи.

Дальше выигрыш становится измеримым. Поиск по логам превращается в один запрос по метаданным, разбор инцидента — в просмотр цепочки событий одного запроса по идентификатору корреляции. Доля восстановленных событий растёт: ничего не срезается на этапе сбора, поэтому картину собирают даже по сбоям, которые раньше списывали на «нет данных».

Меняется и класс отказов. Уходит сценарий «сбой заметили, причину не нашли» — остаются записи с точным временем, узлом и версией сборки. Срок хранения задаётся политикой по тегам: объёмные технические сообщения уходят в холодное хранилище, а ошибки и события доступа остаются под рукой дольше.

Режимы работы Fluentd: агент на узле, служба, шлюз

Fluentd — это не только агент на каждом узле. Один и тот же сборщик разворачивают в трёх режимах, и выбор определяет, где копится буфер, сколько ресурсов уходит у приложения и что произойдёт при обрыве канала до приёмника. Ниже — варианты, между которыми реально выбирают.

Режим буферизации подбирается под требования к отказоустойчивости сбора. Буфер в памяти даёт максимальную скорость, но теряется при перезапуске процесса; буфер на диске с ограничением по размеру и числу чанков переживает падение агента и разрыв связи с приёмником. Схема «лёгкий агент на узле плюс шлюз сбора с дисковым буфером» разгружает приложения: сеть и повторные отправки берёт на себя шлюз, а не сам сервис.

Этапы внедрения централизованного логирования

Порядок работ строится так, чтобы каждый шаг опирался на данные предыдущего. Начинаем не с установки агентов, а с инвентаризации: пока неизвестно, сколько источников и в каких они форматах, маршрутизация превращается в угадывание и всплывает потерянными записями при первом же разборе инцидента.

1. Инвентаризация источников. Перечень сервисов, файлов, системных журналов и контейнеров: формат записи (структурированный JSON, неструктурированный текст, многострочные трассировки), скорость роста, владелец. На выходе — таблица с очередностью подключения: кого берём в первой волне, кого осознанно откладываем.

2. Схема потоков. Маршрут «агент на узле → агрегатор → хранилище», с буферизацией на диске и заданным поведением при недоступности приёмника. Теги и метки (сервис, окружение, узел) фиксируем заранее — по ним потом строятся выборки и алерты.

3. Настройка сбора и разбора. Конфигурации Fluentd — парсеры, фильтры, размеры буферов, повторы при ошибках — держим в репозитории и меняем через ревью, а не правкой на сервере.

4. Пилотная группа. Три-пять сервисов с разными форматами логов. Проверяем потери при обрыве сети, нагрузку от агента на узел и корректность разбора многострочных записей.

5. Проверка полноты логов. Сверяем число записей на источнике и в хранилище, ищем пропуски на пиках нагрузки. Критерий приёмки — расхождение в заданных пределах, а не «вроде всё приходит».

6. Передача в эксплуатацию. Инструкции по типовым сбоям, оповещения на отставание доставки и переполнение буфера, регламент подключения нового источника — чтобы сервисы добавлялись без нашего участия.

Что заказчик получает: конфигурации Fluentd и регламенты

Работа заканчивается не запущенным сервисом, а комплектом артефактов, который ваша команда сопровождает своими силами. Каждый пункт передаём в виде, пригодном для правок без нас: конфигурации лежат в репозитории, решения по маршрутизации описаны словами, а не только в голове инженера.

• Конфигурации сбора — описания источников, фильтров разбора и маршрутов вывода единым набором файлов в репозитории. Изменения проходят проверку на тестовом контуре: сборщик поднимается с новым набором, прогоняет эталонные события и только потом идёт в рабочий контур.
• Схемы потоков — откуда и куда идёт каждый тип событий, где стоит буфер на диск, где события обогащаются, а где отбрасываются как дубли. Схема позволяет за минуту понять, почему запись из конкретного сервиса не дошла до хранилища.
• Политики доступа — какие команды видят какие наборы логов, какие поля маскируются до записи, как выдаются и отзываются токены сборщиков. Отдельно фиксируем, что делать при увольнении сотрудника или смене подрядчика.
• Правила хранения и очистки — сколько живут события в быстром доступе, что уходит в архив, по какому возрасту удаляется остальное. Хранилище перестаёт расти бесконтрольно, при этом окно для разбора инцидента остаётся достаточным.
• Регламент дежурства — кому и в какой канал уходит сигнал при отказе сборщика или потере потока, за какое время нужна реакция, что считается инцидентом, а что штатной деградацией.
• Метрики самого конвейера — задержка доставки, заполнение буфера, доля отброшенных записей. По ним видно проблему до того, как о ней сообщит разработка.
• Документация — пошаговые инструкции «как подключить новый источник» и «как разобрать типовые отказы», с примерами готовых блоков конфигурации.

Приёмку проводим на живом сценарии: гасим один узел сбора и проверяем, что события не теряются, а после восстановления доезжают целиком.

Кейс: разбор инцидента по логам вместо часов поиска

До: логи были, а картины инцидента не было

Сервис работал на десятке узлов, и каждый писал в локальный файл с ротацией по размеру. При сбое инженер шёл по машинам через терминал, сопоставлял отметки времени вручную — и всё равно не видел цепочку целиком: часть событий терялась при ротации, часть оставалась на узле, который к моменту разбора уже вывели из балансировки. Полнота логов держалась около 60%, поиск нужного события занимал 40-60 минут, восстановление сервиса растягивалось на часы.

Что изменили

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

После: инцидент разбирается по одному запросу

Полнота логов выросла до 99%: потери на ротации и обрывах связи ушли, а пропуски отправки агент досылает из буфера после восстановления канала. Поиск события занимает 2-3 минуты вместо часа, время восстановления сервиса сократилось примерно вчетверо — дежурный видит последовательность от первого сбоя до каскада, а не собирает её по фрагментам. Нагрузка на узлы при этом снизилась: один рабочий поток с настраиваемым лимитом памяти оказался легче прежнего тяжёлого сборщика.

На том же контуре позже подключили метрики и трассировки — точки отказа теперь сопоставляются с логами по общим метаданным, и разбор не начинается заново для каждого нового инструмента.

Чем Fluentd отличается от Fluent Bit и что выбрать

Это не два конкурирующих продукта, а два уровня одной схемы сбора. Fluent Bit ставят на каждый узел как лёгкий агент: он читает stdout контейнеров и файлы журналов, добавляет метаданные (имя пода, namespace, метки) и отправляет дальше. Fluentd занимает место центрального агрегатора, где нужна полноценная маршрутизация, фильтрация и раздача в несколько приёмников.

Разница видна в потреблении ресурсов. Fluent Bit — один статически собранный исполняемый файл без внешних зависимостей, поэтому десятки узлов не дают заметной нагрузки и агент не конкурирует с рабочими сервисами за память. Fluentd — среда с большим набором плагинов и гибкими буферами на диске, он требовательнее и разворачивается там, где ресурсов заведомо достаточно.

Практический критерий простой. Если задача — доставить логи с узла без потерь и без роста потребления, хватает Fluent Bit с настройкой дискового буфера и повторов при недоступности приёмника. Если появляются ветвление потоков по меткам, маскирование полей, дедупликация, склейка многострочных записей и раздача в несколько систем одновременно — это работа для Fluentd.

Смешанная схема закрывает оба требования: на узлах остаётся дешёвый агент, а вся логика переезжает на слой агрегации. Тогда изменение маршрутизации не требует перезапуска агентов на каждой машине, а буферы на двух уровнях сглаживают недоступность хранилища. Дальше разбираем, как эта схема настраивается и какие параметры буферов определяют, потеряются ли записи при перезапуске узла.

Технические сомнения перед внедрением логирования

На этапе оценки почти всегда всплывает один и тот же набор сомнений: приложения пишут логи по-разному, в строках оказываются персональные данные, неясно, сколько всё это хранить и не начнёт ли сбор тормозить рабочие сервисы. Ниже — как мы закрываем каждое из них конфигурацией, а не обещаниями.

Как быть с персональными данными в логах?

Маскирование выполняется на стороне агента, до отправки: фильтры вырезают значения по именам полей и шаблонам, всё остальное отсекается по белому списку. В хранилище попадает уже обезличенный поток, поэтому срок хранения перестаёт зависеть от требований к защите персональных данных.

Сколько хранить и не вырастет ли реестр бесконечно?

Политика задаётся по классу данных: свежие логи лежат в быстром хранилище, затем автоматически уезжают в дешёвый архив и удаляются по расписанию. Для прикладных логов и журналов доступа сроки разные — реестр не растёт бесконечно, при этом окно для разбора инцидента остаётся достаточным.

Не просадит ли логирование рабочие сервисы и как запускать поэтапно?

Агент работает отдельным процессом, пишет буфер на диск и ограничен по процессору и памяти. Если приёмник недоступен, буфер переживает перезапуск, а приложение продолжает отвечать — сбор логов не попадает в критический путь запроса. Стартуем с пилотного контура: сверяем полноту и потери на одной группе сервисов, потом раскатываем на остальные, с возможностью откатить конфигурацию на агенте.

Обсудим вашу задачу по логированию

Чтобы оценка была предметной, а не «на глаз», достаточно нескольких вводных: какие источники пишут логи (приложения, системные службы, контейнеры, балансировщики), примеры реальных записей за час-два и текущий путь этих записей — куда они уходят и в каком объёме. По строкам сразу видно, где нужен разбор и обогащение полей, а где достаточно доставки, и это меняет и конфигурацию, и сроки.

Дальше разбираем схему целиком: агенты на узлах или набор демонов в кластере, буферизация на диск при недоступности приёмника, метки и маршрутизация в несколько хранилищ, ограничение роста индексов. После разбора возвращаемся с планом, оценкой сроков и составом работ — без абстрактных формулировок.

Что входит в разбор и что вы получаете на выходе:

• Перечень источников и разметку: какие поля извлекаем из строк, что оставляем в исходном виде.
• Схему доставки: где стоят агенты, как настроены очереди, что происходит при обрыве связи с приёмником.
• План внедрения по этапам: пилот на одном контуре, проверка полноты и потерь, затем раскатка на остальные.
• Оценку сроков и трудозатрат по каждому этапу с точками контроля и признаками готовности.
• Конфигурации Fluentd, схему потоков и правила хранения — с расчётом, как быстро растёт объём.
• Регламент поддержки после запуска: реакция на сбои доставки, обновление конфигураций, дежурство.
• Инструкции для вашей команды: как добавить новый источник и не сломать разбор существующих.

Опишите задачу в том объёме, который есть на руках, — вернёмся с планом внедрения, оценкой сроков и понятной зоной ответственности после запуска.