W zeszłym tygodniu powiedziałem o 3 fajnych rzeczach w nlog związanych z ustawieniami naszych własnych danych – takich jak ID usera czy nazwa bazy danych. Coś co pomoże nam lepiej logować i przeszukiwać logi. Dziś zaś bardzo krótko ale też o super funkcji która została udostępnione niecałe 2 lata temu. Aż mi smutno, że dokumentacji nie czytałem od 2008/9 roku :)
W ostatnim artykule dałem przykład w którym możemy ustalić kontekst użytkownika i potem z niego korzystać w plikach logów które generujemy. Da nam to możliwość identyfikacji grupy logów tyczących się użytkownika. Ale taki użytkownik może daną operację wykonywać 40 razy. Ciężko nam będzie zorientować się (nie znając kodu) gdzie jest początek operacji a gdzie jest jej koniec. Czy to się ciągnie przez kilka miejsc w kodzie czy jest to jedna akcja?
Niby możemy to rozwiązać za pomocą kontekstu. Ale to zaczyna się robić śmieszne, tak jakby byśmy próbowali rozwiązać problem młotkiem zamiast znaleźć odpowiedni śrubokręt. A taki ów istnieje. Od .NET Framework 2.0 MS umożliwia nam ustawienie ID aktywności dla menadżera korelacji. Czyli mechanizmu .NET który grupuje logicznie serię wykonywanych operacji. Coś w stylu MappedDiagnosticsLogicalContext ale wbudowane jest to w .NET. Dokładnie mówiąc, MappedDiagnosticsLogicalContext korzysta z podobnego mechanizmu który się zwie CallContext i jest dostępny od .NET 1.1, ale że mało osób pamięta Remoting to temat pomińmy.
Menadżer korelacji jest wykorzystywany wewnętrznie przez Microsoft w System.Diagnostics. Czyli jakbyśmy nie chcieli korzystać z nLog a z System.Diagnostics to też moglibyśmy z tego mechanizmu skorzystać. Wszystko co musimy zrobić w aplikacji to ustawiać ActivityId:
Trace.CorrelationManager.ActivityId = Guid.New();
Od teraz, do końca naszego logicznego kontekstu, wszystkie operacje będą grupowane pod jednym określonym ID. Na przykład na Application_BeginRequest możemy takie coś ustawić i wszystko w kontekście danego request będzie logowane z tym samym ID. Dzięki czemu jeszcze łatwiej będzie nam śledzić nasze zdarzenia – lub dokładniej mówiąc rozdzielać odpowiednie akcje.
W pliku layouts zaś w nLog musimy dodać:
${activityid}
Dzięki czemu, jeżeli określimy ActivityID to będzie on logowany, jak nie to pusty ciąg znaków zostanie zwrócony.
Takie proste a takie piękne! Ja na dzisiaj mam zaplanowaną sesję z kodem by to wprowadzić :)
Znaliście tę opcję?
Korelacja logów w nLog – Jakub Gutkowski
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Znane :)
A dawno dawno temu opakowywałem bibliotekę do logowania w swoją klasę. Obiekt tajek klasy był wstrzykiwany z cyklem życia Per web request, a w konstruktorze generował sobie Guid. Potem każda metoda doklejała ten guid to tekstu, który był logowany.
fajny pomysł, kiedyś też robiłem wrappery na loggery, ale po tym jak się okazało co tracę przestałem. Ale też miałem inny cel. podobny do Common Logging stare czasy :) więc nie pamiętam :)
Comments are closed.