Uygulama Günlüğü: Kendi Olaylarınızı Kaydetmek

Bir müşteri "siparişim kayboldu" diyor. Erişim günlüklerinde o saatte bir istek görünüyor, hata günlüğünde bir şey yok. Ne olduğunu anlamanın hiçbir yolu yok — çünkü uygulamanız kendi adına hiçbir şey kaydetmiyor.

Bu yazı, uygulama seviyesinde günlük tutmayı ele alıyor.

Sunucu Günlüğü ile Fark

Üçüncü satır olmadan bir boşluk kalır: sunucu günlükleri isteğin geldiğini ve başarıyla yanıtlandığını söyler ama "ödeme reddedildi" veya "stok yetersiz" gibi iş kararlarını hiç görmez.

Kod hata vermeden yanlış davranıyorsa, sunucu günlükleri tamamen sessiz kalır.

Uygulama günlüğü tam olarak bu boşluğu doldurur ve "neden böyle oldu" sorusuna cevap verir.

Neyi Kaydetmeli?

Her şeyi kaydetmek işe yaramaz, seçici olmak gerekir:

• Kritik iş olayları. Sipariş, ödeme, iptal.
• Kimlik doğrulama olayları. Giriş, çıkış, başarısızlık.
• Dış servis çağrıları. İstek ve yanıt özeti.
• Yönetimsel değişiklikler. Kim neyi değiştirdi.
• Beklenmedik durumlar. Yakalanan istisnalar.

Üçüncü madde teşhis açısından en değerlisidir: bir dış servisin ne zaman yavaşladığını veya hangi yanıtı döndüğünü ancak kendi kaydınızdan öğrenirsiniz — o servisin günlüklerine erişiminiz yoktur.

"Ödeme sağlayıcısı bize hata döndü" iddiasını kanıtlamanın tek yolu budur.

Dördüncü madde ise hem güvenlik hem hesap verebilirlik sağlar. Bir fiyatın kim tarafından değiştirildiğini bilmek, ekip çalışmasında gereklidir.

Neyi Kaydetmemeli?

1. Şifreler. Hiçbir biçimde.
2. Kart bilgileri.
3. Oturum belirteçleri.
4. API anahtarları.
5. Gereksiz kişisel veri.

Üçüncü madde çok gözden kaçar ve ciddi bir açık üretir: günlüğe yazılan bir oturum belirteci, o dosyayı okuyabilen herkesin kullanıcı hesabına girebilmesi anlamına gelir.

Bu, hata ayıklama sırasında "tüm isteği kaydedelim" denilerek kolayca yapılan bir hatadır.

Doğru yaklaşım, hassas alanları kaydetmeden önce maskelemektir. Kart numarasının son dört hanesi yeterlidir, tamamı asla.

Beşinci madde ise yasal bir yükümlülüktür. Kaydettiğiniz kişisel veri, tüm veri koruma kurallarına tabidir.

Seviye Kullanmak

Her kayıt aynı önemde değildir:

Seviye kullanmanın pratik faydası filtrelemedir: üretimde yalnızca uyarı ve üstünü kaydederek disk kullanımını düşürür, sorun anında seviyeyi geçici olarak indirip ayrıntı toplayabilirsiniz.

Birinci satır üretimde açık bırakılmamalıdır. Hata ayıklama seviyesi çok hızlı disk doldurur.

Beşinci satır ise alarm üretmelidir. Kritik seviye bir kayıt yazıldığında birinin haberdar olması gerekir.

Kayıt Biçimi

Okunabilir olmak yetmez, aranabilir olmalıdır:

• Zaman damgası eksiksiz olsun.
• İlgili kimlikleri ekleyin. Sipariş, kullanıcı.
• Bir istek kimliği taşıyın.
• Yapılandırılmış biçim tercih edin.

Üçüncü madde teşhisi tamamen değiştirir: her isteğe benzersiz bir kimlik atayıp tüm kayıtlara eklemek, tek bir kullanıcının tek bir işlemi sırasında olan her şeyi tek bir aramayla toplamanızı sağlar.

Bu kimlik hata sayfasında kullanıcıya da gösterilebilir. Müşteri destek talebinde o numarayı verdiğinde, saniyeler içinde tüm akışı görürsünüz.

İkinci madde ise ilişkilendirmeyi sağlar. Sipariş numarasıyla arama yapabilmek, sorunu dakikalar yerine saniyeler içinde bulmayı mümkün kılar.

Nerede Saklanmalı?

1. Web kökünün dışında.
2. Döndürme kurallı.
3. Saklama süresi tanımlı.
4. Kritik olaylar veritabanında da olabilir.

Birinci madde temel bir güvenlik kuralıdır: web kökü içinde duran bir günlük dosyası, adresini tahmin eden herkes tarafından indirilebilir ve içindeki tüm iş bilgisi açığa çıkar.

İkinci madde ise diski korur. Döndürme kuralı olmayan bir günlük dosyası büyümeye devam eder ve sonunda hesabınızı doldurur.

Dördüncü madde ise sorgulanabilirlik sağlar. Denetim izi niteliğindeki kayıtlar, dosya yerine veritabanında tutulduğunda arayüzden görüntülenebilir.

Günlüğü Gerçekten Kullanmak

Birinci satır çoğu ekibin atladığı ama en çok getiri sağlayan alışkanlıktır: kullanıcıların hiç şikayet etmediği ama sessizce başarısız olan işlemler, ancak günlük taraması yapıldığında ortaya çıkar.

İnsanlar bir şeyin çalışmadığını genellikle bildirmez; sadece vazgeçip ayrılırlar.

İkinci satır ise yayına almanın doğal bir parçası olmalıdır. Yeni sürümden sonraki ilk saatlerde hata seviyesindeki kayıtlar izlenmelidir.

Günlük dosyalarına erişmek ve boyutlarını yönetmek için panel araçlarınızı kullanabilirsiniz; Linux hosting hizmeti kapsamında dosya yöneticisi ve disk kullanım raporu bu takibi kolaylaştırır.

Sonuç

Sunucu günlükleri isteğin geldiğini söyler ama "ödeme reddedildi" veya "stok yetersiz" gibi iş kararlarını hiç görmez — kod hata vermeden yanlış davrandığında tamamen sessiz kalırlar. Uygulama günlüğü bu boşluğu doldurur. En yüksek getiriyi veren tek uygulama, her isteğe benzersiz bir kimlik atamaktır: tek bir kullanıcının tek bir işlemi sırasında olan her şeyi tek aramayla toplarsınız. Ve oturum belirteçlerini asla kaydetmeyin; dosyayı okuyan herkes o hesaba girebilir.

Sıkça Sorulan Sorular (SSS)

Sunucu günlükleri yetmiyor mu?

Yetmez. Erişim günlüğü hangi adresin istendiğini, hata günlüğü hangi kod satırının patladığını söyler. Ama "ödeme reddedildi" veya "stok yetersiz" gibi iş kararlarını hiçbiri görmez. Kod hata vermeden yanlış davranıyorsa sunucu günlükleri tamamen sessizdir.

Teşhisi en çok ne kolaylaştırır?

Her isteğe benzersiz bir kimlik atayıp tüm kayıtlara eklemek. Böylece tek bir kullanıcının tek bir işlemi sırasında olan her şeyi tek aramayla toplarsınız. Bu kimliği hata sayfasında kullanıcıya da gösterin — destek talebinde numarayı verdiğinde saniyeler içinde akışı görürsünüz.

Neyi kaydetmemeliyim?

Şifreler, kart bilgileri, oturum belirteçleri ve API anahtarları. Oturum belirteci özellikle gözden kaçar: günlüğe yazılan bir belirteç, dosyayı okuyabilen herkesin o hesaba girebilmesi demektir. Hassas alanları kaydetmeden önce maskeleyin.

Günlükleri nereye koymalıyım?

Web kökünün dışına, döndürme kuralı ve saklama süresi tanımlı olarak. Web kökü içinde duran bir günlük dosyası adresini tahmin eden herkes tarafından indirilebilir. Döndürme kuralı olmayan dosya ise büyümeye devam edip hesabınızı doldurur.