Najlepsze praktyki w zakresie pozyskiwania drewna [zamknięte]

Chciałbym uzyskać historie o tym, jak ludzie radzą sobie ze śledzeniem i logowaniem w prawdziwych aplikacjach. Oto kilka pytań, które mogą pomóc wyjaśnić Twoją odpowiedź.

Framework

Jakich frameworków używasz?

  • log4net
  • System.Diagnostyka.Trace
  • System.Diagnostyka.TraceSource
  • blok aplikacji logowania
  • Inne?

Jeśli używasz śledzenia, czy używasz śledzenia.Korelacja.StartLogicalOperation?

Czy piszesz ten kod ręcznie, czy używasz do tego jakiejś formy programowania aspect oriented? Podzielisz się fragmentem kodu?

Czy podajesz jakąś formę ziarnistości nad źródłami śladowymi? Np. znaczniki WPF pozwalają na konfigurację ich na różnych poziomach:

  • System.Windows - ustawienia dla wszystkich WPF
  • System.Okna.Animacja- override specjalnie dla animacji.

Słuchacze

Jaki dziennik wyjścia, których używasz?

  • Pliki Tekstowe
  • pliki XML
  • Dziennik zdarzeń
  • Inne?

Jeśli używasz plików, używasz rolling logs czy tylko jednego pliku? Jak udostępnić dzienniki do konsumpcji?

Viewing

Jakich narzędzi używasz do przeglądania dzienników?

  • Notatnik
  • ogon
  • przeglądarka zdarzeń
  • Systems Center Operations Manager / Microsoft Operations Manger
  • WCF Service Trace Viewer
  • Inne?

Jeśli budujesz ASP.NET rozwiązanie, czy używasz również ASP.NET Monitoring zdrowia? Czy uwzględniasz dane wyjściowe w zdarzeniach monitora zdrowia? A co z Trace ' em.axd?

A co z niestandardowymi licznikami wydajności?

Author: Erik Funkenbusch, 2009-02-23
Source

10 answers

Update: dla rozszerzeń do systemu.Diagnostyka, dostarczanie niektórych brakujących słuchaczy, których możesz chcieć, zobacz Essential.Diagnostyka na CodePlex ( http://essentialdiagnostics.codeplex.com/)

ramy

P: jakich frameworków używacie?

Odp: System.Diagnostyka.TraceSource, Wbudowany W. NET 2.0.

Zapewnia wydajne, elastyczne i wydajne rejestrowanie aplikacji, niezależnie od tego, jak wiele deweloperzy nie są świadomi jego możliwości i nie wykorzystują ich w pełni.

Istnieją obszary, w których dodatkowa funkcjonalność jest użyteczna, lub czasami funkcjonalność istnieje, ale nie jest dobrze udokumentowana, jednak nie oznacza to, że cały framework logowania (który został zaprojektowany jako rozszerzalny) powinien zostać wyrzucony i całkowicie zastąpiony jak niektóre popularne alternatywy (NLog, log4net, Common.Logging, a nawet EntLib Logging).

Zamiast zmieniać sposób dodawania rejestrowanie instrukcji do aplikacji i ponowne wymyślanie koła, po prostu rozszerzyło System.Ramy diagnostyczne w kilku miejscach, których potrzebujesz.

Wydaje mi się, że inne frameworki, nawet EntLib, po prostu cierpią z powodu nie wynalezionego tutaj syndromu i myślę, że zmarnowały czas na wymyślanie podstaw, które już doskonale działają w systemie.Diagnostyka (np. sposób pisania instrukcji dziennika), zamiast wypełniania kilku istniejących luk. Krótko mówiąc, nie używaj ich - nie są potrzebne.

Cechy, których możesz nie znać:

  • użycie przeciążeń TraceEvent, które przyjmują format string i args, może pomóc w wydajności, ponieważ parametry są przechowywane jako oddzielne odniesienia do filtra po filtrze.ShouldTrace () udało się. Oznacza to, że żadne kosztowne wywołania ToString () na wartościach parametrów, dopóki system nie potwierdzi wiadomości, nie będą faktycznie rejestrowane.
  • Ślad.CorrelationManager pozwala na skorelowanie instrukcji dziennika o tym samym operacja logiczna (patrz niżej).
  • VisualBasic.Logowanie.FileLogTraceListener jest dobry do zapisu do plików dziennika i obsługuje obrót plików. Chociaż w przestrzeni nazw VisualBasic, może być równie łatwo używany w projekcie C# (lub w innym języku), po prostu włączając DLL.
  • podczas używania EventLogTraceListener jeśli wywołujesz TraceEvent z wieloma argumentami i z ciągiem w formacie pustym lub null, to args są przekazywane bezpośrednio do EventLog.WriteEntry () jeśli używasz zlokalizowane zasoby wiadomości.
  • narzędzie Service Trace Viewer (z WCF) jest przydatne do przeglądania wykresów skorelowanych plików dziennika aktywności (nawet jeśli nie używasz WCF). Może to naprawdę pomóc w debugowaniu złożonych problemów, w których zaangażowanych jest wiele wątków / aktywności.
  • unikaj kosztów ogólnych, wyczyszczając wszystkie słuchacze (lub usuwając domyślne); w przeciwnym razie Default przekaże wszystko do systemu śledzenia (i poniesie wszystkie koszty ogólne ToString ()).

Obszary, które możesz chcieć spójrz na rozszerzenie (w razie potrzeby):

  • database trace listener
  • Colored console trace listener
    • W związku z tym, że nie jest to możliwe, nie jest to możliwe.]}
  • zaimplementuj FileSystemWatcher do wywołania Trace.Odświeżanie dla dynamicznych zmian konfiguracji

Inne Zalecenia:

Użyj strukturyzowanych identyfikatorów zdarzeń i Zachowaj listę referencyjną(np. dokumentuj je w enum).

Posiadanie unikalnych identyfikatorów zdarzeń dla każdego (znaczącego) zdarzenia w Twój system jest bardzo przydatny do korelowania i znajdowania konkretnych problemów. Łatwo jest śledzić powrót do określonego kodu, który rejestruje / używa identyfikatorów zdarzeń i może ułatwić dostarczanie wskazówek dotyczących typowych błędów, np. błąd 5178 oznacza, że łańcuch połączenia z bazą danych jest nieprawidłowy itp.

Identyfikatory zdarzeń powinny być zgodne z jakąś strukturą (podobną do teorii kodów odpowiedzi używanych w wiadomościach e-mail i HTTP), która pozwala traktować je według kategorii bez znajomości konkretnych kodów.

Np. pierwsza cyfra może wyszczególnić ogólną klasę: 1xxx może być używany do operacji "Start", 2xxx do normalnego zachowania, 3xxx do śledzenia aktywności, 4xxx do ostrzeżeń, 5xxx do błędów, 8xxx do operacji "Stop", 9xxx do błędów krytycznych itp.

Druga cyfra może wyszczególnić obszar, np. 21xx dla informacji o bazie danych (41xx dla ostrzeżeń bazy danych, 51xx dla błędów bazy danych), 22xx dla trybu obliczeniowego (42xx dla ostrzeżeń obliczeniowych, itp.), 23xx dla innego modułu, itp.

Przypisany, uporządkowany identyfikatory zdarzeń umożliwiają również używanie ich w filtrach.

P: Jeśli używasz śledzenia, czy używasz śledzenia.Korelacja.StartLogicalOperation?

Odp: Trace.CorrelationManager jest bardzo przydatny do korelowania poleceń dziennika w dowolnym środowisku wielowątkowym(co w dzisiejszych czasach jest praktycznie wszystkim).

Musisz przynajmniej raz ustawić ActivityId dla każdej operacji logicznej,aby skorelować.

Start/Stop i można wtedy użyć LogicalOperationStack dla prostego kontekstu opartego na stosie. W przypadku bardziej złożonych kontekstów (np. operacji asynchronicznych) użycie TraceTransfer do nowego identyfikatora aktywności (przed jego zmianą) pozwala na korelację.

Narzędzie Service Trace Viewer może być przydatne do wyświetlania wykresów aktywności (nawet jeśli nie używasz WCF).

P: czy piszesz ten kod ręcznie, czy używasz do tego jakiejś formy programowania aspektowego? Podzielisz się fragmentem kodu?

O: możesz chcieć utworzyć klasę scope, np. LogicalOperationScope, który (a) ustawia kontekst po utworzeniu i (b) resetuje kontekst po usunięciu.

Pozwala to na zapisanie kodu, takiego jak poniżej, aby automatycznie zawijać operacje: 

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

Podczas tworzenia scope może najpierw ustawić ActivityId w razie potrzeby, wywołać StartLogicalOperation, a następnie zalogować TraceEventType.Rozpocznij wiadomość. Na Dispose może zapisać komunikat Stop, a następnie wywołać StopLogicalOperation.

P: czy podajesz jakąś formę ziarnistości nad źródła? Np. Źródła śladów WPF pozwalają na konfigurację ich na różnych poziomach.

Tak, wiele źródeł śledzenia jest przydatnych / ważnych, gdy systemy stają się większe.

Podczas gdy prawdopodobnie chcesz konsekwentnie rejestrować wszystkie ostrzeżenia i powyżej, lub wszystkie informacje i powyżej wiadomości, dla każdego systemu o rozsądnej wielkości wolumen śledzenia aktywności (Start, Stop, itp.) i szczegółowego logowania po prostu staje się zbyt duży.

Zamiast mieć tylko jeden przełącznik, który włącza wszystko albo lub wyłącz, przydatne jest włączenie tych informacji dla jednej sekcji systemu na raz.

W ten sposób można zlokalizować istotne problemy z zazwyczaj rejestrowania (wszystkie ostrzeżenia, błędy itp.), a następnie "powiększyć" na sekcje, które chcesz i ustawić je na śledzenie aktywności lub nawet poziomy debugowania.

Liczba potrzebnych źródeł śledzenia zależy od aplikacji, np. możesz chcieć jednego źródła śledzenia na zespół lub na główną sekcję aplikacji.

Jeśli potrzebujesz jeszcze bardziej precyzyjnej kontroli, dodaj Indywidualne przełączniki logiczne, aby włączyć / wyłączyć określone śledzenie o dużej głośności, np. zrzuty nieprzetworzonych wiadomości. (Lub można użyć oddzielnego źródła śledzenia, podobnego do WCF/WPF).

Możesz również rozważyć oddzielne źródła śledzenia dla śledzenia aktywności i ogólnego (innego) logowania, ponieważ może to nieco ułatwić skonfigurowanie filtrów dokładnie tak, jak chcesz.

Zauważ, że wiadomości mogą być nadal skorelowane przez ActivityId, nawet jeśli różne źródła są używane, więc użyj tyle, ile potrzebujesz.

Słuchacze

P: jakich wyjść dziennika używasz?

Może to zależeć od tego, jaki typ aplikacji piszesz i jakie rzeczy są rejestrowane. Zazwyczaj różne rzeczy idą w różnych miejscach(np. wiele wyjść).

Ogólnie klasyfikuję wyjścia do trzech grup:

(1) zdarzenia-Windows Event Log (i pliki śledzenia)

Np. jeśli piszesz serwer / usługę, to najlepsza praktyka w systemie Windows jest użycie dziennika zdarzeń systemu Windows (nie masz interfejsu użytkownika do zgłaszania).

W tym przypadku wszystkie zdarzenia Fatal, Error, Warning I (service-level) Information powinny przejść do dziennika zdarzeń systemu Windows. Poziom Informacji powinien być zarezerwowany dla tego typu zdarzeń wysokiego poziomu, tych, które chcesz przejść w dzienniku zdarzeń, np. "usługa uruchomiona" ," usługa zatrzymana"," podłączony do Xyz", a może nawet "harmonogram zainicjowany"," użytkownik zalogowany", itd.

W niektórych przypadkach możesz chcieć napisać do dziennik zdarzeń wbudowana część aplikacji, a nie za pośrednictwem systemu śledzenia (tzn. zapisywanie wpisów dziennika zdarzeń bezpośrednio). Oznacza to, że nie można go przypadkowo wyłączyć. (Uwaga nadal chcesz również zanotować to samo zdarzenie w systemie śledzenia, aby można było skorelować).

W przeciwieństwie do tego, aplikacja GUI systemu Windows zazwyczaj zgłasza je użytkownikowi(chociaż może również logować się do dziennika zdarzeń systemu Windows).

Zdarzenia mogą mieć również powiązane liczniki wydajności (np. liczba błędów / sek), i może być ważne, aby koordynować każdy bezpośredni zapis do dziennika zdarzeń, liczników wydajności, zapis do systemu śledzenia i raportowania do użytkownika, tak aby występowały one w tym samym czasie.

Tzn. jeśli użytkownik widzi komunikat o błędzie w określonym czasie, powinien być w stanie znaleźć ten sam komunikat o błędzie w dzienniku zdarzeń systemu Windows, a następnie to samo zdarzenie z tym samym znacznikiem czasu w dzienniku śledzenia (wraz z innymi szczegółami śledzenia).

(2) Działania-pliki dziennika aplikacji lub baza danych table (and trace files)

Jest to regularna czynność wykonywana przez system, np. serwowana strona internetowa, obrót giełdowy, pobrane zlecenie, wykonane obliczenia itp.

Śledzenie aktywności (start, stop, itp.) jest tutaj przydatne(po prawej stronie).

Ponadto bardzo często używa się określonego dziennika aplikacji (czasami zwanego dziennikiem audytu). Zwykle jest to tabela bazy danych lub plik dziennika aplikacji i zawiera ustrukturyzowane dane (tj. pola).

Rzeczy mogą się trochę zamazać w zależności od aplikacji. Dobrym przykładem może być serwer WWW, który zapisuje każde żądanie do dziennika internetowego; podobnymi przykładami może być SYSTEM WIADOMOŚCI lub system obliczeniowy, w którym każda operacja jest rejestrowana wraz ze szczegółami specyficznymi dla aplikacji.

Nie tak dobrym przykładem są transakcje giełdowe lub system zamówień sprzedaży. W tych systemach prawdopodobnie już rejestrujesz aktywność, ponieważ mają one ważną wartość biznesową, jednak zasada korelowania ich z innymi działaniami jest nadal ważna.

Oprócz niestandardowych dzienników aplikacji, działania często mają powiązane liczniki peformance, np. liczbę transakcji na sekundę.

Ogólnie należy koordynować rejestrowanie działań w różnych systemach, tj. zapisywać do dziennika aplikacji w tym samym czasie, gdy zwiększasz licznik wydajności i logujesz do systemu śledzenia. Jeśli robisz wszystko w tym samym czasie (lub bezpośrednio po sobie w kod), następnie debugowanie problemów jest łatwiejsze (niż jeśli wszystkie występują w różnych czasach / miejscach w kodzie).

(3) debug Trace-plik tekstowy, a może XML lub baza danych.

Jest to informacja na poziomie szczegółowym i niższym (np. niestandardowe przełączniki logiczne do włączania/wyłączania surowych zrzutów danych). Zapewnia to flaki lub szczegóły tego, co System robi na poziomie podaktywności.

Jest to poziom, który chcesz włączyć/wyłączyć dla poszczególnych sekcji aplikacji (stąd wiele źródeł). Nie chcesz, aby te rzeczy zaśmiecały Dziennik zdarzeń systemu Windows. Czasami używana jest baza danych, ale bardziej prawdopodobne są toczenia plików dziennika, które są usuwane po pewnym czasie.

Duża różnica między tymi informacjami a plikiem dziennika aplikacji polega na tym, że jest on niestrukturalny. Podczas gdy dziennik aplikacji może zawierać pola Dla To, From, Amount, itp., Verbose debug traces może być cokolwiek programista włoży, np. "sprawdzanie wartości X={wartość}, Y = false", lub losowe komentarze / znaczniki typu "Done it, trying again".

Jedną z ważnych praktyk jest upewnienie się, że rzeczy, które umieścisz w plikach dziennika aplikacji lub dzienniku zdarzeń systemu Windows, również zostaną zalogowane do systemu śledzenia z tymi samymi szczegółami (np. znacznikiem czasu). Pozwala to na skorelowanie różnych dzienników podczas badania.

Jeśli planujesz użyć konkretnej przeglądarki logów, ponieważ masz skomplikowaną korelację, np. Service Trace Viewer, musisz użyć odpowiedniego formatu tj. XML. W przeciwnym razie prosty plik tekstowy jest zwykle wystarczająco dobry - na niższych poziomach informacje są w dużej mierze niestrukturalne, więc możesz znaleźć zrzuty tablic, zrzuty stosów itp. Pod warunkiem, że możesz skorelować się z powrotem do bardziej ustrukturyzowanych dzienników na wyższych poziomach, wszystko powinno być w porządku.

P: Jeśli używasz plików, używasz rolling logs lub tylko jednego pliku? Jak udostępnić dzienniki do konsumpcji?

A: w przypadku plików, zazwyczaj chcesz, aby pliki dziennika były zwijane z poziomu zarządzania punkt widzenia (z systemem.Diagnostyka wystarczy użyć VisualBasic.Logowanie.FileLogTraceListener).

Dostępność ponownie zależy od systemu. Jeśli mówisz tylko o Plikach, to dla serwera/usługi, pliki rolujące mogą być dostępne tylko wtedy, gdy jest to konieczne. (Dzienniki zdarzeń systemu Windows lub Dzienniki aplikacji bazodanowych będą miały własne mechanizmy dostępu).

Jeśli nie masz łatwego dostępu do systemu plików, śledzenie debugowania do bazy danych może być łatwiejsze. [tj. wdrożenie bazy danych TraceListener].

Jednym z ciekawych rozwiązań widziałem dla aplikacji Windows GUI było to, że zapisywał bardzo szczegółowe informacje o śledzeniu do "rejestratora lotu" podczas pracy, a następnie po wyłączeniu go, jeśli nie miał żadnych problemów, po prostu usunął plik.

Jeśli jednak uległ awarii lub napotkał problem, plik nie został usunięty. Albo jeśli wyłapie błąd, albo przy następnym uruchomieniu zauważy plik, a następnie może podjąć działanie, np. skompresować go (np. 7zip) i wyślij e-mail lub w inny sposób Udostępnij.

Wiele systemów w dzisiejszych czasach włącza automatyczne zgłaszanie awarii do centralnego serwera (po sprawdzeniu z użytkownikami, np. ze względów prywatności).

Oglądanie

P: jakich narzędzi używasz do przeglądania dzienników?

A: jeśli masz wiele dzienników z różnych powodów, użyjesz wielu przeglądarek.

Notepad/vi/Notepad++ lub jakikolwiek inny edytor tekstu jest podstawowym dla dzienników zwykłego tekstu.

Jeśli masz złożone operacje, np. operacje z transferami, wtedy oczywiście użyjesz specjalistycznego narzędzia, takiego jak przeglądarka śledzenia usługi. (Ale jeśli go nie potrzebujesz, edytor tekstu jest łatwiejszy).

Ponieważ zazwyczaj loguję informacje o wysokim poziomie do dziennika zdarzeń systemu Windows, zapewnia on szybki sposób na uzyskanie przeglądu, w uporządkowany sposób (poszukaj ładnych ikon błędów/ostrzeżeń). Musisz tylko rozpocząć polowanie przez pliki tekstowe, jeśli nie ma wystarczającej ilości w dzienniku, chociaż przynajmniej dziennik daje Ci punkt wyjścia. (W tym momencie, upewnienie się, że Twoje dzienniki mają skoordynowane entires staje się przydatne).

Ogólnie Dziennik zdarzeń systemu Windows udostępnia te znaczące zdarzenia narzędziom monitorującym, takim jak MOM lub OpenView.

Inne --

Jeśli zalogujesz się do bazy danych, możesz łatwo filtrować i sortować informacje (np. przybliżać konkretny identyfikator aktywności. (W przypadku plików tekstowych możesz użyć Grep / PowerShell lub podobnego do filtrowania na partycjonalnym GUID you want)

MS Excel (lub inny program do arkuszy kalkulacyjnych). Może to być przydatne do analizy informacji strukturalnych lub półstrukturalnych, jeśli można je importować za pomocą odpowiednich ograniczników, aby różne wartości znajdowały się w różnych kolumnach.

Podczas uruchamiania usługi w debug / test zazwyczaj hostuję ją w aplikacji konsolowej dla uproszczenia uważam za przydatny Kolorowy rejestrator konsoli (np. czerwony dla błędów, żółty dla ostrzeżeń, itp.). Musisz zaimplementować Niestandardowy słuchacz śledzenia.

Zauważ, że framework nie zawiera kolorowego rejestratora konsoli ani rejestratora baz danych, więc w tej chwili musisz je zapisać, jeśli potrzebujesz (nie jest to zbyt trudne).

Naprawdę denerwuje mnie to, że kilka frameworków (log4net, EntLib, itp.) zmarnowało czas na wymyślenie koła i ponownie zaimplementowało podstawowe logowanie, filtrowanie i logowanie do plików tekstowych, dziennika zdarzeń systemu Windows i plików XML, każdy na swój własny sposób (instrukcje log są różne w każdym); każdy zaimplementował swoje własne wersja, na przykład, rejestratora baz danych, gdy większość z nich już istniała i wszystko, co było potrzebne, to kilka więcej śledzenia słuchaczy dla systemu.Diagnostyka. Mów o wielkim zmarnowaniu duplikatów.

P: jeśli budujesz ASP.NET rozwiązanie, czy używasz również ASP.NET Monitoring zdrowia? Czy uwzględniasz dane wyjściowe w zdarzeniach monitora zdrowia? A co z Trace ' em.axd?

Te rzeczy można włączyć / wyłączyć w razie potrzeby. Znalazłem ślad.axd bardzo przydatny do debugowania jak serwer reaguje na pewne rzeczy, ale na ogół nie jest przydatny w intensywnie używanym środowisku lub do długoterminowego śledzenia.

P: A co z niestandardowymi licznikami wydajności?

W przypadku profesjonalnej aplikacji, zwłaszcza serwera/usługi, spodziewam się, że będzie ona w pełni wyposażona zarówno w liczniki Monitora wydajności, jak i logowanie do dziennika zdarzeń systemu Windows. Są to standardowe narzędzia w systemie Windows i powinny być używane.

Musisz upewnić się, że dołączasz instalatory dla liczniki wydajności i dzienniki zdarzeń, których używasz; powinny one zostać utworzone podczas instalacji (podczas instalacji jako administrator). Gdy aplikacja działa normalnie, nie powinna mieć uprawnień administracyjnych (a więc nie będzie mogła tworzyć brakujących dzienników).

Jest to dobry powód, aby ćwiczyć rozwój jako nie-administrator (mieć oddzielne konto administratora, gdy trzeba zainstalować usługi itp.). Jeśli zapisujesz do dziennika zdarzeń,. NET automatycznie utworzy brakujący dziennik po raz pierwszy piszesz do niego; jeśli rozwiniesz się jako nie-administrator, złapiesz to wcześnie i unikniesz nieprzyjemnej niespodzianki, gdy klient zainstaluje Twój system, a następnie nie będzie mógł go używać, ponieważ nie działa jako administrator.

 232
Author: Sly Gryphon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-30 13:31:56

Muszę dołączyć do chorus zalecając log4net, w moim przypadku z punktu widzenia elastyczności platformy (desktop. Net / Compact Framework, 32/64-bit).

Jednak, owijanie go w API private-label jest głównym anty-pattern. log4net.ILogger jest odpowiednikiem. Net dla Commons Logging wrapper API , więc łączenie jest już zminimalizowane dla Ciebie, a ponieważ jest to również biblioteka Apache, zwykle nie jest to nawet problemem, ponieważ nie rezygnujesz z żadnych Kontrola: widelec, jeśli musisz.

Większość bibliotek wrapperów domowych, które widziałem, również popełnia jedną lub więcej z litanii błędów:

  1. używając globalnego rejestratora Singletona (lub równoważnie statycznego punktu wejścia), który traci dokładną rozdzielczość zalecanego wzorcalogger-per-class dla żadnego innego wzmocnienia selektywności.
  2. nie ujawnienie opcjonalnego argumentu Exception , co prowadzi do wielu problemów:
    • tworzy politykę rejestrowania WYJĄTKÓW jeszcze trudniejsze do utrzymania, więc nic nie robi się konsekwentnie z wyjątkami.
    • nawet przy spójnej polityce, formatowanie wyjątku do ciągu znaków przedwcześnie traci dane. Napisałem Niestandardowy dekorator, który przeprowadza szczegółowe analizy WYJĄTKÓW, aby określić łańcuch zdarzeń.
  3. nie ujawnienie właściwości IsLevelEnabled , które odrzucają możliwość pomijania kodu formatowania, gdy obszary lub poziomy logowania są obracane wyłącz.
 41
Author: Jeffrey Hantin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-23 04:54:33

Nieczęsto rozwijam się w asp.net jednak jeśli chodzi o loggerów uważam, że wiele najlepszych praktyk jest uniwersalnych. Oto niektóre z moich losowych myśli na temat logowania, których nauczyłem się przez lata: {]}

Framework

  • Użyj frameworka abstrakcji loggera - podobnego do slf4j (lub roll your own), aby oddzielić implementację loggera od API. Widziałem wiele frameworków loggera, które przychodzą i odchodzą, a ty lepiej możesz przyjąć nowy bez większego kłopoty.
  • spróbuj znaleźć framework, który obsługuje różne formaty wyjściowe.
  • spróbuj znaleźć framework, który obsługuje wtyczki / filtry niestandardowe.
  • Użyj frameworka, który może być skonfigurowany przez Pliki Zewnętrzne, tak aby klienci / konsumenci mogli łatwo dostosować wyjście dziennika, tak aby można je było łatwo odczytać przez komercyjne aplikacje do zarządzania dziennikami.
  • pamiętaj, aby nie przesadzić na niestandardowych poziomach logowania, w przeciwnym razie możesz nie być w stanie przejść do innego logowania ramy.

Wyjście Loggera

  • staraj się unikać dzienników w stylu XML/RSS do rejestrowania, które mogą napotkać katastrofalne awarie. Jest to ważne, ponieważ jeśli wyłącznik zasilania zostanie wyłączony bez zapisywania znacznika closing </xxx>, dziennik zostanie przerwany.
  • Zaloguj wątki. W przeciwnym razie śledzenie przepływu programu może być bardzo trudne.
  • Jeśli musisz umiędzynarodowić swoje dzienniki, możesz chcieć, aby programista logował się tylko w języku angielskim (lub w Twoim języku wybór).
  • czasami posiadanie opcji wstawiania instrukcji logowania do zapytań SQL może być ratunkiem w sytuacjach debugowania. Np.: 
    -- Invoking Class: com.foocorp.foopackage.FooClass:9021
    SELECT * FROM foo;
  • chcesz logowania na poziomie klasy. Zwykle nie chcesz również statycznych wystąpień loggerów - nie jest to warte mikro-optymalizacji.
  • oznaczanie i kategoryzowanie zalogowanych wyjątków jest czasami przydatne, ponieważ nie wszystkie wyjątki są sobie równe. Więc znając podzbiór ważnych WYJĄTKÓW Głowa czasu jest pomocna, jeśli masz monitor dziennika, który musi wysyłać powiadomienia o stanach krytycznych.
  • filtry duplikacji zapisują wzrok i dysk twardy. Czy naprawdę chcesz, aby ta sama instrukcja logowania powtórzyła się 10^10000000 razy? Czy nie byłoby lepiej po prostu dostać wiadomość jak: This is my logging statement - Repeated 100 times

Zobacz też to moje pytanie .

 19
Author: Elijah,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:17:59

Nie jestem uprawniony do komentowania logowania do. Net, ponieważ moim chlebem powszednim jest Java, ale mieliśmy migrację w logowaniu przez ostatnie 8 lat może znajdziesz użyteczną analogię do twojego pytania.

Zaczęliśmy od rejestratora Singleton, który był używany przez każdy wątek w JVM i ustawiliśmy poziom logowania dla całego procesu. Skutkowało to ogromnymi logami, gdybyśmy musieli debugować nawet bardzo konkretną część systemu, więc lekcja numer jeden to segregowanie logowania.

Nasz obecne wcielenie rejestratora pozwala na wiele wystąpień z jednym zdefiniowanym jako domyślnym. Możemy utworzyć dowolną liczbę loggerów potomnych, które mają różne poziomy logowania, ale najbardziej użytecznym aspektem tej architektury jest możliwość tworzenia loggerów dla poszczególnych pakietów i klas poprzez prostą zmianę właściwości logowania. Lekcja numer dwa to stworzenie elastycznego systemu, który pozwala na nadpisanie jego zachowania bez zmiany kodu.

Używamy Apache commons-logging biblioteka owinięta wokół Log4J.

Mam nadzieję, że to pomoże!

* Edit *

Po przeczytaniu poniższego postu Jeffreya Hantina, zdałem sobie sprawę, że powinienem był zauważyć, czym właściwie stał się nasz wewnętrzny wrapper rejestrujący. Jest teraz zasadniczo fabryczny i jest ściśle używany do uzyskania działającego rejestratora przy użyciu odpowiedniego pliku właściwości (który z powodów starszych nie został przeniesiony do pozycji domyślnej). Ponieważ możesz teraz określić plik konfiguracyjny logowania w wierszu poleceń, I podejrzewam, że stanie się jeszcze szczuplejsza i jeśli zaczynasz nową aplikację, zdecydowanie zgadzam się z jego stwierdzeniem, że nie powinieneś nawet owijać loggera.

 17
Author: Steve Moyer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-24 00:20:34

Używamy Log4Net w pracy jako dostawcy logowania, z opakowaniem singleton dla instancji logu(chociaż singleton jest w trakcie przeglądu, kwestionując, czy są dobrym pomysłem, czy nie).

Wybraliśmy go z następujących powodów:

  • Prosta konfiguracja / rekonfiguracja w różnych środowiskach
  • dobra liczba gotowych aplikacji
  • jeden z używanych przez nas systemów CMS miał już wbudowany
  • Ładna liczba poziomów logów i konfiguracji wokół them

powinienem wspomnieć, że jest to mowa z ASP.NET punkt widzenia rozwoju

Widzę pewne zalety w użyciu Trace, który jest w. NET framework, ale nie jestem w pełni na nim sprzedawany, głównie dlatego, że komponenty, z którymi pracuję, tak naprawdę nie wykonują żadnych połączeń Trace. Jedyne, czego często używam, to System.Net.Mail z tego, co mogę powiedzieć.

Więc mamy bibliotekę, która zawija log4net i w naszym kodzie potrzebujemy takich rzeczy jak to: 

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

Wewnątrz metod wykonujemy sprawdzenie, czy poziom logowania jest włączony, więc nie masz zbędnych wywołań do log4net API( więc jeśli Debug nie jest włączony, instrukcje debug są ignorowane), ale kiedy dostanę trochę czasu, będę aktualizować go, aby ujawnić je, tak, że można zrobić kontrole samodzielnie. Zapobiegnie to podejmowaniu ocen, gdy nie powinny, np.: 

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

To będzie: 

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

(zaoszczędź trochę czasu wykonania)

Domyślnie mamy log w dwóch miejscach:

    System plików strony internetowej (w nie obsługiwanym rozszerzeniu pliku)
  1. wysyłanie wiadomości e-mail dla błędów i fatalnych

Pliki są wykonywane jako rolling każdego dnia lub 10mb (IIRC). Nie używamy Eventlogu, ponieważ może wymagać większego bezpieczeństwa niż często chcemy zapewnić witrynie.

Uważam, że Notatnik działa dobrze do czytania dzienników.

 9
Author: Aaron Powell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-23 01:59:33

Jakich frameworków używacie?

Używamy mieszanki bloku aplikacji rejestrujących i niestandardowego pomocnika rejestrującego, który działa wokół bitów. Net framework. Laboratorium jest skonfigurowany do wyjścia dość obszerne pliki dziennika zawarte oddzielać ogólne pliki śledzenia dla wejścia / wyjścia metody usługi i specyficzne pliki błędów dla nieoczekiwanych problemów. Konfiguracja obejmuje datę/czas, wątek, pId itd. do pomocy w debugowaniu, jak również pełne szczegóły wyjątków i stosu (w przypadku nieoczekiwany wyjątek).

Custom logging helper korzysta ze śledzenia.Korelacji i jest szczególnie przydatna w kontekście logowania WF. Na przykład mamy maszynę stanową, która wywołuje serię sekwencyjnych przepływów pracy. Przy każdym z tych wywoływanych działań logujemy początek (używając StartLogicalOperation), a następnie na końcu zatrzymujemy operację logiczną za pomocą gereric return event handler.

Okazało się to przydatne kilka razy podczas próby debugowania błędów w złożonych sekwencje biznesowe, ponieważ pozwala nam określać takie rzeczy jak decyzje Oddziału If / Else itp. szybciej w oparciu o sekwencję wykonywania czynności.

Jakich wyjść logów używasz?

Używamy plików tekstowych i plików XML. Pliki tekstowe są konfigurowane przez blok aplikacji, ale mamy również wyjścia XML z naszej usługi WF. Pozwala nam to na przechwytywanie zdarzeń runtime (persistence itp.), a także ogólne wyjątki typu biznesowego. Pliki tekstowe to rolling logs, które są rolowane według dnia i rozmiaru (uważam, że całkowity rozmiar 1MB to punkt rolowania).

Jakich narzędzi używasz do przeglądania dzienników?

Używamy Notatnika i przeglądarki śledzenia usług WCF w zależności od grupy wyjściowej, na którą patrzymy. Przeglądarka śledzenia usług WCF jest bardzo przydatna, jeśli masz poprawną konfigurację wyjściową i możesz znacznie uprościć odczyt danych wyjściowych. To powiedziawszy, jeśli i tak Wiem z grubsza, gdzie jest błąd - samo czytanie dobrze przypisanego pliku tekstowego jest dobre jako cóż.

Dzienniki są wysyłane do jednego katalogu, który jest następnie dzielony na sub-dirs na podstawie usługi źródłowej. Katalog główny jest wyświetlany za pośrednictwem strony internetowej, która ma dostęp kontrolowany przez grupę użytkowników wsparcia. Pozwala nam to spojrzeć na dzienniki produkcji bez konieczności składania wniosków i przechodzenia przez długie procesy biurokratyczne dotyczące danych produkcyjnych.

 8
Author: Steve Godbold,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-23 04:22:52

Jako autorzy narzędzia używamy oczywiście SmartInspect do logowania i śledzenia aplikacji.NET. Zwykle używamy nazwanego protokołu pipe do rejestrowania na żywo i (zaszyfrowanych) binarnych plików dziennika dla dzienników użytkowników końcowych. Używamy konsoli SmartInspect jako przeglądarki i narzędzia do monitorowania.

Istnieje naprawdę sporo frameworków i narzędzi do logowania dla. NET. Jest przegląd i porównanie różnych narzędzi na DotNetLogging.com .

 6
Author: Dennis G.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-23 09:44:38

Istnieje wiele wspaniałych zaleceń w odpowiedziach.

Ogólną najlepszą praktyką jest rozważenie, kto będzie czytał dziennik. W moim przypadku będzie to administrator na stronie klienta. Więc zapisuję wiadomości, które dają im coś, na czym mogą działać. Na przykład: "nie można zainicjować aplikacji. Jest to zwykle spowodowane przez ......"

 5
Author: Matthew Sposato,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-24 13:13:06

Używamy log4net w naszych aplikacjach internetowych.

Możliwość dostosowania logowania w czasie wykonywania przez zmianę pliku konfiguracyjnego XML jest bardzo przydatna, gdy aplikacja działa nieprawidłowo w czasie wykonywania i musisz zobaczyć więcej informacji.

Pozwala również na kierowanie określonych klas lub atrybutów do logowania. Jest to bardzo przydatne, gdy masz pomysł, gdzie występuje błąd. Klasycznym przykładem jest NHibernate, gdzie chcesz zobaczyć tylko SQL idący do baza danych.

Edit:

Zapisujemy wszystkie zdarzenia do bazy danych i systemu śledzenia. Dziennik zdarzeń, którego używamy do błędów lub WYJĄTKÓW. Rejestrujemy większość zdarzeń do bazy danych, dzięki czemu możemy tworzyć niestandardowe raporty i pozwolić użytkownikom przeglądać dziennik, jeśli chcą bezpośrednio z aplikacji.

 1
Author: Jeffrey Cameron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-23 14:09:09

Jeśli chodzi o logowanie aspektowe to polecono mi PostSharp na innym więc pytaniu -

Aspect Oriented Logging with Unity\T4 \ anything else

Link podany w odpowiedzi jest wart odwiedzenia, jeśli oceniasz ramy logowania.

 1
Author: Unmesh Kondolikar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 10:31:19