# Logları OpenSearch'e gönderirken Fluent Bit ile arasına Kafka/Redis buffer koymalı mıyım?

> Önce Fluent Bit'in filesystem buffer'ını açın; 40k/s kalıcıysa Kafka'ya geçin, Redis listesini yalnızca kaybını göze aldığınız loglarda kullanın.

- Soruldu: 2026-04-28
- Yanıtlandı: 2026-05-02
- Soran: Burak
- Etiketler: altyapi, observability, kafka
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/loglari-opensearch-e-gonderirken-araya-kafka-buffer-koymali-miyim/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Go ve Laravel servislerimizin loglarını merkezi bir OpenSearch kümesine topluyoruz. Akış şöyle: konteynerler stdout'a basıyor, sunuculardaki Fluent Bit yakalayıp doğrudan OpenSearch API'ına gönderiyor. Ama saniyede 40.000+ log satırını geçtiğimiz anlarda OpenSearch indexing'de darboğaz oluşuyor; Fluent Bit yetiştiremeyince backpressure başlıyor ve uygulama konteynerlerinin I/O'su bloke oluyor.

Araya buffer olarak Redis listesi mi yoksa Kafka mı koymalıyım? Veri kaybını (at-least-once) önlerken sunucularda disk/bellek şişmesini nasıl engellerim?


Kısa cevap: Evet, araya bir buffer koymak doğru hamle — ama Redis listesi ile Kafka arasındaki seçim, kabul ettiğin garanti seviyesine bağlı.

Yaşadığın şey klasik **backpressure**: OpenSearch'in indexleme hızı üretim hızının altına düşünce zincir geriye doğru tıkanıyor, en sonunda uygulama konteynerinin stdout'u bloke oluyor. Çözüm, üretimi (uygulama) tüketimden (OpenSearch) ayıran dayanıklı bir ara katman.

1. **Önce Fluent Bit'in kendi disk buffer'ını aç.** `storage.type filesystem` ve output tarafında `storage.total_limit_size` ile Fluent Bit, OpenSearch yavaşladığında logu RAM yerine diske yazar; uygulamaya doğru basınç gitmez. Harici bir kuyruk eklemeden önce ölçülmesi gereken ilk şey bu — çoğu zaman tek ihtiyacın olan budur.
2. **Redis listesi: ucuz ama riskli.** Bellekte tutar; `RPUSH`/`LPOP` basit ama AOF kapalıysa bir restart'ta veriyi kaybedersin ve liste şişerse Redis'in RAM'ını doldurur. Kaybı dert olmayan loglar için buffer olarak iş görür, finansal/audit logu için değil.
3. **Kafka: 40k/s'in doğal sahası.** Disk tabanlı, retention'lı, replay edilebilir, consumer group'larıyla yatay tüketim. `at-least-once`'ı doğal verir. Bedeli operasyonel: kümeyi ayağa kaldırıp beslemek gerekir. Hacmin kalıcıysa doğru araç odur.
4. **at-least-once'ı consumer'da idempotent kıl.** OpenSearch'e yazarken her belgeye deterministik bir `_id` ver (örn. kaynak+offset hash'i). Aynı mesaj iki kez gelse de aynı `_id` üstüne yazar; mükerrer kayıt oluşmaz.

**Sonuç:** Önce Fluent Bit filesystem buffer + OpenSearch tarafında bulk ayarı ve ISM (rollover) ile indexlemeyi rahatlat. Bu yetmiyorsa Kafka'ya geç — Redis'i yalnızca kaybını göze alabildiğin loglarda kullan. Ve altın kural: uygulama konteynerini log yazarken asla bloklatma. Log fire-and-forget olmalı; kritik veriyi (ödeme, audit) log hattı üzerinden taşıma, onu ayrı ve garantili bir yoldan yürüt.

## İlgili Yazılar

- [Laravel Queue ve Supervisor ile Asenkron İşlemler](/blog/laravel-queue-ve-supervisor-ile-asenkron-islemler/) — Blog
- [Log storm ve disk dolma krizini nasıl önlerim?](https://www.muhammetsafak.com.tr/sor-bakalim/log-storm-ve-disk-dolma-krizini-onlemek/) — Sor Bakalım
- [Correlation ID'yi HTTP isteğinden kuyruğa düşen job'lara kadar nasıl taşımalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/correlation-idyi-http-isteginden-kuyruga-dusen-joblara-kadar-nasil-tasimaliyim/) — Sor Bakalım
- [Loglarımda WARN ile ERROR seviyelerini ne zaman kullanacağıma dair net bir kural nasıl belirlerim?](https://www.muhammetsafak.com.tr/sor-bakalim/loglarimda-warn-ile-error-seviyelerini-ne-zaman-kullanacagima-dair-net-bir/) — Sor Bakalım