Od lat używam nLog jako narzędzia do logowania danych w aplikacji – wybrałem je, bo miało ładne logo, prostą konfigurację i było tworzone i pisane przez Polaka. Do tego miało wsparcie najnowszego .NET a nie było zacofane jak log4net swojego czasu. Wtedy też skonfigurowałem sobie wszystko pod siebie – to jak ma być logowane, co ma by logowane, jak działa zapisywanie loga do plików itp. Ogólnie taki plik config, który można i nawet jest od lat kopiowany z projektu do projektu. Działa? Działa.

Przez ten czas absolutnie nie interesowałem się tym co się dzieje w świecie nLog. Zresztą nic mi nie brakowało. Czasami musiałem pewne zmienne dość często podawać i logować ale tak to… nic specjalnego. On po prostu działa i działa bardzo sprawnie. Zero problemów, polecam.

Ostatnio jednak moim oczom odbiło się coś na temat nLog a dokładniej chodzi o Diagnostics Context. Coś co umożliwia nam programistą, ustawienie pewnych globalnych wartości, do których potem możemy się odwoływać w layouts. Nie jest to nic nowego, ale jakoś to kompletnie umknęło mojej uwadze.

A szkoda. Bo jakbym wiedział to pewnie bym logował teraz dużo więcej informacji :)

Ok, ale co to są Diagnostics Context? W zależności od typu, umożliwiają nam ustawienie wartości globalnych dla danego scope – czy to będzie dla wszystkich wątków i loggerów (GDC), czy loggerów tyko z danego wątku (MDC) czy loggerów w danym logicznym kontekście (głównie dla async) (MDLC).

Ale co to znaczy dla nas, osób korzystających z nLoga? A mianowicie to, że jeżeli chcemy mieć w kontekście UserID w logu, to możemy dla każdego zapytania w danym wątku (MDC) dodać sobie:

MappedDiagnosticsContext.Set("UserID", CurrentUserId);

Albo ustawiać wersję API (przy założeniu, że możemy korzystać z kilku wersji naraz) aktualnie wykorzystywaną przez użytkownika (ale już obsługą async):

MappedDiagnosticsLogicalContext.Set("ApiVer", "1.0");

Czy też ustawić nazwę bazy danych czy też cokolwiek innego co jest globalne dla całego projektu:

GlobalDiagnosticsContext.Set("DBName","BY_DB_TST");

Takie informacje mogą nam potem pomóc łatwiej identyfikować nasze. Na przykład ID wątku? Przydatny? Przydatny. Czy też jak logujemy coś w logicznym kontekście to ID nasze wewnętrzne, które umożliwi nam zidentyfikowanie wszystkich powiązanych ze sobą operacji.

Oczywiście samo ustawienie nic nie da :) trzeba z tego móc potem skorzystać. Na szczęście w pliku konfiguracyjnym layout możemy skorzystać z odpowiednich szablonów i tak o to:

${gdc:item=DBName}
${mdc:item=ApiVer}
${mdlc:item=UserID}

Każdy z tych rzeczy zwróci nam odpowiednią wartość. Śledzenie staje się ciutkę prostsze i nie wymaga ciągłego podawania tych samych danych w każdym miejscu.

Naprawdę szkoda, że dopiero teraz to odkryłem. Ale już wprowadziłem to do dwóch projektów :)

A wy znaliście te opcje nLog? Czy w ogóle z nLog korzystacie?

4 KOMENTARZE

  1. Log4net’a nigdy nie używałem. Używam nLoga dokładnie z tego powodu o którym sam napisałeś. Jeden config wędrujący po projektach. Globalna deklaracja a później tylko wrzucanie informacji. W 99% procentach jest dla mnie idealny. O opisanej funkcjonalności nie wiedziałem, i na razie jej nie potrzebuje ale dobrze w odpowiedniej chwili wiedzieć że mamy takie możliwości, Dzięki :)

  2. Dzięki za informację o parametrach. Fajnie, że ktoś o tym pomyślał. W nowych projektach będzie trzeba się przesiąść na NLoga. Jest to jest jedna z opcji której brakowało czasami. Nie będzie trzeba tworzyć jakichś własnych obejść ;)

ZOSTAW KOMENTARZ

Please enter your comment!
Please enter your name here