Uygulama Hata İzleme: Kullanıcı Şikayet Etmeden Önce Haberdar Olmak

Sunucu ayakta, izleme yeşil, disk boş, CPU rahat. Ama bir kullanıcı ödeme sayfasında hata alıyor ve bunu size ancak telefonla bildiriyor.

Sunucu izleme ile uygulama hata izleme farklı şeylerdir. Bu yazı, ikincisini ele alıyor.

İzleme Boşluğu

Klasik sunucu izleme şunları görür:

Aradaki fark şudur: sunucu izleme altyapının sağlığını ölçer, hata izleme ise uygulamanın doğru çalışıp çalışmadığını.

Bir uygulama, sunucu mükemmel durumdayken de kullanıcılarına hata veriyor olabilir — ve bu, klasik izlemede hiçbir alarm üretmez.

Üç Katmanlı Yaklaşım

Eksiksiz bir görünürlük için üç katman gerekir:

1. Altyapı izleme: Sunucu kaynakları ve servisler.
2. Sentetik izleme: Dışarıdan düzenli işlem testi.
3. Hata izleme: Gerçek kullanıcı hatalarının toplanması.

İkinci katman sıkça atlanır ama en erken uyarıyı verir: kritik bir akışı dışarıdan düzenli olarak test eden bir betik, sorunu ilk kullanıcıdan önce yakalar.

Örneğin her beş dakikada bir test hesabıyla giriş yapıp bir ürünü sepete ekleyen bir kontrol, ödeme akışındaki bir kırılmayı dakikalar içinde bildirir.

Hataları Toplamak

Uygulama hatalarını merkezî olarak toplamanın temel gereksinimleri:

• Hatalar bir yere yazılmalıdır. Ekrana basmak yeterli değil.
• Bağlam kaydedilmelidir. Hangi kullanıcı, hangi istek?
• Yığın izi saklanmalıdır. Hata nereden geldi?
• Benzer hatalar gruplanmalıdır. Aynı hata bin kez bildirilmesin.
• Sıklık takip edilmelidir. Artış eğilimi önemlidir.

Dördüncü madde sistemin kullanılabilir kalmasını sağlar: gruplanmayan bir hata akışı, bir gün içinde okunamaz hâle gelir ve gerçek yeni sorunlar gürültü içinde kaybolur.

İkinci madde ise teşhis süresini belirler. Bağlamsız bir hata kaydı size sorunun varlığını söyler ama nedenini söylemez.

Hangi Bağlam Saklanmalı?

Bir hata kaydında bulunması gerekenler:

1. Zaman damgası — saat dilimi belirtilmiş olarak
2. Hata mesajı ve türü
3. Yığın izi
4. İstek adresi ve yöntemi
5. Kullanıcı kimliği — kişisel veri değil, kimlik numarası
6. Oturum veya istek kimliği
7. Uygulama sürümü
8. Sunucu adı — çok sunuculu yapıda

Yedinci madde ilişkilendirme için kritiktir: hataların hangi sürümle başladığını bilmek, sebebi bulmanın en hızlı yoludur. Yeni bir yayın sonrası fırlayan hata sayısı doğrudan o yayını işaret eder.

Beşinci maddede dikkat gerekir — kullanıcıyı tanımlayacak kadar bilgi saklayın ama kişisel veri biriktirmeyin. Kimlik numarası yeterlidir, ad ve e-posta gerekmez.

Gürültüyü Azaltmak

Hata izleme sisteminin en büyük düşmanı, ciddiye alınmayan bildirimlerdir:

Üçüncü satırda önemli bir ayrım vardır: bilinen bir hatayı sessize almak ile silmek farklıdır — sessize alınan hata sayılmaya devam eder, sıklığı artarsa yeniden görünür hâle gelir.

Uyarı Politikası

Her hata anında bildirim gerektirmez. Pratik bir kademelendirme:

• Yeni bir hata türü: Bildir — daha önce görülmemiş.
• Sıklık ani artışı: Bildir — bir şey bozuldu.
• Kritik akıştaki hata: Hemen bildir — ödeme, giriş.
• Bilinen ve seyrek hata: Bildirme, raporda göster.
• Belirli bir kullanıcıya özel: Toplu raporda değerlendir.

İkinci madde en değerli kuraldır: mutlak sayı yerine değişim oranını izlemek, gerçek sorunları yakalar. Günde beş kez görülen bir hatanın aniden beş yüz kez görülmesi, mutlak sayıdan çok daha anlamlı bir sinyaldir.

Saklama ve Gizlilik

Hata kayıtları hassas veri içerebilir. Dikkat edilecekler:

1. Form verilerini olduğu gibi kaydetmeyin. Şifre alanı sızabilir.
2. Belirli alanları maskeleyin. Kart, şifre, kimlik numarası.
3. Saklama süresi belirleyin.
4. Erişimi sınırlayın. Herkes görmemeli.

Birinci madde ciddi bir risktir ve çoğu ekip bunu yaşayarak öğrenir: hata anında tüm istek gövdesini kaydeden bir sistem, kullanıcı şifrelerini düz metin olarak biriktirebilir.

Kayıt sistemini kurarken maskeleme kurallarını baştan tanımlamak, sonradan temizlemekten çok daha kolaydır. Kendi sunucunuzu yönettiğiniz bir VDS sunucu hizmeti üzerinde hata kayıtlarını kendi kontrolünüzde tutabilir, saklama ve erişim politikasını kendiniz belirleyebilirsiniz.

Sonuç

Sunucu izleme ile uygulama hata izleme farklı işler yapar: biri altyapının sağlığını, diğeri uygulamanın doğru çalışıp çalışmadığını ölçer — ve bir uygulama, sunucu mükemmel durumdayken de kullanıcılarına hata veriyor olabilir. Aradaki boşluğu kapatan en etkili ek, kritik akışları dışarıdan düzenli test eden sentetik kontrollerdir. Uyarı politikasında mutlak sayı değil değişim oranını izleyin. Ve kayıt sistemini kurarken maskeleme kurallarını baştan tanımlayın — tüm istek gövdesini kaydeden bir sistem kullanıcı şifrelerini düz metin biriktirebilir.

Sıkça Sorulan Sorular (SSS)

Sunucu izlemem var, hata izleme de gerekli mi?

Gerekli. Sunucu izleme altyapının sağlığını ölçer — CPU, bellek, servis durumu. Uygulamanızın ödeme adımında hata vermesi bu ölçümlerin hiçbirini bozmaz ve hiçbir alarm üretmez. İki katman farklı sorunları yakalar.

Sorunu en erken nasıl yakalarım?

Sentetik izlemeyle. Kritik akışları — giriş, sepete ekleme, ödeme — dışarıdan düzenli test eden bir betik, kırılmayı ilk kullanıcıdan önce bildirir. Bu, gerçek kullanıcı hatalarını beklemekten çok daha hızlıdır.

Her hata için bildirim almalı mıyım?

Hayır, bu sistemi kullanılamaz kılar. Yeni hata türlerini ve sıklıktaki ani artışları bildirin; bilinen ve seyrek hataları toplu raporda gösterin. Mutlak sayı yerine değişim oranını izlemek çok daha anlamlı bir sinyaldir.

Hata kayıtlarında neye dikkat etmeliyim?

İstek gövdesini olduğu gibi kaydetmeyin — şifre, kart bilgisi ve kimlik numarası gibi alanları maskeleyin. Kullanıcıyı tanımlamak için kimlik numarası yeterlidir, ad ve e-posta saklamaya gerek yoktur. Saklama süresi ve erişim yetkisi de baştan tanımlanmalıdır.