در سیستم‌های توزیع‌شده، log همه جا هست و هیچ‌جا یکسان نیست:

app stdout → فایل → syslog → cloud agent → …
هر تیم SDK خودش → Elasticsearch / S3 / Kafka / Splunk

نتیجه: تعویض backend = بازنویسی collectorها؛ از دست رفتن log هنگام outage مقصد؛ schema ناهمسان.

Fluentd برای همین ساخته شد:

Build Your Unified Logging Layer — Unify data collection and consumption for a better use and understanding of data.

یعنی یک لایه میانی که منابع را از backendها جدا می‌کند — با صدها پلاگین، و مدل «logs as streams, not files» (به قول Adam Wiggins، هم‌بنیان‌گذار Heroku).

CNCF Graduated — ۱۱ آوریل ۲۰۱۹ (ورود Incubating نوامبر ۲۰۱۶). بیش از ۵۰۰۰ شرکت؛ بزرگ‌ترین کاربران در مقیاس ده‌ها هزار سرور. همه اجزا Apache 2.0.

مشکل: coupling لاگ به مقصد

بدون لایه یکپارچه:
  App ──SDK──► ES
  App ──agent──► S3
  App ──file──► grep دستی

با Fluentd:
  Sources ──► Fluentd (tag + buffer + route) ──► ES / S3 / Kafka / …
                    ▲
              تعویض output بدون تغییر app

Fluentd جایگزین SIEM یا Elasticsearch نیست — collector و router در مسیر observability است.

Fluentd چیست؟

طبق fluentd.org و docs:

• open source data collector برای unified logging layer
• log را به‌صورت JSON (machine-readable) درمان می‌کند
• هسته با عملکرد بالا (C) + انعطاف Ruby برای پلاگین/اسکریپت
• proven در مقیاس: ۵۰٬۰۰۰+ سرور در بزرگ‌ترین استقرارهای گزارش‌شده
• اکوسیستم پلاگین برای input، output، filter، parser، buffer، …

Site: fluentd.org
Docs: docs.fluentd.org
Fluent Bit: fluentbit.io (هم‌خانواده، CNCF)
Repo: github.com/fluent/fluentd

خالق: Sadayuki “Sada” Furuhashi (Treasure Data)، ۲۰۱۱
نقل Matz: «programmer happiness و performance همزمان» — Ruby فراتر از وب.

بستهٔ مدرن توزیع: fluent-package (جایگزین مسیرهای قدیمی td-agent در docs جدید).

تاریخچه و CNCF

مدل داده: Event

هر event سه بخش دارد:

Routing با <match> و الگوی tag (*, **, a.b.*) انجام می‌شود — قلب Unified Logging Layer.

معماری Pipeline

Source(s)
    │
    ▼
┌─────────┐   ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
│ Input   │──►│ Parser │──►│ Filter │──►│ Buffer │──►│ Output │
└─────────┘   └────────┘   └────────┘   └────────┘   └────────┘
   tail/http      nginx         enrich      file/mem      ES/S3/…
   forward        json          grep
   syslog         regexp        geoip

Buffer حیاتی است: اگر Elasticsearch لحظه‌ای down باشد، chunkها روی disk می‌مانند و با backoff دوباره ارسال می‌شوند — «at-least-once» عملیاتی در مسیر لاگ.

نمونه Config

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/fluentd/nginx.access.pos
  tag web.nginx
  <parse>
    @type nginx
  </parse>
</source>

<filter web.nginx>
  @type record_transformer
  <record>
    hostname "#{Socket.gethostname}"
    environment "production"
  </record>
</filter>

<match web.nginx>
  @type elasticsearch
  host es.example.com
  port 9200
  logstash_format true
  <buffer>
    @type file
    path /var/log/fluentd/buffer/es
    flush_interval 5s
    retry_type exponential_backoff
  </buffer>
</match>

تعویض مقصد به S3 = تغییر بلوک <match> — بدون دست زدن به app یا input.

Forward protocol

Fluentd/Fluent Bit اغلب با @type forward به هم وصل می‌شوند:

Node (Fluent Bit DaemonSet) ──forward──► Aggregator (Fluentd) ──► ES / S3

الگوی کلاسیک Kubernetes: Bit روی edge، Fluentd در مرکز برای پردازش سنگین‌تر.

Fluentd در برابر Fluent Bit

هر دو زیر چتر Fluent / CNCF هستند — نقش‌ها متفاوت:

OpenAI و دیگران برای مقیاس agent روی node اغلب Fluent Bit را tune می‌کنند؛ Fluentd همچنان برای routing غنی و پلاگین‌های سازمانی قوی است. خیلی pipelineها هر دو را با هم دارند.

Use cases

Kubernetes

الگوهای رایج:

1. Fluent Bit DaemonSet روی هر node — خواندن /var/log/containers
2. Enrich با metadata کوبرنتیز (pod، ns، labels)
3. Forward به Fluentd StatefulSet/Deployment (اختیاری) یا مستقیم به Loki/ES/Cloud
4. GitOps مقادیر Helm با Argo CD

# مفهومی — chart رسمی/جامعه Fluent را از docs روز بگیرید
helm repo add fluent https://fluent.github.io/helm-charts
helm install fluent-bit fluent/fluent-bit -n logging --create-namespace

برای فقط Fluentd به‌عنوان collector روی node هم DaemonSet ممکن است؛ در تراکم بالا Bit معمولاً انتخاب اول edge است.

لاگ‌های امنیت از Falco را هم می‌توان به همان pipeline فرستاد (از طریق Falcosidekick → HTTP/Kafka → Fluentd).

قابلیت اطمینان و Buffer

<buffer>
  @type file
  path /var/log/fluentd/buffer/out
  chunk_limit_size 8MB
  queue_limit_length 64
  flush_mode interval
  flush_interval 5s
  retry_type exponential_backoff
  overflow_action block   # یا drop_oldest_chunk — آگاهانه انتخاب کنید
</buffer>

نکات:

• file buffer برای production وقتی از دست نرفتن لاگ مهم است
• disk جدا برای buffer تا root پر نشود
• overflow_action را با SLO هماهنگ کنید (block vs drop)
• نظارت روی طول صف و retry

Observability خود Fluentd

• متریک‌های داخلی پلاگین‌ها
• monitor plugin / Prometheus exporters در اکوسیستم
• log خود Fluentd را جدا نگه دارید تا loop نشود

اگر مقصد ES کند است، اول buffer و upstream را ببینید — نه اینکه فقط replica Fluentd زیاد کنید.

امنیت

• Fluentd اغلب به فایل‌های لاگ و شبکه داخلی دسترسی دارد — RBAC و hostPath را محدود کنید
• TLS برای forward و خروجی به ES/Kafka
• secretها در env/Secret کوبرنتیز — نه plaintext در ConfigMap عمومی
• ورودی http را بدون auth به اینترنت باز نکنید
• تصاویر رسمی و به‌روزرسانی منظم (وابستگی Ruby gems)

Ingress لاگ از Contour / Envoy access log هم می‌تواند به Fluentd برسد.

مقایسه با جایگزین‌ها

ارتباط با stack شما

Pods / Nodes / [Falco](/blog/falco-runtime-security-ebpf-guide/) alerts
        │
        ▼
Fluent Bit (DaemonSet) ──forward──► Fluentd (aggregator)
                                        │
                    ┌───────────────────┼───────────────────┐
                    ▼                   ▼                   ▼
                 OpenSearch            S3                 Kafka
                 / Loki

Cluster: [CoreDNS](/blog/coredns-kubernetes-dns-guide/) · [Cilium](/blog/cilium-ebpf-kubernetes-networking/)
Images: [Harbor](/blog/harbor-cloud-native-registry-guide/) ± [Dragonfly](/blog/dragonfly-p2p-image-distribution-guide/)
GitOps: [Argo](/blog/argo-project-kubernetes-gitops-cicd/)

Fluentd لایه telemetry transport & transform است — نه storage پایدار (Longhorn، CubeFS).

Best practices

1. از روز اول tag naming convention تعریف کنید (env.team.service.type)
2. Parse را نزدیک source انجام دهید — record ساخت‌یافته زودتر
3. Production: file buffer + disk جدا
4. Aggregator Fluentd را از DaemonSet edge جدا کنید (Bit روی node)
5. Rate و حجم لاگ را با filter/grep کنترل کنید تا هزینه ES منفجر نشود
6. Multi-output با کپی مسئولانه (یا copy plugin) — مراقب amplification باشید
7. Config را GitOps کنید؛ reload آگاهانه
8. SLO برای lag و dropped chunks بگذارید
9. PII را در filter redact کنید قبل از خروج از VPC
10. نسخه fluent-package / chart را با پلاگین‌های لازم pin کنید

Troubleshooting

fluentd --dry-run -c /etc/fluent/fluent.conf
# یا در K8s
kubectl -n logging logs -l app=fluentd --tail=100

چه زمانی Fluentd؟

✅ استفاده کنید

• نیاز به جداسازی ده‌ها منبع از چند backend
• پلاگین‌های بالغ برای ES، S3، Kafka، MongoDB، …
• Aggregator مرکزی با buffer و routing پیچیده
• ترکیب با Fluent Bit در Kubernetes

⚠️ شاید نه

• فقط چند container و Loki ساده → Fluent Bit / Alloy کافی است
• تیم بدون ظرفیت ops برای صف و پلاگین Ruby
• محدودیت شدید حافظه روی هر node بدون aggregator جدا

جمع‌بندی

Fluentd همان لایه‌ای است که «لاگ را stream می‌کند نه فقط فایل» — و به شما اجازه می‌دهد backend را عوض کنید بدون اینکه application و صدها agent را از نو بنویسید.

قدم بعدی

1. Quickstart — نصب fluent-package و یک tail → stdout
2. Parse nginx/json و یک <filter> enrichment
3. Output به Elasticsearch یا S3 با <buffer> فایل
4. روی Kubernetes: Fluent Bit DaemonSet → forward به Fluentd
5. Convention تگ و داشبورد lag/buffer را مستند کنید

منابع یادگیری: Fluent Bit Academy روی سایت پروژه، و docs رسمی Fluentd / Fluent Bit.

منابع

• Fluentd — fluentd.org
• Documentation
• Quickstart
• Fluent Bit
• CNCF Fluentd
• Graduation announcement
• GitHub — fluent/fluentd

منتشر شده در P30Light — بخش زیرساخت و سرور.