.NET'te günlüğe kaydetme ve izleme için en iyi yöntemler

Bu konuda en iyi uygulamalar için bazı altın kurallar bulmaya çalışarak izleme ve kaydetme hakkında çok şey okudum, ancak hiçbiri yok. İnsanlar, iyi programcıların iyi izler ürettiğini söylüyorlar, ancak bu şekilde koymak ve deneyimlerden gelmesi gerekiyor.

Ayrıca burada ve internette benzer soruları okudum ve sorduğum aynı şey değiller veya tatmin edici bir cevabım yok, belki de sorular biraz ayrıntısız olduğu için.

Bu nedenle, millet, izlemenin hata ayıklayıcı ekleyemediğiniz durumlarda uygulamada hata ayıklama deneyimini çoğaltması gerektiğini söylüyor. Uygulamadaki her kontrol noktasında hangi yolun izlendiğini görebilmeniz için yeterli bağlam sağlamalıdır.

Daha derine inerken, "olay günlüğü ayrıntılı kontrol akışı yerine ana durumları yakaladığından izlemekten farklıdır" şeklinde izlemeyle olay günlüğü arasında ayrım yapabilirsiniz.

Şimdi, sadece adlandırma alanındakiler gibi standart .NET sınıflarını kullanarak izleme ve günlüğe kaydetme yapmak istediğimi söyleyin System.Diagnostics. TraceSource sınıfının iş için statik Trace sınıfından daha iyi olduğunu düşündüm, çünkü izleme düzeylerini ayırt etmek istiyorum ve TraceSource sınıfını kullanarak kullanmak istediğim olay türünü bildiren bir parametrede geçirebilirim. Trace.WriteLineIfve sonra ve gibi şeyleri doğrulayın SourceSwitch.TraceInformationve SourceSwitch.TraceErrorshatta TraceVerboseveya gibi özelliklere sahip değil TraceStart.

Tüm bunları göz önünde bulundurarak, aşağıdaki gibi yapmak için iyi bir uygulama düşünür müsünüz:

• Tek bir mantıksal işlemi veya bir boru hattını temsil etmesi gereken bir yönteme başlarken, yönteme iletilen parametre değerlerinin bir dize gösterimi ile birlikte bir "Başlat" olayı izleyin.
• Veritabanına bir öğe eklerken bir "Bilgi" olayı izleyin.
• Önemli bir if / else ifadesinde bir yoldan veya bir başkasından giderken bir "Bilgi" olayı izleyin.
• Bir kurtarılabilir hata olup olmadığına bağlı olarak bir "Critical" veya "Error" komutunu bir catch bloğunda izleyin.
• Yöntemin yürütülmesini bitirirken bir "Dur" olayı izleyin.

Ayrıca, Ayrıntılı ve Uyarı olay türlerini izlemek için en iyi zamanları açıklığa kavuşturun. Güzel iz / günlüğe kaydetme ve paylaşmaya istekli kod örnekleri varsa, bu mükemmel olurdu.

Not: Burada bazı iyi bilgiler buldum, ancak aradığım şeyi hala bulamadım: http://msdn.microsoft.com/en-us/magazine/ff714589.aspx

İzleme türlerinin önemi, izlemenin kodun bulunduğu yer nedeniyle değil, izlenen iletinin az ya da çok önemli olması nedeniyle seçilmelidir. Örnek:

Tek bir mantıksal işlemi veya bir boru hattını temsil etmesi gereken bir yönteme başlarken, yönteme iletilen parametre değerlerinin bir dize gösterimi ile birlikte bir "Başlat" olayını izleyin.

Mantıksal bir işlemi başlatırken başlangıç ​​türünü kullanın. Bu, başlatma izinin bir yöntemin başında olması gerektiği veya bir yöntemin başlangıç ​​izlemesi olması gerektiği anlamına gelmez.

Bu söyleniyor, çoğu durumda, mantıksal bir işlem aslında yöntemin başında başlayacak. Aksi halde, kodun doğru şekilde düzeltilip düzeltilmediğini kendinize sormalısınız.

Parametrelerin izlenmesi de kötü bir fikir olabilir . Ne izleyeceğini düşünmelisin, duruma göre. Örneğin, bir yöntemin parametrelerini izlemek gerçekten kötüdür void Authenticate(string userName, string plainPassword).

Veritabanına bir öğe eklerken bir "Bilgi" olayı izleyin.

Değişir. Bazı öğeler izlenmeli, ancak her öğe kullanılmamalıdır.

• Örneğin, aslında veritabanınıza bir günlük öğesi eklediğinizi düşünün. Günlükleri takip eder misiniz? Ve sonra izleri günlüğe? Ve sonra iz günlüğünü takip?
• Başka bir örnek: Hassas bir veri ekliyorsunuz. Bu denetim gerektirir. Yerleştirmeyi denetlediğinden beri, neden takip ediyorsun?

Önemli bir if / else ifadesinde bir yoldan veya bir başkasından giderken bir "Bilgi" olayı izleyin.

Yine, buna bağlı.

Hava durumuna bağlı olarak bir "Critical" veya "Error" ifadesini yakalama bloğunda izleyin; bu kurtarılabilir bir hatadır.

Kurtarılamayan bir hatadan sonra yapılan işlem izlemekten daha fazlası olabilir. Örneğin sunucu tarafında, daha fazla analiz için istisnayı veritabanında saklamak istersiniz. Ayrıca, bazı istisnalar diğerlerinden daha az önemlidir ve izleme gerektirmez.

Yöntemin yürütülmesini bitirirken bir "Dur" olayı izleyin.

İlk noktaya bakınız.

Lütfen Ayrıntılı ve Uyarı olay türlerini izlemek için en iyi zamanı açıklığa kavuşturun.

ayrıntılı:

Verbose, bir şeyler gerçekten ters gittiğinde, izlemeniz gerekenleri izlemek için kullanılır. Bu, çoğu durumda, ayrıntılı iletilerin izlenmesini devre dışı bırakacağınız anlamına gelir; ancak bazen, neden bir uçta sorun çıkmadığını anlamak için kodunuzun bazı bölümlerinde hata ayıklamanız gerekir.

Genellikle uygulama akışını gerçekten iyi anlamanızı sağlayan çok sayıda ayrıntılı mesajınız vardır. Ayrıca, bu mesajların çoğu zaman devre dışı bırakılması gerektiği anlamına gelir çünkü:

• Aksi halde, günlük çok hızlı büyüyecek,
• Onlara çoğu zaman ihtiyacın yok.
• uygulama akışı hakkında hassas veriler içerebilirler.

Ayrıntılı hata ayıklayıcısına erişiminiz olmadığında kullanmak zorunda olduğunuz bir araç olarak düşünün.

Uyarı:

Uyarı tipi izi, yanlış ve önemli bir şey olduğunda kullanılır, ancak hata olarak değerlendirilemeyecek kadar önemli değildir. Örneğin, düşük RAM bir uyarı verebilir, ancak uygulamanız normalden daha yavaş olsa bile devam edebildiği için bir hatayı izlemek için hiçbir neden yoktur.

Örnekler:

• Örnek 1: uygulama, kullanıcının açmasını istediği dosyayı açamadı. Dosya var ve kullanımda değil, izinler doğru ayarlanmış, ancak bir şey dosyanın açılmasını engelliyor. Bu durumda, uygulamanız bu davayı yönetemediğinden ve kullanıcı tarafından beklendiği şekilde çalışmaya devam edemediğinden bir hatayı takip edeceksiniz (yani dosyayı okumalı).

• Örnek 2: ilk örnekte hatanın incelenmesinden sonra, hatanın dosya yolunun 259 karakterden daha uzun olması nedeniyle ortaya çıktığını tespit edersiniz. Yani yakalamak için kodunuzu yeniden yansıtıyorsunuz PathTooLongException. Kullanıcı bir dahaki sefere aynı dosyayı açmaya çalıştığında, uygulamanın yeni sürümü dosyanın çok uzun olduğunu ve bu dosyayı açmak için tam yolu kısaltmak için başka bir klasöre taşınması gerektiğini açıklayan bir mesaj gösterir. bu başvuru. Ayrıca bir mesaj izlersiniz .

• Örnek 3: başvurunuz küçük bir dosyayı açmak ve ayrıştırmak için yirmi saniye harcadı, çoğu dosya açmak ve ayrıştırmak için on ila yüz milisaniye sürüyor. İlgili bilgileri içeren bir uyarı izlersiniz: Dosyanın gerçekte bulunduğu diskin türü, dosya sistemi, dosyanın boyutu, harcanan süre, bilgisayarın açık olduğu süre, vb. dosyayı açmak için birkaç saniye, ne olacağını bulmak için izini sürersiniz. Örneğin, bilgisayar yeni başlatıldığında dosyaların bir ağ paylaşımından yüklenmesi çok uzun sürüyor. Kullanıcıya gecikmenin ağdan kaynaklandığını ve uygulamanızla ilgili olmadığını açıklarsınız.

• Örnek 4: Açılan dosya yanlış görüntüleniyor. Etkinleştirebilir ayrıntılı aslında veri adım adım dosyasından yüklenir ve daha sonra ayrıştırılır nasıl iz.

 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics harika çünkü hangi izleme bilgisinin nereye gideceğini yapılandırabilirsiniz (dosya, olay günlüğü, veritabanı, ....).

Ne yazık ki, kullanmak System.Diagnosticsistiyorsanız önceden bilmeniz gerekir (çalışma zamanında ), hangi iz akışlarının izlenebileceği konusunda. (Örnek makalede bunlar Aktar, Devam Et, Askıya Al, ... dır). Bunlar Devre Dışı, Hata Ayıklama veya Hata Düzeyi olarak yapılandırılabilir.

Çalışma zamanında sınıf düzeyinde / namespacelevel'de karar verebileceğim bir kayıt sistemine sahip olmayı tercih ediyorum . Örneğin, tüm hata ayıklama ve yukarıda MyNamespace.Business.*ancak değil MyNamespace.Business.Calculations.

Log4net (veya Common.logging) kullanıyorsanız, her sınıf kendi kayıt cihazını alır, böylece hangi sınıfın hangi seviyede oturum açacağına kolayca karar verebilirsiniz.

Veritabanı işlemleri ayrı bir sınıfta olduğu için, farklı bir kurala ihtiyaç yoktur.

Trace an "Information" event when inserting an item into the database.

Bunun yerine bu yönergelere sahip olmayı tercih ederim:

• Tracelevel temel iş akışını göstermeli
• Debuglevel, iş akışında, sebepleri olan program akışındaki kararlar da dahil olmak üzere, ayrıntılı veri ve işlem göstermelidir (Yeni DB oluşturma, çünkü öğe DB'de mevcut değildi)
• Hizmetleri başlatma / durdurma ve her iş akışı / GUI eylemi için bir giriş için Infolevel başladı

Öykü çerçevesini deneyebilirsiniz , tüm günlükleri "yazarken" (ve ilgili diğer bilgileri eklediğinizde) bağlamda "oluştururken" kaydetme konusunda benzersiz bir yaklaşıma sahiptir, böylece daha sonra okumanız gerektiğinde ihtiyacınız olan her şeyi elde edersiniz.

Otomatik olarak "başlangıç" ve "dur" kavramlarını bir hikayenin başlangıcı ve bitişi olarak ekler.

Kural tabanlı bir sistemle, sahip olduğu bilgilere dayanarak her bir öykü (bağlam) ile ne yapılacağını denetleyebilirsiniz, örneğin, hatalı olan tüm öyküleri yazdırabilir veya "admin" kullanıcısından gelebilirsiniz.

Ayrıca bu blog yazısı hakkında daha fazla bilgi