Fluent Bit или OpenTelemetry Collector: богатая телеметрия требует памяти

22 октября 2026 г. в 05:00|Автор: Редакция QUASA|5 мин чтения| 1

Для узла Kubernetes, который прежде всего собирает журналы контейнеров, Fluent Bit выглядит сильнее по пропускной способности и среднему расходу ресурсов в опубликованном испытании. Если через сборщик должны проходить ещё метрики и трассировки, OpenTelemetry Collector заслуживает отдельного рассмотрения: в испытанной смешанной конфигурации до приёмника через него дошло больше данных. Назвать это победой в скорости нельзя, поскольку объёмы доставленной телеметрии различались.

При выборе между ними важны профиль нагрузки и место измерения памяти. Испытание журналов сравнивало доставку записей в Kubernetes и ресурсы контейнеров; другой опыт измерял ресурсы системы при передаче метрик от одного источника. Эти результаты помогают оценить разные задачи, но не дают общего рейтинга для любого конвейера наблюдаемости.

Границы двух испытаний

В опыте Parseable участвовали Fluent Bit 4.0.5 и OpenTelemetry Collector 0.129.1: оба получали метрики от node-exporter и отправляли их в Parseable 2.4.0. Описанная тестовая машина имела два виртуальных процессора и 2 ГиБ ОЗУ. В сводной таблице загрузка процессора системы составляла около 1,2% при каждом сборщике, а занятая память системы — около 426 МиБ с Fluent Bit и 479 МиБ с Collector. Разница в 53 МиБ относится к показателю всей тестовой системы, а не к памяти процесса сборщика.

К метрикам node-exporter исследователи перешли после опыта с OpenTelemetry Demo, который передавал журналы, метрики и трассировки. За одинаковый период через Collector до приёмника дошли 23 553 записи журналов, 389 430 записей метрик и 52 245 записей трассировок; через Fluent Bit — 4 182, 26 721 и 2 395 соответственно. Поэтому расход ресурсов в смешанном опыте нельзя сопоставлять как цену обработки одинакового объёма данных. Причину всей разницы в памяти контролируемый опыт тоже не изолирует: он показывает затраты конкретных настроек при передаче метрик, а не стоимость каждого дополнительно включённого сигнала.

Скорость и память при сборе журналов

При ротации файла журнала Pod одна запись разделяется между файлами; в испытании Fluent Bit передавал такие фрагменты раздельно.

Испытание VictoriaMetrics использовало Fluent Bit 4.2.3 и OpenTelemetry Collector 0.146.1 для чтения журналов Pod в одноузловом кластере Kubernetes. На машине с 32 виртуальными процессорами и 32 ГиБ ОЗУ каждому сборщику задали пределы в одно ядро и 1 ГиБ памяти контейнера. В сценарии со 100 Pod максимальная скорость доставки Fluent Bit достигла 31 300 записей в секунду, Collector — 20 500. При потоке около 10 000 записей в секунду среднее потребление памяти контейнера составляло 78,10 и 106,83 МиБ, а процессора — 0,260 и 0,491 ядра соответственно.

Здесь сопоставлялись готовые пути доставки: генератор писал структурированные журналы, сборщики читали файлы, разбирали записи и отправляли их проверяющему приёмнику. При этом Fluent Bit использовал JSON Lines, а Collector — протокол OpenTelemetry. Разница в скорости охватывает чтение, преобразование и отправку; приписать её одному механизму чтения файлов нельзя. Авторы не подбирали для каждого сборщика оптимальные размеры буферов и пакетов, поэтому числа прежде всего описывают испытанные конфигурации.

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

Что меняется с метриками и трассировками

В предварительном опыте с OpenTelemetry Demo через Fluent Bit дошло меньше журналов, записей метрик и трассировок, чем через OpenTelemetry Collector.

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

Fluent Bit тоже поддерживает передачу разных типов телеметрии: документация его выхода OpenTelemetry описывает отправку журналов, метрик и трассировок по OTLP через HTTP или gRPC. Возможность отправить сигнал ещё не означает, что конкретная цепочка входных модулей, фильтров и преобразований доставит все исходные данные. Поэтому при смешанной нагрузке нужно сопоставлять по отдельности дошедшие журналы, точки метрик и трассировки, а уже затем — затраты процессора и памяти на их передачу.

Именно этим объясняется смена предпочтительного кандидата между двумя профилями. В испытании только с журналами Fluent Bit быстрее доставлял записи при меньшем среднем расходе ресурсов. В предварительном смешанном опыте через Collector дошло значительно больше телеметрии, но это результат конкретной цепочки передачи, а не доказательство его универсального превосходства по производительности. Низкий расход памяти варианта, который доставил меньше данных, не показывает цену выполнения той же работы.

Корректность доставки при ротации файлов

Счётчик полученных записей не раскрывает их целостность. В испытании Kubernetes проверяющий приёмник отслеживал последовательные идентификаторы, чтобы обнаруживать пропуски. Отдельно исследователи описали неполные записи Fluent Bit при ротации файлов containerd: за час при потоке около 10 000 журналов в секунду от двух Pod они получили 34 разделённые записи. Части записи, оказавшиеся в разных файлах, передавались раздельно и могли прийти без нужных полей.

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

Выбор для узла и шлюза Kubernetes

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

Если требуется принимать и обрабатывать журналы, метрики и трассировки в общей схеме маршрутизации, устройство конвейеров Collector лучше соответствует этой задаче. Его ресурсный бюджет следует относить к реально включённым компонентам и объёму данных, дошедших до получателя. Возможна и разделённая схема: Fluent Bit собирает журналы на узлах, а Collector обрабатывает телеметрию дальше. Опубликованные числа не измеряют такую связку целиком, поэтому её итоговые затраты нельзя получить сложением результатов двух разных опытов.