Кратко: Fluent Bit — это сверхлегкий агент для сбора, обработки и маршрутизации логов, метрик и трейсов. Представьте ваш сервер как огромный логистический центр. Fluent Bit — это умные конвейеры, которые бегают по всем углам, собирают коробки (логи), сортируют их, проверяют качество и отправляют точно по адресу — в базу данных, облачное хранилище или систему мониторинга. И всё это на скорости света, потребляя минимум ресурсов. Это стандарт де-факто в мире Kubernetes, который скачали более 13 миллиардов раз.

▫️Fluentd vs Fluent Bit: Старший брат и младший гений Проект Fluentd появился раньше, он мощный, на Ruby, но довольно тяжеловесный. Fluent Bit родился как его легковесная альтернатива для встраиваемых систем и краевых устройств . Написан на чистом C, его размер — около 450 КБ! . Но со временем он так окреп, что сейчас используется повсеместно, съев долю рынка у старшего брата. Fluent Bit — это снайпер, Fluentd — тяжелая артиллерия.

▫️Как устроен конвейер: От помойки до витрины Вся магия Fluent Bit строится на шести этапах : 1. Input (Вход): Где взять данные? Он умеет «слушать» файлы (как tail -f), порты, сокеты, сообщения от системджу. Буквально всё, что может родить строчку текста . 2. Parser (Разборщик): Лог пришел как бессмысленная строка "127.0.0.1 - - [01/Apr/2026:10:12:01] GET /index.html 200". Парсер превращает это в аккуратную JSON-структуру: {"remote":"127.0.0.1", "method":"GET", "status":200} . Теперь с логом можно работать как с объектом. 3. Filter (Фильтр): Самый интересный этап. Здесь можно резать данные, обогащать их, добавлять теги. Например, оставить только ошибки 500 или подставить имя сервера к каждому логу. 4. Buffer (Буфер): Сервер назначения (например, база данных) может зависнуть или тормозить. Чтобы не потерять логи, Fluent Bit складывает их в «память» или на «диск» . Это как склад временного хранения, пока грузовик не приедет. 5. Router (Маршрутизатор): Логи для людей, метрики для Графаны. Router смотрит на тег лога и решает: этот — в Elasticsearch, этот — в S3, а этот — выбросить в stdout для дебага . 6. Output (Выход): Конечная точка. Их десятки: AWS, Google Cloud, Kafka, HTTP, OpenTelemetry .

▫️Почему его обожают SRE (Инженеры надежности) · Легкость: Он жрет 450 КБ ОЗУ и процессор как капля в море. В мире микросервисов, где сотни контейнеров, каждый мегабайт на счету . · Надежность: Есть механизм Mem_Buf_Limit. Если приёмник сломался, Fluent Bit не будет бесконечно копить логи в оперативке и не упадет сам. Он упрется в лимит, притормозит сбор и переключится на диск . · Без потерь: Если вы читаете файл лога и удаляете его, Fluent Bit помнит, где остановился (через SQLite базу). Перезагрузка сервера — не страшна .

▫️Битва с длинными строками (Подводный камень) Когда вы читаете лог-файлы через плагин Tail, есть два важных параметра: · Buffer_Chunk_Size (32 КБ по умолчанию): С какой порцией мы жуем файл. · Buffer_Max_Size: Как далеко можем раздуть рот, если встретили очень длинную строку лога . Если вы пишете в лог огромный стектрейс Java на 1 МБ, а Buffer_Max_Size стоит 32 КБ — Fluent Bit подавится, выплюнет этот файл и перестанет его читать. Правило простое: Buffer_Max_Size должен быть больше самой длинной строки в логах.

▫️Актуальный статус (2026) Сейчас активно развивается версия 5.x, которая умеет работать с OpenTelemetry (OTLP) «из коробки», поддерживает HTTP/2 и имеет встроенный SQL-процессор для фильтрации данных прямо в потоке . Это больше не просто "логгер", это универсальная телеметрическая платформа для метрик, логов и трейсов. Резюмируя: Fluent Bit — это must-have для любого современного Kubernetes-кластера. Он незаметен, но именно он доставляет все ваши "крики о помощи" (логи ошибок) туда, где их увидят инженеры.

#fluentbit #observability #devops #kubernetes #logging #telemetry