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?
Właśnie przesiadamy się z log4net’a na nLoga na naszych projektach. jest wygodniejszy w użyciu. Jednak o tej funkcji biblioteki nie słyszałem.
nLog … contexts – Jakub Gutkowski
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
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 :)
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ść ;)
Comments are closed.