Geçen kış — henüz filo sistemleri tarafında çalışırken — baktığımız bir araç takip sisteminin sunucusu gece 03:14'te durmuştu. Telefonlar çalmaya başladığında ekip saldırı ihtimalini konuşuyordu; gerçek çok daha sıradan çıktı. 600 GB'lık diskin 540 GB'ını log dosyaları doldurmuştu. Asıl acı olan şu: o 540 GB'ın içinde, sistemin neden yavaşladığını açıklayan işe yarar tek bir satır bile bulamadık. Her şeyi logluyorlardı ama hiçbir soruya cevap alamıyorlardı.
Bu tablo istisna değil. 2010'dan beri elimden geçen projelerde en sık gördüğüm iki uç var: ya log diye bir şey yok ve hata olunca herkes karanlıkta el yordamıyla geziniyor, ya da her satır kod bir log yazıyor ve sinyal gürültünün içinde kayboluyor. İkisi de aynı kapıya çıkıyor — üretimde bir şey ters gittiğinde "ne oldu?" sorusuna makul sürede cevap veremiyorsunuz.
Log Bir Cevaptır, Günce Değil
Loglamaya başlarken sorulacak soru "neyi loglayalım" değil, "üç ay sonra hangi soruları soracağız" olmalı. "X müşterisinin dünkü ödemesi neden başarısız oldu?", "Bu endpoint saat kaçta yavaşlamaya başladı?", "Şu kaydı kim, ne zaman değiştirdi?" Log stratejiniz bu sorulara dakikalar içinde cevap verebiliyorsa doğru yoldasınız; veremiyorsa terabaytlarca dosya biriktiriyorsunuz, o kadar.
Pratikte her isteğe bir correlation ID vermek bu işin bel kemiği. Mobil uygulamadan gelen istek API'ye, oradan kuyruğa, oradan üçüncü parti servise giderken aynı kimliği taşımalı. Geçen ay platformumuzdaki bir ödeme entegrasyonu hatasını bu sayede dört dakikada bulduk; benzer bir problemi yıllar önce, correlation ID olmayan bir projede iki gün aramıştım. Aradaki fark yazılım kalitesi değil, log disiplini.
Peki asgari ne loglanmalı? Bizim çizgimiz şu: her isteğin sonunda tek bir özet satır — kim, hangi endpoint, kaç milisaniye, hangi durum kodu. Buna ek olarak her dış servis çağrısının sonucu ve süresi; çünkü "sistem yavaş" şikâyetlerinin yarısında suçlu bizim kod değil, cevabı sekiz saniyede dönen üçüncü parti API oluyor ve bunu kanıtlayacak veri elinizde yoksa tartışma haftalarca sürüyor. Bir de iş açısından kritik durum değişiklikleri: sipariş durumu, ödeme durumu, yetki değişikliği. Bu üçlü çekirdeği kurduktan sonra gerisi projeye göre şekilleniyor.
Bir de mesajın kendisi var. "Hata oluştu" yazan bir log satırı, hiç yazılmamış olandan sadece biraz iyidir. Hangi işlem, hangi girdiyle, hangi adımda, hangi hatayı aldı — bunlar yoksa o satır sadece yer kaplıyor demektir.
Seviyeler Konusunda Dürüst Olalım
Log seviyesi teoride herkesin bildiği, pratikte neredeyse kimsenin doğru kullanmadığı bir konu. Yıllar içinde devraldığım projelerdeki tipik tablo: her şey ya INFO ya ERROR. Oysa ayrım tek bir soruya dayanıyor: bu satır yazıldığında birinin bir şey yapması gerekiyor mu?
- ERROR: Birinin bakması gerekiyor. Gece kimseyi uyandırmayacaksa muhtemelen ERROR değildir.
- WARN: Şimdilik değil ama birikirse sorun; retry'a düşen istekler, dolmaya yaklaşan kotalar.
- INFO: İşin akışını anlatan olaylar; sipariş oluştu, ödeme onaylandı, araç güzergâha girdi.
- DEBUG: Geliştirme ve geçici teşhis için; üretimde varsayılan olarak kapalı.
Yıllar önce bir müşteride ERROR seviyesinde günde 40 bin satır birikiyordu. Sorduk: "Bunların kaçına bakıyorsunuz?" Cevap: "Hiçbirine, çok fazla geliyor." ERROR kanalına bakılmıyorsa o kanal ölmüştür; gerçek bir felaket geldiğinde de kimse fark etmez. Alarm yorgunluğu dediğimiz şey tam olarak bu.
Dosyada Bırakmayın, Ama Her Şeyi de Merkeze Taşımayın
Tek sunuculu küçük bir projede dosyaya yazıp logrotate ile döndürmek gayet meşru bir çözüm. Ama ikinci sunucu devreye girdiği an SSH ile dosya gezmek işkenceye dönüşüyor. Merkezi bir log sistemi — bizim platformda Grafana'nın yanına Loki oturdu; küçük işlerde yönetilen servisler de yeterli — artık lüks sayılmıyor.
Burada bütçe uyarısı yapayım: merkezi log sistemlerinin faturası hacimle büyür. DEBUG seviyesini merkeze taşımak, hiç sorgulanmayacak veriye her ay para ödemektir. Bizim formülümüz şöyle: ERROR ve WARN her zaman merkeze gider, INFO örneklenerek ya da kısa saklama süresiyle tutulur, DEBUG ise sadece bir sorunu kovalarken açılan bir musluktur.
Yapılandırılmış log da bu noktada devreye giriyor. "Kullanıcı 4521 siparişi tamamladı" cümlesini grep'lemekle, JSON içindeki user_id=4521 alanına sorgu atmak arasında dağlar var. Ayrıca metrikle logu birbirine karıştırmayın: "dakikada kaç istek geliyor" sorusu metrik işidir, bunu loglardan saymaya kalkmak hem pahalı hem yavaş. Log "ne oldu"yu, metrik "ne kadar"ı anlatır; ikisini aynı boruya sıkıştıran projelerde ikisi de kötü çalışıyor. Yeni serviste düz metin log yazmayı tamamen bıraktık; platformdaki miras servislerde de ilk dokunduğumuz yer genelde burası oluyor.
Saklama Süresi Aynı Zamanda Bir Hukuk Sorusu
"Ne kadar tutalım?" sorusunun tek bir cevabı yok. Erişim ve trafik kayıtları için mevzuat devrede; 5651 sayılı kanun kapsamındaki kayıtların süresi belli, KVKK da kişisel veri içeren her logu ilgilendiriyor. Öte yandan içinde kişisel veri geçen uygulama loglarını yıllarca tutmak başlı başına bir risk — log dosyanız sızarsa veritabanınız sızmış kadar yanarsınız. TC kimlik, telefon, kart numarası gibi alanların loga maskesiz yazılması bizim ekipte kod review'da otomatik red sebebi.
Pratik formülümüz: hata ayıklama logları 14-30 gün, iş olayları ve audit kayıtları 1-2 yıl, mevzuata tabi kayıtlar kanun ne diyorsa o kadar. Ve bu süreler yazılı bir politikada dursun; "sanırım sonsuza kadar tutuyoruz" bir strateji değil, bir itiraf.
Logları Artık Sadece İnsanlar Okumuyor
Son bir yıldır işin rengi ciddi biçimde değişti. Bizim sistemde loglara ilk bakan artık çoğu zaman bir insan değil; MCP üzerinden log sistemine bağlanan bir AI ajanı. Nöbetçi geliştirici uyandırılmadan önce ajan ilgili zaman aralığını tarıyor, benzer geçmiş olayları buluyor, hipotezini yazıp bırakıyor. Sabah kahvesini içerken hazır bir ön analiz bulmak (deneyene kadar ben de abartı sanıyordum) nöbet kültürünü baştan değiştirdi.
Ama bu düzen ancak loglar yapılandırılmışsa, seviyeler dürüst kullanılıyorsa ve correlation ID varsa çalışıyor. Dağınık loglarla beslenen ajan da insan gibi boğuluyor; sadece daha hızlı ve daha pahalı boğuluyor. İyi loglama artık yalnızca sizin gece uykunuz için değil, yanınızda çalışan yapay zekânın da gözü kulağı.
Projenizin log altyapısını gözden geçirecekseniz üç soruyla başlayın: correlation ID var mı, ERROR kanalına gerçekten bakılıyor mu, saklama süreleri yazılı mı? On altı yıldır bu tablonun her hâlini gördüm; sizinki beni şaşırtmaz. Loglama sohbetine her zaman varım; iletişim sayfası açık.