Günlük düzeyleri - Günlük kaydı - günlük düzeylerini atamak için genel kural

Mevcut projemde geri oturum kullanıyorum .

Altı günlük kaydı sunar: TRACE DEBUG INFO WARN ERROR OFF

Ortak faaliyetler için günlük düzeyini belirlemek için bir başparmak kuralı arıyorum. Örneğin, bir iş parçacığı kilitliyse, günlük iletisi hata ayıklama düzeyine veya bilgi düzeyine ayarlanmışsa. Veya bir soket kullanılıyorsa, belirli kimliği hata ayıklama düzeyinde veya izleme düzeyinde kaydedilmişse.

Her günlük kaydı düzeyi için daha fazla örnek içeren yanıtları takdir edeceğim.

Çoğunlukla büyük ölçekli, yüksek kullanılabilirlikli tip sistemler inşa ediyorum, bu yüzden cevabım ona bir üretim destek bakış açısından bakmaya eğilimli; dedi ki, kabaca şu şekilde atarız:

• hata : sistem sıkıntıda, müşteriler muhtemelen etkileniyor (veya yakında olacak) ve düzeltme muhtemelen insan müdahalesini gerektiriyor. Burada "2AM kuralı" geçerlidir - görüşme yapıyorsanız, bu durum gerçekleşirse 2: 00'de uyanmak ister misiniz? Evetse, "hata" olarak kaydedin.

• uyar : beklenmedik bir teknik olay veya iş olayı meydana geldi, müşteriler etkilenebilir, ancak büyük olasılıkla acil insan müdahalesi gerekmez. Çağrı sırasında insanlar hemen çağrılmaz, ancak destek personeli etkinin ne olduğunu anlamak için bu sorunları en kısa zamanda gözden geçirmek isteyecektir. Temel olarak izlenmesi gereken ancak acil müdahale gerektirmeyen herhangi bir sorun.

• bilgi : Bir sorunu adli olarak analiz etmemiz gerektiğinde yüksek hacimde görmek istediğimiz şeyler. Sistem yaşam döngüsü olayları (sistem başlatma, durdurma) buraya gidin. "Oturum" yaşam döngüsü etkinlikleri (giriş, çıkış, vb.) Buraya gidin. Önemli sınır olayları da dikkate alınmalıdır (örn. Veritabanı çağrıları, uzak API çağrıları). Tipik iş istisnaları buraya gidebilir (ör. Kötü kimlik bilgileri nedeniyle giriş başarısız oldu). Üretimde yüksek hacimde görmeniz gerektiğini düşündüğünüz diğer tüm etkinlikler buraya gelir.

• hata ayıklama : "bilgi" yi kesmeyen hemen hemen her şey ... sistemdeki akışı izlemeye ve özellikle geliştirme ve KG aşamalarında sorunları izole etmeye yardımcı olan herhangi bir mesaj. Önemsiz yöntemlerin çoğuna giriş / çıkış yapmak ve yöntemler içindeki ilginç olayları ve karar noktalarını işaretlemek için "hata ayıklama" seviye günlüklerini kullanıyoruz.

• izleme : Bunu sık kullanmıyoruz, ancak bu normal geliştirme sırasında bile normalde etkinleştirilmesini istemediğiniz son derece ayrıntılı ve potansiyel olarak yüksek hacimli günlükler içindir. Örnekler arasında tam bir nesne hiyerarşisinin boşaltılması, büyük bir döngünün her yinelemesi sırasında bazı durumların günlüğe kaydedilmesi vb. Sayılabilir.

Doğru günlük düzeylerini seçmekten veya daha önemli olarak, günlüklerin anlamlı ve gerekli bağlama sahip olmasını sağlamaktır. Örneğin, hemen hemen her zaman iş parçacığı kimliğini günlüklere dahil etmek istersiniz, böylece gerekirse tek bir iş parçacığını takip edebilirsiniz. Ayrıca iş bilgilerini (ör. Kullanıcı kimliği) iş parçacığıyla da ilişkilendirmek için bir mekanizma kullanmak isteyebilirsiniz, böylece günlüğe kaydedilir. Günlük iletinize, iletinin işlem yapılabilir olmasını sağlamak için yeterli bilgi eklemek istersiniz. "FileNotFound özel durumu yakalandı" gibi bir günlük çok yararlı değildir. Daha iyi bir ileti, "/usr/local/app/somefile.txt. Yapılandırma dosyasını açmaya çalışırken FileNotFound özel durumu yakalandı." UserId = 12344. "

Ayrıca, orada iyi günlüğe kaydetme rehberleri de vardır ... örneğin, JCL'den (Jakarta Commons Logging) düzenlenmiş bir snippet :

• error - Diğer çalışma zamanı hataları veya beklenmeyen durumlar. Bunların bir durum konsolunda hemen görünmesini bekleyin.
• uyar - Kullanımdan kaldırılmış API'ların kullanımı, API'nın yetersiz kullanımı, 'neredeyse' hatalar, istenmeyen veya beklenmeyen, ancak mutlaka "yanlış" olmayan diğer çalışma zamanı durumları. Bunların bir durum konsolunda hemen görünmesini bekleyin.
• info - İlginç çalışma zamanı olayları (başlatma / kapatma). Bunların bir konsolda hemen görünmesini bekleyin, bu nedenle muhafazakar olun ve minimumda tutun.
• hata ayıklama - sistemden geçen akış hakkında ayrıntılı bilgi. Bunların yalnızca günlüklere yazılmasını bekleyin.
• izleme - daha ayrıntılı bilgi. Bunların yalnızca günlüklere yazılmasını bekleyin.

Benim yaklaşımım, bence bir operasyon açısından daha çok bir gelişmeden geliyor:

• Hata , bazı görevlerin yürütülmesinin tamamlanamadığı anlamına gelir; bir e-posta gönderilemedi, bir sayfa oluşturulamadı, bazı veriler bir veritabanında depolanamadı, bunun gibi bir şey. Bir şeyler kesinlikle yanlış gitti.
• Uyarı , beklenmedik bir şey olduğu anlamına gelir, ancak yürütme, belki de bozulmuş bir modda devam edebilir; bir yapılandırma dosyası eksikti, ancak varsayılanlar kullanıldı, bir fiyat negatif olarak hesaplandı, bu yüzden sıfıra kelepçelendi, vb. Bir şeyler doğru değil, ancak düzgün bir şekilde yanlış gitmedi - uyarılar genellikle olacağının bir işaretidir çok yakında bir hata.
• Bilgi , normal fakat önemli bir şeyin olduğu anlamına gelir; sistem başlatıldı, sistem durdu, günlük envanter güncelleme işi yapıldı, vb. Bunların sürekli torrentleri olmamalı, aksi halde okunacak çok şey var.
• Hata ayıklama , normal ve önemsiz bir şeyin olduğu anlamına gelir; siteye yeni bir kullanıcı geldi, bir sayfa oluşturuldu, bir sipariş alındı, bir fiyat güncellendi. Çok fazla olurdu çünkü bu bilgi hariç tutulan şeyler.
• İz aslında hiç kullanmadığım bir şeydir.

Bu, teğetsel olarak, belirli bir düzeydeki bir günlük kaydı isteğinin (koddan), bir dağıtımın yapılandırıldığı etkin günlük düzeyi göz önüne alındığında gerçekte günlüğe kaydedilip sonuçlanmayacağını anlamak için teğetsel olarak yardımcı olabilir . Buradaki diğer Yanıtlardan dağıtımınızı yapılandırmak istediğiniz etkin düzeye karar verin ve kodunuzdan belirli bir günlükleme isteğinin gerçekten günlüğe kaydedilip kaydedilmeyeceğini görmek için buna bakın ...

Örnekler için :

• "UYARI'da oturum açan bir günlük kodu satırı, ERROR ile yapılandırılmış dağıtımımda gerçekten oturum açacak mı?" Tabloda HAYIR diyor.
• "WARN'de oturum açan bir günlük kodu satırı, DEBUG ile yapılandırılmış dağıtımımda gerçekten oturum açacak mı?" Tabloda EVET diyor.

dan logback belgeler :

Daha grafik bir şekilde, seçim kuralı şu şekilde çalışır. Aşağıdaki tabloda, dikey üstbilgi, p ile gösterilen günlükleme isteğinin seviyesini gösterirken, yatay üstbilgi, q ile belirtilen günlükçünün etkili düzeyini gösterir. Satırların (düzey isteği) ve sütunların (etkin düzey) kesişimi, temel seçim kuralından kaynaklanan boole değeridir.

Bu nedenle, günlüğe kaydetmeyi isteyen bir kod satırı, yalnızca dağıtımının etkin günlüğe kaydetme düzeyi söz konusu kod satırının istenen önem düzeyinden düşük veya ona eşitse günlüğe kaydedilir .

Bunu, bir kuruluşun birbirine güvenebilecek birçok bileşen çalıştırabileceği bileşen tabanlı bir mimariden geliyorum. Yayılma hatası sırasında, kayıt düzeyleri hem hangi bileşenlerin etkilendiğini hem de hangisinin kök neden olduğunu belirlemeye yardımcı olmalıdır.

• HATA - Bu bileşenin bir hatası vardı ve nedenin dahili olduğuna inanılıyor (herhangi bir dahili, işlenmeyen istisna, kapsüllenmiş bağımlılığın başarısızlığı ... örn. Veritabanı, REST örneği, bağımlılıktan 4xx hatası almış olabilir). Beni (bu bileşenin koruyucusu) yataktan çıkar.

• UYARI - Bu bileşen, bağımlı bir bileşenden kaynaklandığına inanılan bir hatayla karşılaştı (REST örneği, bağımlılıktan kaynaklanan 5xx durumu olacaktır). THAT bileşeninin koruyucularını yataktan çıkarın.

• BİLGİ - Bir operatöre almak istediğimiz her şey. Mutlu yolları günlüğe kaydetmeye karar verirseniz, önemli işlem başına 1 günlük mesajı ile sınırlandırmanızı öneririm (örneğin, gelen http isteği başına).

Tüm günlük iletileri için, yararlı bağlamı günlüğe kaydettiğinizden emin olun (ve "hata kodları" nı kullanmak yerine iletileri okunabilir / yararlı hale getirmeye öncelik verin)

• HATA AYIKLAMA (ve altı) - Hiç kullanılmamalıdır (ve kesinlikle üretimde değil). Geliştirme aşamasında, kodun günlük ifadeleriyle kirletilmesinin aksine, TDD ve Hata Ayıklama (gerektiğinde) kombinasyonunu kullanmanızı öneririm. Üretimde, yukarıdaki INFO kaydı, diğer metriklerle birlikte yeterli olmalıdır.

Yukarıdaki kayıt seviyelerini görselleştirmenin güzel bir yolu, her bileşen için bir dizi izleme ekranı hayal etmektir. Her şey yolunda gittiğinde yeşil renktedir, eğer bir bileşen bir UYARI kaydederse, bir şey bir HATA kaydederse turuncu (kehribar) olur ve kırmızı olur.

Bir olay olması durumunda bir (temel neden) bileşen kırmızıya ve etkilenen tüm bileşenler turuncu / sarıya gitmelidir.

Diğer cevaplar için farklı değil, çerçevem ​​neredeyse aynı seviyelere sahip:

1. Hata: veritabanı bağlantısı zaman aşımı gibi uygulamadaki kritik mantıksal hatalar. Yakın gelecekte bir hata düzeltmesi gerektiren şeyler
2. Uyarı: kırılmayan sorunlar, ancak dikkat edilmesi gereken şeyler. İstenen bir sayfa bulunamadı gibi
3. Bilgi: fonksiyonlar / yöntemlerde ilk satırda, çağrılan bir prosedürü veya tamamlanmış bir adımı göstermek için kullanılır, örneğin ekleme sorgusu yapıldı
4. log: bir if ifadesinin sonucu gibi mantık bilgileri
5. hata ayıklama: kalıcı olarak izlenecek değişken içerik