Ответ
Да, я использовал Fluentd как унифицированный сборщик логов в DevOps-практиках. Основная цель — агрегировать логи от разнородных источников (приложения, контейнеры, системные сервисы) и направлять их в централизованное хранилище, такое как Elasticsearch или S3.
Мой опыт включает:
- Конфигурация и парсинг: Написание конфигурационных файлов (
td-agent.conf) для парсинга структурированных и неструктурированных логов (Nginx, Docker, системного journald) с использованием встроенных и кастомных плагинов (parser,filter). - Надежность доставки: Настройка буферизации (
bufferсекции) и механизма повторных попыток (retry) для обработки сетевых сбоев или недоступности выходного плагина (например, при падении Elasticsearch). - Развертывание в Kubernetes: Использование Fluentd в качестве DaemonSet для сбора логов с каждой ноды. Конфигурация через ConfigMap, парсинг логов контейнеров с использованием плагина
kubernetes_metadataдля обогащения записей метаданными (pod name, namespace). - Маршрутизация: Настройка тегов (
tag) и правилmatchдля маршрутизации разных типов логов в разные destinations (например, логи приложений — в Elasticsearch для анализа, аудит-логи — в S3 для долгосрочного хранения).
Пример конфигурации для сбора логов Docker контейнеров и отправки в Elasticsearch:
<source>
@type tail
path /var/lib/docker/containers/*/*.log
pos_file /var/log/fluentd-docker.pos
tag docker.*
<parse>
@type json
time_key time
time_format %Y-%m-%dT%H:%M:%S.%NZ
</parse>
</source>
<filter docker.var.lib.docker.containers.**>
@type record_transformer
<record>
hostname ${hostname}
</record>
</filter>
<match docker.**>
@type elasticsearch
host es-logging.prod.internal
port 9200
logstash_format true
logstash_prefix fluentd-docker
buffer_chunk_limit 2M
buffer_queue_limit 32
flush_interval 5s
max_retry_wait 30
disable_retry_limit
num_threads 4
</match>
Для более сложной обработки и трансформации данных в современных стеках часто рассматриваю Fluent Bit как более легковесную альтернативу.