Порівняння 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 вже сьогодні.