it-swarm-eu.dev

Doporučené postupy pro protokolování a trasování v .NET

Četl jsem hodně o trasování a protokolování, snažil jsem se najít nějaké zlaté pravidlo pro nejlepší postupy v této záležitosti, ale neexistuje žádné. Lidé říkají, že dobré programátory produkují dobré sledování, ale říkají to tak a musí to vycházet ze zkušeností.

Četl jsem také podobné otázky zde a prostřednictvím internetu a nejsou ve skutečnosti to samé, na co se ptám, nebo nemají uspokojivou odpověď, možná proto, že na tyto otázky chybí nějaké podrobnosti.

Takže lidé říkají, že trasování by mělo určitým způsobem zopakovat zkušenosti s laděním aplikace v případech, kdy nemůžete připojit debugger. Měl by poskytovat dostatečný kontext, abyste viděli, která cesta je vedena v každém kontrolním bodě aplikace.

Jde-li se hlouběji, můžete dokonce rozlišovat mezi trasováním a protokolováním událostí v tom, že „protokolování událostí se liší od trasování v tom, že zachycuje spíše hlavní stavy než podrobný tok kontroly“.

Řekněme, že chci provádět trasování a protokolování pouze pomocí standardních tříd .NET, které jsou uvedeny v System.Diagnostics jmenný prostor. Myslel jsem, že třída TraceSource je pro danou úlohu lepší než statická třída Trace, protože chci rozlišovat mezi úrovněmi trasování a pomocí třídy TraceSource mohu předat parametr informující o typu události, zatímco při použití třídy Trace musím použít Trace.WriteLineIf a poté ověřte věci jako SourceSwitch.TraceInformation a SourceSwitch.TraceErrors a nemá dokonce vlastnosti jako TraceVerbose nebo TraceStart.

S ohledem na to všechno byste považovali za dobrý postup postupovat takto:

  • Sledujte událost „Start“ při zahájení metody, která by měla představovat jednu logickou operaci nebo potrubí, spolu s řetězcovým vyjádřením hodnot parametrů předaných do metody.
  • Sledujte událost „Information“ při vkládání položky do databáze.
  • Sledujte událost „Information“, když se vydáte jednou nebo druhou cestou v důležitém prohlášení if/else.
  • Sledujte „kritickou“ nebo „chybu“ v blokovacím bloku v závislosti na tom, zda se jedná o chybu, kterou lze obnovit.
  • Sledujte událost „Stop“ po dokončení provádění metody.

A také objasněte, kdy je nejlepší sledovat typy podrobných a výstražných událostí. Pokud máte příklady kódu s trasováním/protokolováním Nice a jste ochotni sdílet, bylo by to vynikající.

Poznámka: Našel jsem zde několik dobrých informací, ale stále ne to, co hledám: http://msdn.Microsoft. com/en-us/magazine/ff714589.aspx

53
Levidad

Důležitost typů trasování musí být vybrána nikoli z důvodu, kde je trasování v kódu, ale proto, že sledovaná zpráva je více či méně důležitá. Příklad:

Sledujte událost „Start“ při zahájení metody, která by měla představovat jednu logickou operaci nebo potrubí, spolu s řetězcovým vyjádřením hodnot parametrů předaných do metody.

Použijte typ start při spuštění logické operace. To neznamená, že počáteční stopa musí být na začátku metody, ani to neznamená, že metoda musí mít počáteční stopu.

Toto bylo řečeno, ve většině případů logická operace skutečně začne na začátku metody. Jinak byste se měli zeptat sami sebe, zda je kód refactored správně.

Parametry sledování mohou být také špatný nápad. Musíte přemýšlet, co sledovat, případ od případu. Například je opravdu špatné sledovat parametry metody void Authenticate(string userName, string plainPassword).

Sledujte událost „Information“ při vkládání položky do databáze.

Záleží. Některé položky musí být sledovány, ale ne každá položka.

  • Představte si například, že do své databáze skutečně vkládáte položku protokolu. Sledovali byste protokoly? A pak protokolovat stopy? A pak trasování záznamu trasování?
  • Další příklad: vkládáte citlivá data. To vyžaduje audit. Protože jste auditovali vložení, proč je sledovat?

Sledujte událost „Information“, když se vydáte jednou nebo druhou cestou v důležitém prohlášení if/else.

Znovu to záleží.

Sledujte „Kritický“ nebo „Chyba“ v blokovacím bloku v závislosti na počasí, jedná se o opravitelnou chybu.

Akce přijatá po nevymožitelné chybě může být více než jen trasování. Například na straně serveru byste chtěli uložit výjimku do databáze pro další analýzu. Některé výjimky jsou také méně důležité než jiné a nevyžadují trasování.

Sledujte událost „Stop“ po dokončení provádění metody.

Viz první bod.

prosím objasněte, kdy je nejlepší sledovat typy podrobných a výstražných událostí.

podrobný popis

Podrobný se používá ke sledování toho, co potřebujete sledovat, když se něco opravdu pokazí. To znamená, že ve většině případů zakážete trasování podrobných zpráv, ale někdy musíte ladit některé části kódu, abyste pochopili, proč něco selže v případě Edge.

Obvykle máte spoustu podrobných zpráv, které vám umožní dobře porozumět toku aplikací. To také znamená, že tyto zprávy musí být většinou deaktivovány, protože:

  • jinak bude protokol růst opravdu rychle,
  • většinu času je nepotřebuješ,
  • mohou obsahovat citlivá data o aplikačním toku.

Zamyslete se nad podrobností jako s nástrojem, který musíte použít, když nemáte přístup k debuggeru.

Varování:

Sledování typu varování se používá, když se stane něco špatného a důležitého, ale není příliš důležité, aby se s ním zacházelo jako s chybou. Například low RAM může vydávat varování, ale není důvod sledovat chybu, protože vaše aplikace může pokračovat, i když bude pomalejší než obvykle).

Příklady:

  • Příklad 1: aplikaci se nepodařilo otevřít soubor, který uživatel požadoval. Soubor existuje a není používán, oprávnění jsou nastavena správně, ale něco blokuje otevření souboru. V tomto případě budete sledovat chyba, protože vaše aplikace nemůže tento případ spravovat a pokračovat v práci podle očekávání uživatele (tj. Skutečně načíst soubor).

  • Příklad 2: po kontrole chyby v prvním příkladu zjistíte, že chyba je způsobena skutečností, že cesta k souboru je delší než 259 znaků. Takže refaktorujete svůj kód, abyste chytili PathTooLongException. Když se uživatel příště pokusí otevřít stejný soubor, nová verze aplikace zobrazí zprávu vysvětlující, že soubor je příliš dlouhý a musí být přesunut do jiné složky, aby zkrátil celou cestu, aby mohl tento soubor otevřít v tato aplikace. Můžete také sledovat zpráv.

  • Příklad 3: vaše aplikace strávila dvacet sekund otevíráním a analyzováním malého souboru, zatímco většina souborů trvá otevření a rozbor deset až sto milisekund. Sledujete varování s příslušnými informacemi: typ disku, kde se soubor ve skutečnosti nachází, systém souborů, velikost souboru, přesný čas strávený, doba, po kterou byl počítač zapnut atd. Když uživatel si stěžuje, že otevření souboru trvá dvacet vteřin, pomocí stopy zjistíte, co se stane. Zjistíte například, že načítání souborů ze síťové sdílené složky po spuštění počítače trvá tak dlouho. Vysvětlete uživateli, že zpoždění je způsobeno sítí a nesouvisí s vaší aplikací.

  • Příklad 4: otevřený soubor je zobrazen nesprávně. Povolíte stopu podrobně, kde skutečně vidíte, jak jsou data načtena ze souboru a poté analyzována, krok za krokem.

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

System.Diagnostics je skvělé, protože můžete nakonfigurovat, kam mají trasovací informace směřovat (soubor, eventlog, databáze, ....)

Bohužel, pokud chcete použít System.Diagnostics musíte předem vědět (v době návrh), které sledovací proudy by mělo být možné sledovat. (V příkladu jsou to Přenos, Pokračovat, Pozastavit, ...). Lze je nakonfigurovat na Disabled, Debuglevel nebo Errorlevel.

Dávám přednost logovacímu systému, kde se mohu za běhu rozhodnout classlevel/namespacelevel, jak podrobné by mělo být protokolování. Například všechny ladění a vyšší od MyNamespace.Business.* ale ne MyNamespace.Business.Calculations.

Pokud používáte log4net (nebo Common.logging), každá třída dostane svůj vlastní logger, takže můžete snadno rozhodnout, které třídy se budou protokolovat na které úrovni.

Protože databázové operace jsou v samostatné třídě, není již zapotřebí žádné zvláštní pravidlo

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

Místo toho raději mám tyto pokyny:

  • Tracelevel by měl ukazovat základní pracovní postup
  • Debuglevel by měl zobrazovat podrobná data a zpracování v rámci pracovního postupu, včetně rozhodnutí v programovém toku s důvody (vytvoření nové položky, protože položka v DB neexistovala)
  • Infolevel pro spouštění/zastavování služeb a jeden záznam pro každou akci workflow/GUI spuštěnou
5
k3b

Můžete vyzkoušet Story framework , má jedinečný přístup k protokolování, protože „dělá“, že zapisujete všechny protokoly (a přidáváte další relevantní informace) v kontextu, takže když je potřebujete později přečíst, získáte vše co potřebuješ.

Jako začátek a konec příběhu automaticky přidá koncepty „start“ a „stop“.

A se systémem založeným na pravidlech můžete řídit, co dělat s každým příběhem (kontextem) na základě informací, které má, například vytisknout všechny příběhy, které mají chybu nebo pocházejí od „administrátorského“ uživatele.

Také více informací o tento blogový příspěvek

4
Amit Apple