TRACE seviyesi neden var ve DEBUG yerine ne zaman kullanmalıyım?

Log4J, Slf4J ve Java'daki diğer birkaç günlük kaydı çerçevesinde, günlük kaydı için iki "geliştirici" seviyeniz vardır:

• DEBUG
• İZ, İŞARET, İPUCU

DEBUG'ın ne yaptığını anlıyorum, çünkü açıklama açıktır:

DEBUG Seviyesi, bir uygulamanın hatalarını ayıklamak için en faydalı olan ince taneli bilgi olaylarını belirler.

Ancak TRACE seviyesi kullanım durumu hakkında çok spesifik değil:

TRACE Seviyesi, DEBUG’dan daha ince taneli bilgilendirme olayları belirler

(Kaynak: log4J JavaDoc )

Bu bana ne zaman ve ne zaman TRACE kullanacağımı söylemez. İlginçtir ki, bu syslog standardında tanımlanan bir önem seviyesi değildir . TRACE ve DEBUG arasındaki farkın googlingi yalnızca “DEBUG kullanın, oh ve TRACE de var” gibi görünüyor. TRACE seviyesi için belirli bir kullanım örneği bulamadım. Bulabildiğim en iyi şey , seviyenin varlığının değerini tartışan bu eski wiki sayfasıydı .

Bu, bir mimar olarak, kafamda birçok bayrak ve soru yükseltir. Genç bir geliştirici benden mimarisine TRACE'i eklememi istedi, onu sorularla bombalardım:

• DEBUG ile değil, TRACE ile kaydedilmesi gereken bazı bilgi örnekleri nelerdir?
• Bu bilgileri günlüğe kaydederek hangi sorunu çözerim?
• Bu örneklerde, DEBUG seviyesinden ziyade TRACE seviyesindeki loglama arasında açıkça ayırım yapan kayıtlı bilgilerin özellikleri nelerdir?
• Bu bilgi neden log altyapısından geçmeli?
  • Bu bilgiyi bir günlükler dergisinde sadece kullanmak yerine sürdürmeye devam etmenin faydaları nelerdir System.out.println?
  • Neden bunun için bir hata ayıklayıcı yerine günlük kullanmak daha iyi?
• TRACE düzeyinde logonun kanonik bir örneği ne olabilir?
  • Örnekte DEBUG yerine TRACE seviyesine giriş yaparak elde edilen spesifik kazançlar nelerdir?
  • Bunlar neden önemli?
  • Tersi: DEBUG yerine TRACE'e giriş yaparak hangi sorunları çözdüm?
  • Bu sorunları başka nasıl çözebilirim? Niçin TRACE seviyesinde giriş yapmak diğer çözümlerden daha iyidir?
• Üretim kodunda TRACE seviye log ifadesi bırakılmalı mı? Neden?

Ancak en büyük çerçevede bulunduğu göz önüne alındığında, bunun bir şeyler için faydalı olduğunu tahmin ediyorum? Öyleyse ... TRACE ne için ve onu DEBUG'dan ayıran nedir?

DEBUG ile değil TRACE ile giriş yapılması gereken bilgilere örnek nedir?

Birkaç adımdan geçen bir algoritmaya sahipsem, izleme seviyesi bu adımların her biri hakkında en iyi seviyede bilgi basacaktır. Her adımın değişmez girdileri ve çıktıları gibi şeyler.

Genel olarak, izleme tüm hata ayıklamayı içerecektir (tıpkı hata ayıklamanın tüm uyarı ve hataları içerdiği gibi).

Bu bilgileri günlüğe kaydederek hangi sorunu çözerim?

Sen çıkarır şey hata ayıklamak gerek yolu çok fazla veri o belirli şeyi hedefliyorsanız ve hatalar veya diğer giriş bilgi (iz bilgi hacmi bunları engelleyebilir çünkü) umurumda değil ne zaman belirli bir yapı dışında giriş yapmak. Bazı kayıt cihazlarında, belirli bir modülü sadece izleme seviyesine çevirirsiniz.

Bu örneklerde, DEBUG seviyesinden ziyade TRACE seviyesindeki loglama arasında açıkça ayırım yapan kayıtlı bilgilerin özellikleri nelerdir?

Genel olarak, izleme düzeyi günlüğü uzun süre açık kalamaz çünkü uygulamanın performansını büyük ölçüde düşürür ve / veya disk / bant genişliği kısıtlamaları nedeniyle sürdürülemeyen bir miktarda günlük verisi oluşturur.

Hata ayıklama seviyesi günlüğü, uygulamayı kullanılamaz duruma getirmeden genellikle daha uzun bir süre açık olabilir.

Bu bilgi neden log altyapısından geçmeli?

Zorunda değil. Bazı çerçevelerde ayrı bir tracelogger vardır

Genellikle günlüklerde sona erer çünkü normalde kayıt yapan kişilerin ve disk / ağa yazma, hata yönetimi, günlük döndürme vb. Konularda benzer ihtiyaçları vardır.

Neden bunun için bir hata ayıklayıcı yerine günlük kullanmak daha iyi?

Çünkü hata ayıklayıcı, sorunlu makineye bağlayamayabilir. Kesme noktalarını nerede ayarlayacağınızı bile bilmeyecek veya kodda ilerleyebilecek kadar bilginiz olmayabilir. Hatayı bir hata ayıklayıcıda güvenilir şekilde yeniden oluşturamayabilirsiniz, bu nedenle "olması durumunda" yakalamak için günlükleri kullanın.

Ama onlar sadece isim. Diğer etiketlerde olduğu gibi, sadece insanların eşyalara koydukları isimlerdir ve genellikle farklı kişiler için farklı şeyler ifade eder. Ve etiketin kendisi, etiketin ifade ettiği etli bitlerden daha az önemlidir.

Slf4j'nin izlemeyi özellikle kullanmamaya özellikle önerdiğini not alın ( http://slf4j.org/faq.html#trace ):

Kısacası, alternatifler mevcut olduğundan veya çoğu durumda TRACE seviyesindeki log taleplerinin israfı olduğu için TRACE seviyesini kullanmaktan caydırmamıza rağmen, insanların talepte bulunmaya devam etmelerine rağmen popüler talebe boyun eğmeye karar verdik.

Şahsen, benim beklentim, her şeyi kaydetme izini sürmek olurdu (örneğin, "Y işlevinde A, B, C argümanları olan MyFunc fonksiyonuna girilen şeyler" gibi şeyler bile). Bunun dezavantajı, yalnızca bu inanılmaz derecede gürültülü olması değil, aynı zamanda disk alanı sorunlarına neden olma eğiliminde olmasıdır; Bu işlemlerin normal işlemler sırasında devre dışı kalmasını beklerdim. Bunun yanı sıra, bunun bir hata ayıklayıcısını takmanın daha az pratik olabileceği durumlarda, programınıza girerken elde edeceğinize benzer bir bilgi düzeyi sağlamasıdır.

Genel olarak, izin genellikle diğer yaklaşımlardan daha fazla çaba olduğunu düşünüyorum.

Genel olarak hata ayıklama düzeyleri tamamen isteğe bağlıdır ve diller, kütüphaneler ve şirketler arasında değişebilir.

Olduğu söyleniyor, işte onları nasıl kullandıklarını gördüm:

TRACE: Lojik seviye program akışını göstermek için kullanılır. Bir fonksiyon girdiniz mi? Bir "if" ifadesi ana mı yoksa "else" dalını mı seçti? Bu iz için bir aday. Başka bir deyişle, izleme günlüğü genellikle "burada olduğunuzu" belirtmek için kullanılır. Bu, bir hata veya diğer bilgileri günlüğe kaydedebilecek diğer günlük ifadesi bağlamında kullanışlıdır. İzleme günlüğü, hatanın yerini veya kodda farklı bir düzeyde günlüğe kaydedilen diğer olayların yerini belirlemenize yardımcı olabilir.

DEBUG: değişken durumu, belirli hata kodlarını, vb. Atmak için kullanılır. Örneğin: bir web servisi, uygulama kullanıcıya "iletişim başarısız" mesajı verirken günlüğe kaydedilebilecek 809214 hata kodunu verebilir. Bir hatanın oluştuktan ve kullanıcının " neden başarısız oldu?" Diye merak ettikten sonra bir kullanıcının sisteminden günlük aldığını düşünün. Bu hata ayıklama düzeyinde oturum açmak için iyi bir şeydir. Başka bir örnek, üretimde bir hata oluşmaya devam etse de, yeniden üretilmesi zorsa, sorunlu modülde bazı değişkenleri veya olayları hata ayıklamak, hata gidermek için hata oluştuğunda geliştiricilere program durumunu anlatmaya yardımcı olmak için hata ayıklama modülünde bazı hata ayıklama günlüğü hata ayıklaması olabilir.

Normalde biri uygulamayı belirli bir düzeyde (veya daha yüksek) oturum açacak şekilde yapılandırır. Örneğin, izleme genellikle en düşük seviyedir: o seviyede oturum açmak her şeyi kaydeder. Hata ayıklama seviyesi iz bırakabilir, ancak yüksek düzeyler içerir (örn. Uyarılar ve hatalar).

Günlük seviyelerini ayırmanın faydası, kaydedilen tutarı kontrol etmektir. Karmaşık bir uygulama için, izleme günlüğü, çoğu zaman işe yaramaz olan büyük miktarda veriyi potansiyel olarak kaydedebilir. Bir hataya neden olmak istemediği sürece sadece kritik bilgileri (belki bazı başlangıç ​​bilgilerini, ardından sadece hataları) kaydetmek en iyisidir . Ayrıca, bu genellikle bir üretim ortamında hata ayıklayıcılar olduğu ve diğer geliştirme araçlarının bulunmadığı durumlarda sadece faydalıdır.

Bunun için gerçek bir sınır yok, kesin bir şekilde giriş yapmanız gerektiğini söyleyen kurallar yok. Yalnızca bazı kitaplıkların veya uygulamaların uygulayabileceği veya uygulayamayacağı geniş sözleşmeler.

Bence Telastyn’in mükemmel cevabı kısa kuralıma göre özetlenebilir:

• DEBUG Tomruk üretimi üretimde kullanabilmelidir (ancak hala normalde kapalı olma eğilimindedir).
• TRACE kayıtların üretimde kullanılmasının (belirli / kısa bir seans dışında) mümkün olmadığı şekilde kaydedilmesine izin verilir.

İşte 'benim kural benim

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

Bunun arkasındaki varsayım ops ekibinin yapacağı

• her zaman üretimin log-level bilgisi olarak ayarlanması
• üretimi log-debug olarak ayarlamış olabilirsiniz.
• asla log seviyesindeki izlemeye ayarlanmamış

Bu varsayımla donanmış olarak, bir geliştirici olarak log seviyelerini nasıl kullanabileceğinizi işte ...

Sorun # 1) üretim performansını çok yavaşlatmıyor

debug# 1 çözüyor. Geliştirici olarak, üretimde ihtiyaç duyabileceğiniz bilgileri makineyi yavaşlatırken fazla gürültü yapmadan dengelemek için elinizden geleni yapıyorsunuz. “İsterseniz bunu üretimde sürekli olarak kaydetmek iyi bir fikirdir” diyorsunuz.

Problem # 2) geliştirilirken ayrıntılı bilgilere sahip olmak

trace2 numaralı sorunu çözer. Bir üretim makinesi üzerinde ne gibi bir etkisinin olacağı konusunda hiçbir endişeniz yok, ancak kodu geliştirmek için şu anda bu bilgiye ihtiyacınız var. “Bu bilgiyi her zaman üretime kaydetmenin iyi bir fikir olacağına dair hiçbir söz vermiyorum” diyorsunuz.

Verilmiş (başkalarının söylediği gibi), bunlar keyfidir; bu nedenle, geliştirme ekibinizin (ve ops / izleme ekibi - çünkü onlar da günlüğe kaydetmenizin kullanıcılarıdır) bir konuda hemfikir olun.

TRACE düzeyinde logonun kanonik bir örneği ne olabilir?

ENTRY / EXIT bir yöntemden günlüğe kaydeder. Bu günlükler yardımcı iz programın akışını ve ne zaman çok yararlı olurlar:

1. Program aniden çöküyor - kütüğün son satırına bakarak tam olarak hangi işlevi düştüğünü biliyorsunuz.

2. Bazı hileli işlev bir istisna emerek sessizce başarısız oluyor

Sadece DEBUG kullanmak yerine ayrı bir TRACE seviyesi garanti ediyorlar, çünkü kod tabanınızdaki her yöntem için ENTRY / EXIT günlüklerinin etkinleştirilmesi , DEBUG bağlamında bile her zaman açık olmayan muazzam miktarda ekstra günlükler oluşturacak .