Сравнение коллекторов логов в Kubernetes: vlagent, Vector, Fluent Bit и OpenTelemetry

Сравнение коллекторов логов в Kubernetes: vlagent, Vector, Fluent Bit и OpenTelemetry

Эффективная работа с логами (записями о событиях в системе) — это основа наблюдаемости инфраструктуры. Во время сбоев приложения генерируют аномальный объем диагностических данных. В такие моменты от коллектора логов (программы, которая считывает логи с диска, обрабатывает их и отправляет в хранилище) требуется максимальная производительность. Если коллектор не справляется, он либо потребляет слишком много ресурсов процессора и памяти, мешая основным сервисам, либо теряет важные записи, мешая найти причину аварии.

Для оценки возможностей современных инструментов команда VictoriaMetrics в марте 2026 года провела масштабное тестирование популярных коллекторов логов в среде Kubernetes. Бенчмарк сравнил как проверенные временем решения, так и новые легковесные альтернативы.

Методология и условия стресс-теста

Тестирование проводилось в одноузловом кластере Kubernetes (виртуальная машина Google Cloud n2-highcpu-32 с 32 виртуальными процессорами, 32 ГБ оперативной памяти и быстрым локальным SSD-накопителем). Локальный SSD исключил задержки дискового ввода-вывода (I/O) из списка узких мест. Нагрузка на хост не превышала 50%, что гарантировало чистоту измерений.

В бенчмарке сравнивались:

• vlagent v1.48.0 — новый легковесный агент от VictoriaMetrics для системы VictoriaLogs.
• Vector v0.53.0 — высокопроизводительный конвейер данных от Datadog.
• Fluent Bit v4.2.3 — популярный сборщик логов, используемый по умолчанию во многих Kubernetes-платформах.
• OpenTelemetry Collector v0.146.1 — универсальный открытый агент для сбора метрик, логов и трассировок.
• Grafana Alloy v1.13.2 — современный коллектор от Grafana, сменивший устаревшие Grafana Agent и Promtail.
• Filebeat v9.3.1 и Fluentd v1.19.1 — классические сборщики из экосистем Elastic и CNCF.

Для создания нагрузки в кластере было запущено 100 независимых подов (Pod — минимальная рабочая единица в Kubernetes), каждый из которых непрерывно записывал логи в собственный файл на диске. Это позволило воспроизвести верхнюю границу плотности приложений на один рабочий узел. Средний размер одной строки лога составлял 216 байт. Каждая запись содержала типичный набор полей (уровень логирования, компонент, код ответа, время выполнения) и уникальный порядковый номер (sequence_id) для проверки целостности доставки.

Каждому тестируемому агенту были заданы жесткие ограничения ресурсов: лимит процессора — 1 ядро (CPU core), лимит оперативной памяти — 1 ГБ. Предварительной оптимизации конфигурации не проводилось — все системы запускались с дефолтными настройками.

Пиковая пропускная способность: разрыв увеличивается

Основным показателем эффективности сборщиков является количество строк логов, которые они способны обработать и отправить в секунду в условиях дефицита процессора. В сценарии со 100 подами-генераторами результаты распределились следующим образом:

1. vlagent продемонстрировал пиковую пропускную способность, достигнув 143 000 строк в секунду. Агент полностью утилизировал выделенное процессорное ядро, не выходя за рамки ограничений по памяти.
2. Fluent Bit занял второе место с результатом 31 300 строк в секунду, что оказалось в 4,5 раза медленнее лидера.
3. Vector обработал 25 000 строк в секунду (в 5,7 раза медленнее).
4. OpenTelemetry Collector зафиксировал производительность на уровне 20 500 строк в секунду (в 6,9 раза медленнее).
5. Grafana Alloy показал 15 700 строк в секунду (в 9,1 раза медленнее).
6. Filebeat (5250) и Fluentd (5100) оказались аутсайдерами теста, отстав от лидера почти в 28 раз.

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

Эффективность использования ресурсов при стабильной нагрузке

Помимо работы на пике возможностей, критически важно оценивать потребление ресурсов в штатном режиме, когда объем логов стабилен и относительно невелик. Команда VictoriaMetrics замерила утилизацию CPU и оперативной памяти при фиксированном потоке в 10 000 строк в секунду. В этих условиях все основные коллекторы работали стабильно и без потерь.

Потребление процессора:

• vlagent: 0.062 ядра CPU.
• Fluent Bit: 0.260 ядра CPU (в 4.2 раза больше vlagent).
• Vector: 0.412 ядра CPU (в 6.6 раза больше vlagent).
• OpenTelemetry Collector: 0.491 ядра CPU (в 7.9 раза больше vlagent).
• Grafana Alloy: 0.578 ядра CPU (в 9.3 раза больше vlagent).
• Promtail: 0.655 ядра CPU (в 10.5 раз больше vlagent).
• Примечание: Filebeat и Fluentd были исключены, так как теряли логи еще до достижения этой отметки.

Потребление оперативной памяти (RAM) при той же нагрузке:

• vlagent: 27.91 МБ.
• Promtail: 63.00 МБ.
• Grafana Alloy: 66.44 МБ.
• Fluent Bit: 78.10 МБ.
• OpenTelemetry Collector: 106.83 МБ.
• Vector: 153.50 МБ.

В масштабах крупного кластера, где коллектор логов запускается в виде DaemonSet (по одной копии на каждом физическом сервере), эта разница превращается в прямые финансовые затраты. Выбор экономичного агента позволяет высвободить вычислительные ресурсы под бизнес-логику приложений. Кроме того, под максимальной нагрузкой Fluent Bit и Filebeat превысили лимит оперативной памяти в 1 ГБ, из-за чего были принудительно завершены системой Kubernetes (OOM-kill), что привело к потере логов.

Надежность сбора логов и проблемы ротации файлов

Скорость обработки — не единственный критерий качества. Гораздо важнее гарантия доставки каждого лога в неизменном виде. Одним из сложнейших сценариев для коллектора является ротация лог-файлов (когда текущий файл закрывается при достижении лимита размера, и создается новый, а сборщик должен корректно переключиться и дочитать остатки).

Бенчмарк выявил несколько серьезных проблем с надежностью:

1. Проблема разорванных строк (split records). При высокой интенсивности записи Docker или containerd могут записать одну строку лога частично в старый файл, а частично — в новый. Коллектор обязан склеить эти части перед отправкой. Fluent Bit и Vector проигнорировали это правило и отправили фрагменты как две отдельные записи. В результате в систему пришел невалидный JSON без ключевых полей (например, без sequence_id). За один час теста Fluent Bit отправил 34 разорванные строки, а Vector — 2. Это ломает логику автоматических алертов и парсинга на стороне бэкенда.
2. Утечки файловых дескрипторов у Vector. При накоплении очереди на отправку Vector продолжал держать открытыми файлы логов, которые уже были ротированы и удалены из файловой системы. Операционная система не может физически освободить место на диске, пока файл удерживается открытым процессом. Это создает риск переполнения диска хоста. Если Vector перезагрузить до того, как он обработает очередь, эти данные будут безвозвратно потеряны.
3. Потеря метаданных при удалении подов. Если под Kubernetes завершает работу и удаляется в тот момент, когда у Vector есть отставание по обработке его логов, Vector отправляет оставшиеся записи без добавления метаданных (имен подов, пространств имен, лейблов). downstream-фильтры не могут классифицировать такие логи, и они превращаются в «бесполезный шум».

Практические выводы для инженеров

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

• Учитывайте особенности vlagent. Несмотря на выдающуюся скорость и низкое потребление ресурсов, vlagent на текущий момент (версия v1.48.0) имеет важные функциональные ограничения. Он не поддерживает склеивание многострочных логов (например, стеков ошибок Java Stack Trace) и парсинг кастомных форматов (таких как access-логи Nginx) на стороне агента. Эти функции планируется реализовать позже с использованием языка LogsQL. Если ваша система критически зависит от этих возможностей, сейчас безопаснее остаться на Vector или Fluent Bit.
• Контролируйте настройки ротации. Для предотвращения потери логов при использовании Vector рекомендуется уменьшить интервал сканирования каталогов с дефолтных 60 секунд до 10 секунд (параметр glob_minimum_cooldown_ms) и аккуратно настроить параметр rotate_wait_secs, чтобы освобождать файловые дескрипторы своевременно, соглашаясь на контролируемый риск потери недочитанных логов в пользу стабильности дисковой подсистемы.
• Проводите локальное тестирование. Любые вендорские бенчмарки (а данное исследование опубликовано создателями VictoriaMetrics) отражают специфический профиль нагрузки. Перед внедрением нового агента в продакшен разверните его в тестовой среде, сымитируйте отказ сети хранения данных, принудительно удаляйте поды под нагрузкой и проверяйте сохранность метаданных и корректность склейки логов.