Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Loglar neden başımıza dert oluyor?
Şimdi şöyle bir düşün…
Bir production problemi var ve sen loglara bakıyorsun. Ekranda yüzlerce, binlerce satır log akıyor. Ama aslında senin aradığın şey çok basit:
“Bu request’te ne oldu?”
Sorun şu: loglar genelde çok parçalıdır.
Bir request için:
- 1 satır giriş logu
- 3 satır DB logu
- 2 satır error logu
… derken her şey dağılır.
Yani şöyle bir durum oluşur:
Aynı request’e ait bilgi farklı yerlere dağılmıştır.
Bunu şöyle hayal edebilirsin:
Bir hikayeyi 10 parçaya bölmüşler ve her parça farklı sayfada yazıyor. Sen de hikayeyi anlamaya çalışıyorsun.
Structured logging: İlk çözüm ama yeterli değil
Bu problemi çözmek için geliştiriciler genelde structured logging kullanır.
Yani loglara şu tarz bilgiler eklenir:
- request_id
- user_id
- status
- duration
Bu sayede aynı request’e ait logları birleştirebilirsin.
Yani şöyle düşün:
Her parçaya bir “etiket” yapıştırıyorsun ve diyorsun ki “bunlar aynı hikayeye ait”.
Ama burada da bir problem var:
👉 Hâlâ veriler farklı satırlarda
Yani analiz yapmak için:
- logları çek
- request_id ile grupla
- birleştir
- sonra hesapla
Bu hem pahalı (compute açısından) hem de yavaş.
Asıl problem: Logları birleştirmek
Sen de fark etmişsindir ki…
Bir şeyleri anlamak için sürekli şu işlemi yapıyoruz:
“Bu request’in tüm loglarını topla ve analiz et”
Ama bu şu demek:
- çok veri tara
- çok işlem yap
- çok zaman harca
Özellikle Splunk gibi sistemlerde query yazmak bile ayrı bir iş.
Canonical Log Line: Basit ama güçlü fikir
İşte burada Stripe çok basit ama etkili bir çözüm getiriyor:
👉 Her request’in sonunda tek bir özet log yaz.
Buna “canonical log line” deniyor.
Canonical log line nedir?
Canonical log line şu mantıkla çalışır:
“Bu request hakkında bilmem gereken her şeyi tek satırda ver”
Bu log içinde şunlar olabilir:
- request_id
- user_id
- HTTP path
- status code
- duration
- yapılan DB query sayısı
- rate limit durumu
Yani tüm kritik bilgiler tek satırda toplanır.
Bunu şöyle hayal edebilirsin:
Artık hikayeyi 10 parçadan okumuyorsun, sana direkt özet çıkarılmış hali veriliyor.
Neden bu kadar işe yarıyor?
En kritik avantajı şu:
👉 Artık logları “birleştirmene gerek yok”
Örneğin şu soruya cevap arıyorsun:
“En çok rate limit’e takılan kullanıcılar kim?”
Eskiden:
- logları topla
- request bazında birleştir
- sonra group by yap
Şimdi:
- sadece canonical log line’ları filtrele
- group by user_id
- bitti
Bu kadar.
Performans avantajı
Bu yaklaşımın teknik olarak büyük avantajları var:
- Daha az veri işlenir
- Parsing maliyeti düşer
- Aggregation hızlı olur
- Query’ler basitleşir
Yani şöyle düşün:
Ham veriyi analiz etmek yerine, önceden hazırlanmış özet üzerinden gidiyorsun.
Sistem nasıl çalışıyor?
Stripe bunu şöyle çözmüş:
- Request işlenir
- Tüm metrikler toplanır
- En sonda canonical log line üretilir
- Log stdout’a yazılır
- Log collector (örneğin Fluent Bit) yakalar
- Kafka’ya gönderilir
- Oradan indexing + query sistemi işler
Bir risk: Herkes kafasına göre log yazarsa?
Burada önemli bir nokta var:
Eğer herkes farklı isimlerle key yazarsa:
- userId / user_id / uid
- duration / latency
… sistem kaosa döner.
Bu yüzden Stripe şunu yapıyor:
👉 Standart naming convention
Yani:
- herkes aynı isimleri kullanmak zorunda
- çakışma yok
- analiz kolay
Ne zaman kullanmalısın?
Bu yaklaşım özellikle şu durumlarda çok değerli:
- Production incident debugging
- Dashboard metrikleri
- Hızlı analiz ihtiyacı
- Yüksek trafik sistemler
Ama her sistem için şart değil.
Özet
Loglar aslında en güçlü debug aracımız ama çoğu zaman fazla parçalı oldukları için kullanımı zorlaşıyor. Structured logging bu sorunu kısmen çözse de verinin dağınık olması hâlâ büyük bir problem yaratıyor. Canonical log line yaklaşımı ise bu sorunu kökten basitleştiriyor: her request için tek bir özet log üretmek. Böylece logları birleştirme ihtiyacı ortadan kalkıyor, sorgular hızlanıyor ve sistem çok daha anlaşılır hale geliyor. Özellikle production ortamında hızlı karar vermek gerektiğinde bu yaklaşım ciddi bir fark yaratıyor.
Bu yazı Stripe’s Smarter Approach to Structured Logging – Canonical Log Lines videosundan ilham alınarak yazılmıştır.
