środa, 21 stycznia 2009

Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (część 1) (przykłady w oparciu o C#).

Tworząc jakąś aplikację bardzo często stajemy przed koniecznością śledzenia zdarzeń jakie w niej występują. Szczególnie istotne jest to w aplikacjach, które wykonują zadania trwające dłuższą chwilę czasu. Do aplikacji tego typu zaliczyć można:
  • programy przetwarzające dane (np. wykonujące skomplikowane obliczenia, kodujące materiał wideo, itp...)
  • programy oferujące usługi jak serwer (np. serwer www, ftp, opc lub inny...)
  • inne aplikacje, których przebiegiem jesteśmy zainteresowani
Należy pamiętać, że nie zawsze chcemy, a często nawet nie jest to możliwe, by informować użytkownika bezpośrednio przy pomocy okna dialogowego. Zastanówmy się więc jakie są inne możliwości? Najczęściej w takich przypadkach wykorzystywane jest jedno z dwóch poniższych rozwiązań:
  • prywatny plik logu,
  • użycie rejestru zdarzeń wbudowanego w systemu operacyjny.
Która z tych metod jest lepsza? Chyba trudno jednoznaczną odpowiedź, każde z tych wspomnianych wyżej rozwiązań ma swoje wady i zalety. Pocieszający jest fakt, że programując w oparciu o platformę .NET Framework nie trzeba wcale decydować o tym, którą drogę wybrać. Wystarczy tylko wybrać metodologię opartą o tzw. tracing, a dzięki temu decyzję o tym gdzie mają nasze logi trafić będzie można zostawić użytkownikowi końcowemu. Jak to działa? Mechanizm ten wykorzystuje klasy takie jak: Dodatkowo można jeszcze wskazywać poziomy zdarzeń (przecież nie wszystkie zdarzenia są tak samo ważne). Platforma .Net Tracing przewiduje następujące typy zdarzeń (opisane w enumeracji TraceLevel):
  • Off - logowanie jest wyłączone
  • Error - logowane są tylko zdarzenia mające charakter błędów
  • Warning - logowane są zdarzenia, które są ostrzeżeniami
  • Info - w logu będą się pojawiały informacje
  • Verbose - logowane mogą być wszystkie zdarzenia, bez względu na charakter.
Co ciekawe, to użytkownik obsługujący program może wybrać jakiego rodzajami zdarzeń jest zainteresowany, wystarczy tylko zmodyfikować plik konfiguracyjny aplikacji (z rozszerzeniem ".config"), nie potrzeba wykonywać rekompilacji kodu aplikacji. Dodatkowo użytkownik może wybierać źródła, dla których zdarzeniami jest zainteresowany, twórca aplikacji musi jedynie poinformować użytkownika jakie źródła są dostępne, a później wystarczy już tylko zmiana ustawień w pliku konfiguracyjnym (.config) i zdarzenia są otrzymywane z innego źródła. Co więcej użytkownik może zdarzenia z różnych źródeł kierować do różnych Listener'ów, a dla każdego z nich ustawiać inny poziom logowania. W kolejnej części przedstawię opisany tutaj mechanizm w praktyce.

1 komentarz:

Posty powiązane / Related posts