Farklı günlük düzeyleri ne zaman kullanılır?

Fatality sırasına göre iletileri günlüğe kaydetmenin farklı yolları vardır:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Hangisini ne zaman kullanacağım nasıl karar veririm?

Kullanılacak iyi bir buluşsal yöntem nedir?

Genellikle aşağıdaki sözleşmeye abone olurum:

• Trace - Ben sadece kodu "izleme" ve özellikle bir fonksiyonun bir bölümünü bulmaya çalışırken .
• Hata Ayıkla - Yalnızca geliştiricilerden (BT, sistem yöneticileri, vb.) Daha fazla insanlara teşhis amaçlı yardımcı olan bilgiler.
• Bilgi - Günlüğe kaydedilmek için genellikle yararlı bilgiler (servis başlatma / durdurma, yapılandırma varsayımları, vb.). Bilgi Her zaman elimde olmak istiyorum ancak normal şartlar altında umurumda değil. Bu, kullanıma hazır yapılandırma düzeyim.
• Uyar - Potansiyel olarak uygulama tuhaflıklarına neden olabilecek, ancak otomatik olarak iyileştiğim her şey. (Birincil sunucudan yedekleme sunucusuna geçmek, bir işlemi yeniden denemek, ikincil verileri kaçırmak vb.)
• Error - İşlem veya ölümcül olan ancak hizmet veya uygulama için önemli olmayan herhangi bir hata (gerekli bir dosyayı açamıyor, eksik veriler vb.). Bu hatalar kullanıcının (yönetici veya doğrudan kullanıcı) müdahalesini zorlar. Bunlar genellikle (uygulamalarımda) yanlış bağlantı dizeleri, eksik hizmetler vb. İçin ayrılır.
• Fatal - Veri kaybını (veya daha fazla veri kaybını) önlemek için hizmet veya uygulamanın kapanmasını zorlayan herhangi bir hata. Bunları yalnızca en kötü hatalar ve veri bozulması veya kaybı olduğu garanti edilen durumlar için saklıyorum.

Mesajın gece yarısı sistem yöneticisini yataktan çıkarmasını ister misiniz?

• evet -> hata
• hayır -> uyar

Günlük dosyasını görüntüleme açısından ciddiyetleri düşünmeyi daha yararlı buluyorum.

Ölümcül / Kritik : Derhal araştırılması gereken genel uygulama veya sistem hatası. Evet, SysAdmin'i uyandırın. SysAdmins uyarımızı ve iyi dinlenmemizi tercih ettiğimizden, bu önem derecesi çok seyrek kullanılmalıdır. Her gün oluyor ve bu bir BFD değilse, anlamını yitirdi. Tipik olarak, önemli bir hata işlem ömründe yalnızca bir kez oluşur, bu nedenle günlük dosyası işleme bağlıysa, bu genellikle günlükteki son iletidir.

Hata : Kesinlikle araştırılması gereken bir sorun. SysAdmin otomatik olarak bilgilendirilmelidir, ancak yataktan dışarı sürüklenmesi gerekmez. Bir günlüğü hatalara bakmak için filtreleyerek ve yukarıda hata frekansına genel bir bakış elde edersiniz ve ek hataların artmasına neden olabilecek başlatma hatasını hızlı bir şekilde belirleyebilirsiniz. Uygulama kullanımına karşı hata oranlarını izleme, MTBF gibi genel kaliteyi değerlendirmek için kullanılabilecek faydalı kalite ölçütleri sağlayabilir. Örneğin, bu metrik, bir sürümden önce başka bir beta test döngüsünün gerekip gerekmediğine ilişkin kararların bildirilmesine yardımcı olabilir.

Uyarı : Bu sorun olabilir veya olmayabilir. Örneğin, kısa ağ kaybı veya veritabanı bağlantısı gibi beklenen geçici ortam koşulları Hatalar yerine Uyarılar olarak kaydedilmelidir. Yalnızca uyarıları ve hataları göstermek için filtrelenmiş bir günlüğü görüntülemek, sonraki hatanın temel nedenindeki erken ipuçlarına hızlı bir bakış sağlayabilir. Uyarılar anlamsız hale gelmemek için idareli kullanılmalıdır. Örneğin, ağ erişiminin kaybedilmesi bir sunucu uygulamasında bir uyarı hatta bir hata olmalıdır, ancak yalnızca bağlantısı kesilmiş dizüstü bilgisayar kullanıcıları için tasarlanmış bir masaüstü uygulamasındaki Bilgi olabilir.

Bilgi : Bu, başarılı başlatma, hizmet başlatma ve durdurma veya önemli işlemlerin başarıyla tamamlanması gibi normal koşullar altında kaydedilmesi gereken önemli bilgilerdir. Bilgi ve yukarısını gösteren bir günlüğü görüntülemek, gerçekleşen uyarıları veya hataları anlamak için en üst düzey bağlam sağlayan süreçteki önemli durum değişikliklerine hızlı bir genel bakış sunmalıdır. Çok fazla Bilgi mesajınız yok. İz ile ilgili olarak genellikle <% 5 Bilgi mesajımız vardır.

İz : İz, en yaygın kullanılan şiddettir ve hatalara ve uyarılara yol açan adımları anlamak için bağlam sağlamalıdır. İzleme mesajlarının doğru yoğunluğuna sahip olmak, yazılımı çok daha sürdürülebilir hale getirir, ancak programlar geliştikçe bireysel İzleme ifadelerinin değeri zaman içinde değişebileceğinden, biraz özen gerektirir. Bunu başarmanın en iyi yolu, geliştirici ekibinin günlükleri, müşteri tarafından bildirilen sorunları gidermenin standart bir parçası olarak düzenli olarak inceleme alışkanlığı haline getirmektir. Ekibi, artık yararlı içerik sağlamayan İletileri takip etme ve sonraki iletilerin içeriğini anlamak için gerektiğinde ileti eklemeye teşvik etme. Örneğin, ekranları veya sekmeleri değiştirmek gibi kullanıcı girişlerini kaydetmek genellikle yararlıdır.

Hata Ayıklama : Hata Ayıklama <İz'i düşünüyoruz. Ayıklama iletileri Sürüm derlemeleri dışında derlenir. Bununla birlikte, Hata Ayıklama mesajlarının kullanılmasını önermiyoruz. Hata Ayıklama iletilerine izin vermek, giderek daha fazla Hata Ayıklama iletisinin eklenmesine ve hiçbirinin kaldırılmamasına neden olur. Zamanla, bu günlük dosyalarını neredeyse işe yaramaz hale getirir, çünkü gürültüyü sinyalden filtrelemek çok zordur. Bu, geliştiricilerin ölüm spiralini devam ettiren günlükleri kullanmamasına neden olur. Buna karşılık, sürekli budama İzleme mesajları, geliştiricileri onları erdemli bir sarmalla sonuçlamaya teşvik eder. Ayrıca bu, sürüm derlemesinde yer almayan hata ayıklama kodunda gerekli yan etkiler nedeniyle ortaya çıkan hata olasılığını ortadan kaldırır. Evet, bunun iyi kodda olmaması gerektiğini biliyorum, ama üzgünüm o zaman daha güvenli.

İşte "kaydedicilerin" sahip oldukları bir liste.

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] muhtemelen uygulamanın durdurulmasına neden olacak çok ciddi hata olayları.

   [ v2.0 : ..] uygulamanın devam etmesini engelleyecek ciddi hata.

2. ERROR:

   [ v1.2 : ..] uygulamanın çalışmaya devam etmesine izin verebilecek hata olayları.

   [ v2.0 : ..] uygulamada hata, muhtemelen kurtarılabilir.

3. WARN:

   [ v1.2 : ..] potansiyel olarak zararlı durumlar.

   [ v2.0 : ..] olayı [ sic ] bir hataya neden olabilir .

4. INFO:

   [ v1.2 : ..] uygulamanın kaba taneli düzeyde ilerlemesini vurgulayan bilgilendirici mesajlar.

   [ v2.0 : ..] bilgilendirme amaçlı etkinlik.

5. DEBUG:

   [ v1.2 : ..] bir uygulamada hata ayıklamak için en yararlı olan ayrıntılı bilgi olayları.

   [ v2.0 : ..] genel hata ayıklama olayı.

6. TRACE:

   [ v1.2 : ..] .'dan daha ince taneli bilgilendirme olayları DEBUG.

   [ v2.0 : ..] tipik olarak uygulama içinden akışı yakalayan ince taneli hata ayıklama mesajı.

Apache Httpd (her zamanki gibi) aşırıya kaçmayı sever: §

1. ortaya çıktı :

   Acil durumlar - sistem kullanılamaz.

2. uyarı :

   İşlem hemen yapılmalıdır [ancak sistem hala kullanılabilir].

3. ölçüt :

   Kritik Koşullar [ancak hemen önlem alınması gerekmez].

   • " socket: Bir yuva alınamadı, alttan çıkılıyor "

4. hata :

   Hata koşulları [ancak kritik olmayan].

   • " Komut dosyası başlıklarının erken sonu "

5. uyar :

   Uyarı koşulları. [hataya yakın, ancak hata değil]

6. uyarı :

   Normal fakat önemli [ kayda değer ] durum.

   • " Httpd: yakalanmış SIGBUS, içinde çekirdek dökümü çalışırken ... "

7. bilgi :

   Bilgilendirici [ve bilinemez].

   • [" Sunucu x saattir çalışıyor. "]

8. hata ayıklama :

   Ayıklama seviyesi mesajları [yani, mesajlar uğruna kaydedilir de-rahatsız )].

   • " Yapılandırma dosyası açılıyor ... "

9. trace1 → trace6 :

   İzleme mesajları [yani izleme amacıyla kaydedilen mesajlar ].

   • " proxy: FTP: kontrol bağlantısı tamamlandı "
   • " proxy: CONNECT: uzak proxy'ye CONNECT isteği gönderme "
   • " openssl: El sıkışma: başlat "
   • " arabelleğe alınmış SSL tugayından okuyun, mod 0, 17 bayt "
   • " harita arama BAŞARISIZ:map=rewritemap key=keyname "
   • " önbellek araması BAŞARISIZ, yeni harita aramayı zorladı "

10. trace7 → trace8 :

    İletileri izleyin, büyük miktarda veri dökün

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache ortak günlük kaydı: §

1. ölümcül :

   Erken sonlandırmaya neden olan ciddi hatalar. Bunların bir durum konsolunda hemen görünmesini bekleyin.

2. hata :

   Diğer çalışma zamanı hataları veya beklenmeyen durumlar. Bunların bir durum konsolunda hemen görünmesini bekleyin.

3. uyar :

   Kullanımdan kaldırılmış API'ların kullanımı, API'nın yetersiz kullanımı, 'neredeyse' hatalar, istenmeyen veya beklenmeyen diğer çalışma zamanı durumları, ancak mutlaka "yanlış" değildir. Bunların bir durum konsolunda hemen görünmesini bekleyin.

4. bilgi :

   İlginç çalışma zamanı olayları (başlatma / kapatma). Bunların bir konsolda hemen görünmesini bekleyin, bu nedenle muhafazakar olun ve minimumda tutun.

5. hata ayıklama :

   sistemden geçen akış hakkında ayrıntılı bilgi. Bunların yalnızca günlüklere yazılmasını bekleyin.

6. iz :

   daha ayrıntılı bilgi. Bunların yalnızca günlüklere yazılmasını bekleyin.

Apache ortak girişimlerini kurumsal kullanım için "en iyi uygulamaları" günlüğe kaydetme , ne tür sınırları aştıklarına bağlı olarak hata ayıklama ve bilgi arasında bir ayrım yapar .

Sınırlar şunları içerir:

• Dış Sınırlar - Beklenen İstisnalar.

• Dış Sınırlar - Beklenmeyen İstisnalar.

• İç Sınırlar.

• Önemli İç Sınırlar.

( Bununla ilgili daha fazla bilgi için ortak günlük kaydı kılavuzuna bakın .)

Sorundan kurtulabilirseniz, bu bir uyarıdır. Devam eden yürütmeyi engelliyorsa, bu bir hatadır.

Syslog önem düzeylerini benimsemenizi öneririm DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Bkz. Http://en.wikipedia.org/wiki/Syslog#Severity_levels

Çoğu kullanım durumu için yeterli düzeyde ince önem derecesi sağlamalı ve mevcut günlük ayrıştırıcılar tarafından tanınmalıdır. Tabii ki yalnızca bir alt kümeyi uygulama özgürlüğünüz olsa da, örneğin DEBUG, ERROR, EMERGENCYuygulamanızın gereksinimlerine bağlı olarak.

Yaptığımız her farklı uygulama için kendi standardımızı bulmak yerine, uzun zamandır var olan bir şey üzerinde standartlaşalım. Günlükleri toplamaya başladığınızda ve farklı olanlar arasındaki kalıpları algılamaya çalıştığınızda gerçekten yardımcı olur.

Kurtarma yapabileceğiniz uyarılar. Yapamayacağınız hatalar. Bu benim sezgiselim, başkalarının başka fikirleri olabilir.

Örneğin, adı "Angela Müller"uygulamanıza girdiğinizi / içe aktardığınızı varsayalım (üzerindeki imleci not edin u). Kodunuz / veritabanınız yalnızca İngilizce olabilir (muhtemelen bu gün ve yaşta olmamalıdır ) ve bu nedenle tüm "alışılmadık" karakterlerin normal İngilizce karakterlere dönüştürüldüğü konusunda uyarabilir.

Bu bilgiyi veritabanına yazmaya ve 60 saniye boyunca bir ağ kesintisi mesajını geri almaya çalışırken kontrast yapın. Bu bir uyarıdan çok bir hatadır.

Diğerlerinin söylediği gibi, hatalar problemdir; uyarılar potansiyel problemlerdir.

Geliştirme aşamasında, bir onaylama hatası eşdeğerini koyabileceğim, ancak uygulamanın çalışmaya devam edebileceği uyarıları sıklıkla kullanıyorum; bu, o vakanın gerçekten olup olmadığını ya da benim hayal gücüm olup olmadığını öğrenmemi sağlar.

Ama evet, kurtarılabilirlik ve gerçekçilik boyutlarına iniyor. Eğer iyileşebilirseniz, bu muhtemelen bir uyarıdır; bir şeyin gerçekten başarısız olmasına neden olursa, bu bir hatadır.

SYSLOG düzeylerinin BİLDİRİM ve UYARI / ACİL DURUMUNUN uygulama düzeyinde günlük kaydı için büyük ölçüde gereksiz olduğunu düşünüyorum - EĞİTİM / UYARI / ACİL DURUM bir uygulama yöneticisi için farklı eylemleri ve bildirimleri tetikleyebilecek bir operatör için yararlı uyarı seviyeleri olabilir. ÖLÜMCÜL. Ve bir uyarı veya bazı bilgiler verilmesi arasında yeterince ayrım yapamıyorum. Eğer bilgi kayda değer değilse, gerçekten bilgi değildir :)

Jay Cincotta'nın yorumunu en iyi şekilde seviyorum - kodunuzun yürütülmesini izlemek teknik destekte çok yararlı bir şeydir ve özellikle belirli uygulama bileşenlerinden izleme mesajlarını kaydetmek için dinamik bir filtreleme mekanizması ile birlikte, izleme ifadelerini koda liberal olarak koymak teşvik edilmelidir. Ancak DEBUG seviyesi bana hala neler olup bittiğini anlamaya devam ettiğimizi gösteriyor - DEBUG seviye çıktısını bir üretim günlüğünde gösterilmesi gereken bir şey olarak değil, sadece geliştirme seçeneği olarak görüyorum.

Ancak OPERATIONAL mesajları için bir sistem yöneticisinin şapkası kadar teknik destek ve hatta geliştirici: OPER kadar giyerken hata günlüklerimde görmek istediğim bir kayıt seviyesi var. Bu bir zaman damgası, çağrılan işlem türü, sağlanan bağımsız değişkenler, muhtemelen (benzersiz) görev tanımlayıcısı ve görev tamamlama günlüğü için kullanın. Örneğin, bağımsız bir görev başlatıldığında, daha büyük ve uzun süren uygulama içinden gerçek bir çağrı olan bir şey kullanılır. Bu, her zaman günlüğe kaydedilmesini istediğim bir şey, bir şeylerin yanlış olup olmadığına bakılmaksızın, OPER seviyesinin FATAL'den daha yüksek olduğunu düşünüyorum, bu yüzden sadece tamamen sessiz moda geçerek kapatabilirsiniz. Ve sadece INFO günlük verilerinden çok daha fazlasıdır - hiçbir tarihsel değere sahip olmayan küçük operasyonel mesajlarla günlükleri spam yapmak için kötüye kullanılan bir günlük seviyesi.

Durumun gerektirdiği gibi, bu bilgi ayrı bir çağrı günlüğüne yönlendirilebilir veya daha fazla bilgi kaydeden büyük bir günlükten süzülerek elde edilebilir. Ancak, tarihsel bilgi olarak, ne yapıldığını bilmek her zaman gereklidir - AUDIT seviyesine inmeden, arızalar veya sistem çalışması ile ilgisi olmayan tamamen ayrı bir günlük seviyesi, yukarıdaki seviyelere gerçekten uymuyor ( önem derecesi sınıflandırmasına değil, kendi kontrol anahtarına ihtiyaç duyduğu için) ve kesinlikle kendi ayrı günlük dosyasına ihtiyaç duyar.

RFC 5424'ten Syslog Protokolü (IETF) - Sayfa 10:

Her bir Öncelik mesajı ayrıca ondalık Önem Derecesi seviye göstergesine sahiptir. Bunlar, sayısal değerleri ile birlikte aşağıdaki tabloda açıklanmıştır. Önem derecesi değerleri 0 ila 7 dahil olmalıdır.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

İyi günler,

Bu sorunun bir sonucu olarak, günlük düzeyleri hakkındaki yorumlarınızı iletin ve bir projedeki tüm kişilerin düzeylerin yorumlanmasında hizalandığından emin olun.

Şiddetlerin ve seçilen günlük seviyelerinin tutarsız olduğu çok çeşitli günlük mesajlarını görmek acı vericidir.

Mümkünse farklı günlük kaydı düzeylerine örnekler verin. Ve bir iletiye kaydedilecek bilgilerde tutarlı olun.

HTH

Diğerlerine tamamen katılıyorum ve GrayWizardx'ın en iyi dediğini düşünüyorum.

Ekleyebileceğim tek şey, bu seviyelerin genellikle sözlük tanımlarına karşılık gelmesidir, bu yüzden bu zor olamaz. Şüpheniz varsa, bir bulmaca gibi davranın. Projeniz için, günlüğe kaydetmek isteyebileceğiniz her şeyi düşünün.

Şimdi, neyin ölümcül olabileceğini anlayabilir misiniz? Ölümcül ne demek biliyorsun, değil mi? Listenizdeki hangi öğelerin ölümcül olduğu.

Tamam, bu ölümcül halledildi, şimdi hatalara bakalım ... durulayın ve tekrarlayın.

Ölümcül veya Belki Hata altında, daha fazla bilgi her zaman daha az daha iyi olduğunu, bu yüzden hata "yukarı" öneririz. Bilgi veya Uyarı olup olmadığından emin değil misiniz? Sonra bir uyarı yapın.

Ölümcül ve hatanın hepimiz için açık olması gerektiğini düşünüyorum. Diğerleri daha bulanık olabilir, ancak onları düzeltmek muhtemelen daha az hayati.

İşte bazı örnekler:

Ölümcül - bellek, veritabanı vb. Ayıramaz - devam edemez.

Hata - mesaja cevap yok, işlem iptal edildi, dosya kaydedilemiyor, vb.

Uyarı - kaynak ayırma% X'e (% 80 diyelim) ulaşır - bu, yeniden boyutlandırmak isteyebileceğiniz bir işarettir.

Bilgi - kullanıcı oturum açmış / oturmuş, yeni işlem, sandıklı dosya, yeni d / b alanı veya alan silindi.

Hata ayıklama - dahili veri yapısının dökümü, dosya adı ve satır numarası ile her şey izleme düzeyi.
İzleme - işlem başarılı / başarısız, d / b güncellendi.

Bir hata yanlış, basit yanlış, etrafında bir yol yok, düzeltilmesi gerekiyor.

Uyarı, olabilecek bir modelin işaretidir. yanlış ancak sonra da olmayabilecek .

Bunu söyledikten sonra, aynı zamanda hata olmayan bir uyarıya iyi bir örnek bulamıyorum. Bununla kastettiğim, bir uyarıyı günlüğe kaydetme sorununa giderseniz, alttaki sorunu da çözebilirsiniz.

Ancak, "sql yürütme çok uzun sürüyor" gibi şeyler bir uyarı olabilir, "sql yürütme kilitlenmeleri" bir hata, belki de sonuçta bazı durumlar vardır.

Her zaman ilk günlük düzeyini bir sorun olduğu anlamına gelen uyarı olarak düşündüm (örneğin, belki bir yapılandırma dosyası olması gereken yerde değildir ve varsayılan ayarlarla çalışmak zorundayız). Bir hata, bana göre, yazılımın ana amacının imkansız olduğu anlamına geliyor ve temiz bir şekilde kapanmaya çalışacağız.

Ben daha önce aşağıdakileri kullanmak sistemleri inşa ettik:

1. HATA - bir şeyin ciddi şekilde yanlış olduğu ve belirli bir iş parçacığının / işlem / dizinin devam edemeyeceği anlamına gelir. Bazı kullanıcı / yönetici müdahalesi gerekiyor
2. UYARI - bir şey doğru değil, ancak süreç daha önce olduğu gibi devam edebilir (örneğin, 100'lük bir kümedeki bir iş başarısız oldu, ancak geri kalanı işlenebilir)

Yaptığım sistemlerde yöneticiler ERROR'lara tepki vermek için talimat altındaydı. Öte yandan, UYARILARI izler ve her durum için herhangi bir sistem değişikliği, yeniden yapılandırma vb. Gerekip gerekmediğini belirleriz.

Btw, ben her şeyi yakalamak ve bilgileri daha sonra filtrelemek için büyük bir hayranıyım.

Uyarı düzeyinde yakalar ve uyarı ile ilgili bazı Hata Ayıklama bilgileri istiyor, ancak uyarıyı yeniden oluşturamazsanız ne olurdu?

Her şeyi yakalayın ve daha sonra filtreleyin!

İşlemcinizin dayanamadığını bulamazsanız, gömülü yazılım için bile bu geçerlidir, bu durumda izlemenizi daha verimli hale getirmek için yeniden tasarlamak isteyebilirsiniz veya izleme zamanlamaya müdahale edebilir ( hata ayıklamayı düşünebilirsiniz) daha güçlü bir işlemci, ancak bu solucanların bir kısmını açar).

Her şeyi yakalayın ve daha sonra filtreleyin !!

(btw, her şeyi yakalama da iyidir, çünkü hata ayıklama izini göstermekten daha fazlasını yapmak için araçlar geliştirmenize izin verir (benimki Mesaj Dizisi Grafiklerini ve bellek kullanımının histogramlarını çiziyorum. gelecek (başarılı olsun veya olmasın tüm günlükleri saklayın ve günlük dosyasına derleme numarasını eklediğinizden emin olun)).

İki sentim FATALve hakkındaTRACE hata günlüğü düzeyleri.

ERROR bazı HATA (istisna) oluştuğundadır.

FATAL aslında ÇİFT HATA: istisna işlenirken istisna oluştuğunda.

Web hizmeti için anlaşılması kolaydır.

1. İstek geliyor. Etkinlik olarak günlüğe kaydedilirINFO
2. Sistem düşük disk alanı algılar. Etkinlik olarak günlüğe kaydedilirWARN
3. İsteği işlemek için bazı işlevler çağrılır. Sıfıra bölünme işlemi yapılırken gerçekleşir. Etkinlik olarak günlüğe kaydedilirERROR
4. Web hizmetinin istisna işleyicisi, bölümü sıfıra işlemek için çağrılır. Web hizmeti / çerçevesi e-posta gönderecek, ancak posta hizmeti şu anda çevrimdışı olduğu için kullanılamıyor. Web hizmetinin özel durum işleyicisi özel durumu işleyemediğinden, bu ikinci özel durum normal olarak işlenemiyor.
5. Farklı istisna işleyicisi çağrıldı. Etkinlik olarak günlüğe kaydedilirFATAL

TRACEfonksiyon giriş / çıkışını takip edebildiğimiz zamandır. Bu, günlüğe kaydetme ile ilgili değildir, çünkü bu ileti bazı hata ayıklayıcılar tarafından oluşturulabilir ve kodunuz hiç çağrılmaz log. Dolayısıyla uygulamanızdan olmayan iletiler TRACEseviye gibi işaretlenir . Örneğin, uygulamanızıstrace

Yani genellikle programında yapmanız DEBUG, INFOve WARNgünlüğü. Ve sadece bazı web hizmeti / çerçeve yazıyorsanız kullanacaksınız FATAL. Ve uygulama hata ayıklama zaman TRACEbu tür bir yazılım günlüğü alacak .

Sadece üç seviye kullanmanızı öneririm

1. Fatal - Uygulamayı bozar.
2. Bilgi - Bilgi
3. Hata ayıklama - Daha az önemli bilgi