Сравнение Filebeat, Promtail, Fluent Bit: настройка log shipping

Как выбрать и настроить агент сбора логов: Filebeat, Promtail, Fluent Bit

Агент сбора логов — первое и самое ответственное звено в logging pipeline. Именно здесь чаще всего теряются события: Filebeat пропустил ротацию файла — недосчитались 2000 строк. Promtail упал на ноде — потерял позицию. Fluent Bit съел 100% CPU на парсинге multiline Java stacktrace. По нашим данным, до 5% логов теряются из-за неверной конфигурации агента. Правильная настройка — не «поставил и забыл», а регулярный аудит и адаптация под инфраструктуру.

Мы — DevOps-инженеры с опытом работы в продакшене более 10 лет и более 50 успешных проектов по логированию. Один из кейсов: настройка Fluent Bit для кластера из 50 нод позволила снизить потребление ресурсов на 40% и сократить затраты на хранение логов вдвое — экономия $3000 в месяц.

Какой агент выбрать для вашей инфраструктуры?

Все три инструмента делают одно и то же — читают логи и отправляют в систему хранения. Разница в ресурсах, производительности и интеграциях. Сводная таблица:

Filebeat — выбор для Elastic Stack. У него модули (nginx, mysql) с готовыми парсерами. Promtail — оптимален для Loki. Он автоматически обогащает логи метаданными pod'ов. Fluent Bit — самый лёгкий, в 20 раз легче Filebeat по памяти. Идеален для edge, IoT и Kubernetes с ограниченными ресурсами.

Настройка Filebeat с учётом edge cases

Базовая конфигурация проста, но дьявол в деталях — особенно multiline и обработка ротации:

# /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/app/*.log
    multiline.type: pattern
    multiline.pattern: '^\d{4}-\d{2}-\d{2}'
    multiline.negate: true
    multiline.match: after
    multiline.max_lines: 500
    multiline.timeout: 5s
    fields:
      app: myapp
      env: production
    fields_under_root: true
    scan_frequency: 10s
    close_inactive: 5m
    ignore_older: 24h
  - type: container
    paths:
      - /var/lib/docker/containers/*/*.log
    processors:
      - add_kubernetes_metadata:
          host: ${NODE_NAME}
          matchers:
            - logs_path:
                logs_path: "/var/lib/docker/containers/"
    processors:
      - drop_fields:
          fields: ["agent", "ecs", "host.os"]
          ignore_missing: true
output.logstash:
  hosts: ["logstash:5044"]
  loadbalance: true
  ttl: 30s
  compression_level: 3
queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 5s
logging.level: warning
logging.to_files: true
logging.files:
  path: /var/log/filebeat
  name: filebeat
  keepfiles: 3

multiline — самая частая причина битых логов. Java stacktrace занимает десятки строк, и без правильного pattern каждая строка улетит как отдельное событие. Паттерн ^\d{4}-\d{2}-\d{2} означает: новое событие начинается со строки с датой, всё остальное — продолжение предыдущего. close_inactive: 5m закрывает файловый дескриптор, если файл не обновлялся 5 минут. Без этого Filebeat держит открытыми сотни дескрипторов на активном сервере.

Почему правильная настройка multiline критична?

Недавний кейс: клиент жаловался на дублирование логов в Elasticsearch. Filebeat захватывал каждую строку stacktrace как отдельное событие, и в результате логов стало в 10 раз больше нормы. Решение — настроить multiline.type: pattern с корректным выражением. После этого размер индекса сократился с 200 GB до 30 GB в месяц — экономия 85% дискового пространства.

Fluent Bit в Kubernetes: production-ready конфиг

Fluent Bit распространяется как Helm chart и разворачивается DaemonSet'ом. Конфигурация через ConfigMap:

# values.yaml для helm chart fluent-bit
config:
  inputs: |
    [INPUT]
    Name tail
    Path /var/log/containers/*.log
    multiline.parser docker, cri
    Tag kube.*
    Mem_Buf_Limit 64MB
    Skip_Long_Lines On
    Refresh_Interval 10
  filters: |
    [FILTER]
    Name kubernetes
    Match kube.*
    Kube_URL https://kubernetes.default.svc:443
    Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token
    Merge_Log On
    Keep_Log Off
    K8S-Logging.Parser On
    K8S-Logging.Exclude On
    [FILTER]
    Name grep
    Match kube.*
    Exclude $kubernetes['labels']['skip-logging'] true
  outputs: |
    [OUTPUT]
    Name loki
    Match kube.*
    Host loki.logging.svc.cluster.local
    Port 3100
    Labels job=fluentbit, namespace=$kubernetes['namespace_name'], pod=$kubernetes['pod_name'], app=$kubernetes['labels']['app']
    Label_Keys $level,$trace_id
    Batch_Size 1048576
    Batch_Wait 1s
    Line_Format json
tolerations:
  - key: node-role.kubernetes.io/master
    operator: Exists
    effect: NoSchedule
  - key: node-role.kubernetes.io/control-plane
    operator: Exists
    effect: NoSchedule

Fluent Bit GitHub позволяет подам отключать логирование через annotation fluentbit.io/exclude: "true" — полезно для debug-инструментов, генерирующих тонны мусора.

Promtail: позиции и надёжность доставки

Promtail хранит позиции чтения в файле /tmp/positions.yaml. Если этот файл не персистентен (например, в ephemeral container), после рестарта агент начнёт читать с начала и задублирует все логи. Для DaemonSet обязательно монтировать hostPath:

# promtail DaemonSet snippet
volumes:
  - name: positions
    hostPath:
      path: /var/log/promtail-positions
      type: DirectoryOrCreate
  - name: varlog
    hostPath:
      path: /var/log
  - name: varlibdockercontainers
    hostPath:
      path: /var/lib/docker/containers
volumeMounts:
  - name: positions
    mountPath: /run/promtail
  - name: varlog
    mountPath: /var/log
    readOnly: true
  - name: varlibdockercontainers
    mountPath: /var/lib/docker/containers
    readOnly: true

Promtail теряет позиции в 100% случаев, если не смонтировать hostPath. Гарантируйте сохранность positions.yaml.

Частые проблемы и их решения

Что входит в работу по настройке log shipping

Мы предоставляем полный цикл услуг:

• Аудит текущего logging pipeline: объём, потери, задержки.
• Выбор агента и проектирование архитектуры.
• Написание конфигов и Helm charts.
• Развёртывание через Ansible или GitOps.
• Интеграция с SIEM и системами оповещения.
• Документация и runbook для оператора.
• Пост-деплой мониторинг и оптимизация.

Процесс настройки log shipping под ключ

Этапы работы:

1. Анализ источников логов: приложения, системные, контейнеры. Определение частоты и объёмов (до 10 TB/сут).
2. Проектирование pipeline: выбор агента, конфигурация буферизации, резервирование (active-active).
3. Реализация: конфиги для всех серверов, Helm charts для Kubernetes, интеграция с SIEM.
4. Тестирование: стресс-тест с генерацией потока (10k событий/с), проверка потерь (SLO 99.9%).
5. Деплой и документация: Ansible/Helm развёртывание, runbook для оператора.

Ориентировочные сроки: от 2 до 5 рабочих дней в зависимости от сложности инфраструктуры. Стоимость рассчитывается индивидуально после аудита.

Готовы оценить ваш проект? Свяжитесь с нами — настроим log shipping под ключ с гарантией сохранности данных. Закажите аудит вашего logging pipeline уже сегодня.