Loglama (Logging) Nedir?
Kısa tanım
Loglama (logging), bir uygulamanın veya sunucunun çalışırken gerçekleşen olayları zaman damgası, önem seviyesi ve bağlam bilgisiyle birlikte kayda geçirmesidir. Loglar hata ayıklamada, güvenlik olaylarının incelenmesinde ve denetim izi oluşturmada kullanılır. İyi bir log makinece ayrıştırılabilir (yapılandırılmış) olur; parola, token gibi gizli bilgileri ve gereğinden fazla kişisel veriyi içermez.
Diğer adları: logging, log, log kaydı, günlük kaydı, yapılandırılmış log, structured logging
Bir log satırı neyi anlatmalı?
Gece yarısı gelen bir hata bildiriminde elinizdeki tek kanıt çoğu zaman loglardır. İşe yarar bir log satırı, olayı yaşamamış birine şu soruların cevabını verir: ne zaman oldu (tercihen UTC ve milisaniye hassasiyetinde), ne kadar önemli (seviye), ne oldu (kısa ve sabit bir mesaj), hangi bağlamda (istek kimliği, servis adı, sürüm, ilgili kayıt kimliği). “Bir hata oluştu” yazan bir satır bu soruların hiçbirini yanıtlamaz.
Düz metin yerine yapılandırılmış log
Serbest metin loglar insan için okunaklıdır ama binlerce satır arasında arama yapmak düzenli ifadelerle uğraşmak demektir. Yapılandırılmış loglarda her kayıt, alanları belli bir nesnedir (genellikle JSON). Böylece log yönetim aracında “son bir saatte odeme-servisi sürüm 2.14.0'da level=error olan kayıtlar” gibi sorgular doğrudan çalışır.
// Serbest metin
2026-10-03 09:41:12 HATA odeme basarisiz siparis 1042 [email protected]
// Yapılandırılmış
{"ts":"2026-10-03T09:41:12.418Z","level":"error","service":"odeme-servisi",
"version":"2.14.0","msg":"payment declined","orderId":1042,
"provider":"bank-x","reason":"insufficient_funds","traceId":"4bf92f3577b34da6a3ce929d0e0e4736"}İkinci örnekte e-posta adresinin yer almadığına dikkat edin; sipariş kimliği, gerektiğinde kişiyi yetkili sistemlerden bulmaya yeter. traceId alanı ise bu satırı, isteğin servisler arasındaki yolunu gösteren dağıtık izleme kaydına bağlar.
Log seviyelerini anlamlı kullanmak
| Seviye | Ne zaman? | Örnek |
|---|---|---|
| DEBUG | Geliştirme ve kısa süreli inceleme; üretimde genellikle kapalı | Hesaplanan indirim ara değerleri |
| INFO | Normal ama kayda değer iş olayları | Sipariş oluşturuldu, toplu iş tamamlandı |
| WARN | Beklenmeyen ama sistemin tolere ettiği durum | Dış API yavaş yanıt verdi, yeniden denendi |
| ERROR | Bir işlem başarısız oldu, müdahale gerekebilir | Ödeme sağlayıcısına ulaşılamadı |
| FATAL / CRITICAL | Süreç çalışmaya devam edemiyor | Veritabanı bağlantısı kurulamadı, uygulama kapanıyor |
Her şeyi ERROR seviyesinde yazmak, gerçek hataları gürültünün içinde kaybettirir. Kullanıcının yanlış parola girmesi bir uygulama hatası değildir; ama aynı hesaba dakikada yüzlerce yanlış deneme yapılması, güvenlik açısından izlenmesi gereken bir olaydır.
Loglara girmemesi gerekenler
Loglar genellikle uygulama veritabanından çok daha geniş bir ekibe açıktır, harici servislere gönderilir ve uzun süre saklanır. Bu yüzden içlerine yazılan her şey yeni bir sızıntı yüzeyi oluşturur. OWASP Logging Cheat Sheet, doğrudan loglanmaması gereken veriler arasında parolaları, oturum kimliklerini, erişim token'larını, veritabanı bağlantı dizelerini, şifreleme anahtarlarını ve ödeme kartı verilerini sayar; bunların çıkarılmasını, maskelenmesini veya özetlenmesini önerir.
- İstek gövdesini ve başlıklarını toptan loglamayın.
Authorizationbaşlığı veya bir form gövdesindeki parola, en sık görülen sızıntı yoludur. Hassas alanları bir izin listesiyle seçin ya da otomatik maskeleyin. - Kişisel veriyi en aza indirin. Ad, e-posta, telefon, T.C. kimlik numarası, hatta IP adresi kişisel veri sayılabilir. Loglarda bunları tutmak KVKK kapsamında bir işleme faaliyetidir; amaçla sınırlı olmalı, saklama süresi ve erişim yetkileri belirlenmelidir. Çoğu durumda bir kayıt kimliği veya takma ad yeterlidir.
- Log enjeksiyonunu önleyin. Kullanıcıdan gelen veriler satır sonu karakterleri içeriyorsa sahte log satırları üretilebilir. Yapılandırılmış log kütüphaneleri değerleri kaçışlayarak bu riski büyük ölçüde azaltır.
Gizli bilgilerin kodda ve loglarda dolaşmaması, daha geniş bir disiplin olan gizli bilgi yönetiminin parçasıdır.
Güvenlik olaylarını kaydetmek
Loglar yalnızca hata ayıklama aracı değil, bir saldırıyı fark etmenin ve sonradan incelemenin de temelidir. Başarısız ve başarılı oturum açma denemeleri, yetki reddedilen istekler, parola ve e-posta değişiklikleri, yönetici işlemleri ve doğrulama hataları kayda geçmelidir. Bu kayıtlar sayesinde örneğin bir kaba kuvvet saldırısı erkenden görülebilir. Güvenlik logları, saldırganın izini silememesi için uygulama sunucusundan ayrı bir yerde, yalnızca eklemeye izin veren biçimde ve erişimi sınırlı olarak saklanmalıdır. Logları metrik ve trace verileriyle birlikte ele alan bütüncül yaklaşım için gözlemlenebilirlik maddesine bakabilirsiniz.