Dotyczy wersji 2026.1.x i powyżej
Wprowadzenie
W wersji 2026R1 wprowadzono zmianę sposobu logowania błędów – z dotychczasowych logów tekstowych (NLog) na logowanie strukturalne oparte na Serilog. Modernizacja ta znacząco podnosi jakość, czytelność i możliwości analizy logów w systemie.
- Głównym celem migracji na logowanie strukturalne jest modernizacja technologii oraz umożliwienie zaawansowanego, maszynowego przetwarzania logów. Serilog przechowuje dane w formie klucz–wartość, co znacząco ułatwia analizę i przeszukiwanie.
- Parametr ErrorGuid został zastąpiony przez CorrelationID – spójny identyfikator śledzenia zdarzeń.
- Konfiguracja logowania znajduje się w pliku appsettings.json w folderze instalacyjnym Portalu i Serwisu.
- Serilog obsługuje standard OpenTelemetry, umożliwiając jednolite przesyłanie, korelowanie i przetwarzanie logów w różnych narzędziach.
- Narzędzia zgodne ze standardem OpenTelemetry można konfigurować w sekcji Exporters w pliku appsettings.json.
- Dzięki OpenTelemetry, logi są powiązane z danymi diagnostycznymi (Traces) oraz metrykami (Metrics), co ułatwia analizę i monitoring.
- Zaktualizowano strukturę bazy danych, aby umożliwić przechowywanie obiektów logów – sposób działania pozostaje bez zmian.
- Zawartość logów jest teraz ujednolicona, ponieważ logi nie są oparte na sztywnej formule tekstowej, lecz na danych strukturalnych.
Przykład logu strukturalnego
Ujednolicona zawartość oferuje większą przejrzystość w porównaniu ze sztywnymi formułami tekstowymi.
{
“Name”:”WebCon.Workflow.Module.Identity.AccountController”,
“MessageTemplate”: „Niepoprawne hasło dla użytkownika ,{UserLogin}’.”
“UserLogin”: “t.green”,
“Clientp“: “192.168.1.0“,
“CorrelationId“: “a987763c-3e5c-42eb-bade-76a6e35cb3df“
}
Przykłady popularnych sinków
Serilog pozwala na jednoczesne wysyłanie logów w wiele miejsc poprzez tzw. sinki. W domyślnej instalacji WEBCON, w pliku appsettings.json wyszczególnione będą węzły odpowiadające tym sikom.
MSSQL
Domyślne miejsce przechowywania logów przez WEBCON, w świeżej instalacji jest to tabela Infrastructure.Logs w Bazie Konfiguracji. Tak jak pozostałe sinki i exportery, jest to dowolnie konfigurowalne. Możliwe jest (a przy większych systemach zalecane) przechowanie tych logów w innej, dedykowanej bazie MSSQL.
"MSSqlServerSink": {
"Name": "MSSqlServer",
"Args": {
"connectionString": "LogsDb",
"tableName": "Logs",
"schemaName": "infrastructure",
"autoCreateSqlTable": true,
"restrictedToMinimumLevel": "Warning",
File
Plik utworzony w wyznaczonym miejscu, domyślnie są to zapisywane logi z poziomem Fatal, czyli błędy krytyczne blokujące uruchomienie systemu.
"FileSink": {
"Name": "File",
"Args": {
"path": "Logs/log-.txt",
"rollingInterval": "Day",
"outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss} [{Level:u3}] {Message:lj}{NewLine}{Exception}",
"restrictedToMinimumLevel": "Fatal"
OpenTelemetry
Dowolne narzędzia korzystające ze standardu Opentelemetry. Różne narzędzia mogą obsługiwać różną kombinację Metrics/Traces/Logs w zależnie od potrzeb i preferencji, dodatkowo narzędzia mogą współpracować np. logi przesłane do narzędzia Loki wizualizowane za pomocą Grafana. Możliwe jest też wysyłanie z logów z jednego węzła Exporters do wielu narzędzi, na przykład:
- Seq
- Loki
- Grafana
- Prometheus
"OpenTelemetry": {
"Logs": {
"Enabled": True,
"Exporters": {
“Loki”: {
“Enabled”: true
“Endpoint”: http://localhost:3110/otlp/v1/logs
“Protocol”: “http”
},
“Seq”: {
“Enabled”: true
“Endpoint”: http://localhost:5432/ingest/otlp/v1/logs
“Protocol”: “http”
},
}
}
},
Więcej informacji można znaleźć w artykule o standardzie OpenTelemetry.
Dzięki modularności można łatwo dopasować konfigurację do wielkości środowiska oraz potrzeb operacyjnych.
Dwa słowa o bazie MSSQL
- Choć Serilog umożliwia logowanie do MSSQL, zalecamy stosowanie tego podejścia ostrożnie, szczególnie w dużych środowiskach.
- Baza konfiguracyjna MSSQL może stać się obciążona przy dużej ilości zdarzeń, co może wpłynąć na wydajność całego systemu WEBCON.
- W dużych środowiskach zalecane jest korzystanie z dedykowanej bazy MSSQL lub dedykowanych sinków.
- Łączy się to z brakiem możliwości wyszukiwania logów z poziomu Designer Studio.
Loggery
W konfiguracji poszczególnych, węzłów istnieje możliwość nadpisanie poziomu minimalnego logów tylko dla konkretnych loggerów. Na przykład, dla wybranego modułu systemu WEBCON (1) można zmienić poziom na Information albo Verbose (2), co pozwoli na szczegółowy troubleshooting. Poziomy logowania oraz ich domyślne wartości opisane są niżej.
W WEBCON, loggery odpowiadają konkretnym obszarom systemu, pozwalając wyszczególnić logi tylko z interesującego nas modułu.
Lista obszarów i loggerów
(lista niekompletna, uzupełniana będzie na bieżąco)
Nie ograniczają nas tylko loggery systemowe, można również korzystać z loggerów udostępnionych przez firmę Microsoft np. Microsoft.Extensions.logging, które pozwalają mierzyć i śledzić inne parametry, np. czas trwania jakiejś operacji.
Poziomy logowania
Różne poziomy logowania pozwalają śledzić wydarzenia w systemie mniej lub bardziej szczegółowo. Im bardziej szczegółowy poziom – tym więcej logów, i większe obciążenie. Niemniej jednak, korzystanie z szczegółowych poziomów tylko dla wybranych loggerów pozwoli na szczegółową analizę wybranych obszarów.
- Verbose – najbardziej szczegółowy i najrzadziej używany poziom; przydatny w debugowaniu złożonych scenariuszy.
- Debug – szczegółowe informacje pomocne przy troubleshooting’u na środowisku testowym.
- Information – ogólne informacje o zdarzeniach w systemie (np. walidacja, przepływ wykonania).
- Warning – zdarzenia niespodziewane, nieprzerywające operacji; domyślny poziom MinimumLevel w appsettings.json.
- Error – błędy przerywające aktualną operację, ale nie zatrzymujące działania całej aplikacji.
- Fatal – krytyczne błędy uniemożliwiające działanie systemu (np. brak możliwości uruchomienia Portalu).
Gdzie są domyślnie zapisywane logi?
W nowej instalacji WEBCON, węzły w konfiguracji mają skonfigurowany domyślny poziom minimalny, i domyślne miejsca przechowywania logów.
- Lokalizacja konfiguracji znajduje się w sekcji WriteTo w appsettings.json.
- Logi poziomu Fatal trafiają do pliku w folderze logs (zgodnie z konfiguracją).
- Logi poziomu Warning i wyższe trafiają do bazy MSSQL określonej w węźle MSsqlServer (domyślnie tabela Infrastructure.Logs w Bazie Konfiguracji).
- Logi IIS trafiają do folderu Inetpub.
- EventLog obejmuje poziom Error i wyższe.
Przyszłe zmiany
Zmiany wprowadzone w wersji 2026R1 to tylko pierwszy krok w modernizacji sposobu logowania. Ze względu na obszerność potrzebnych zmian, nie wszystkie miejsca w systemie są objęte nowym standardem – niektóre loggery nadal zapisują dane do swoich poprzednich tabel.
W przyszłych wersjach, również i one zostaną zastąpione logowaniem Serilog, a do starych tabel zapisywana będzie coraz mniejsza ilość logów, aż będą całkowicie zastąpione nową metodą logowania – informacja o tych planach będzie dostępna w Roadmapie.
Na chwilę obecną, bez zmian pozostają:
- logowanie przez Serwis – AdminWfEventLogs, Event viewer itd.
- sesje diagnostyczne,
- logi REST API oraz UDA.
Podsumowanie
- Logi są w pełni przeszukiwalne
Każdy wpis zawiera pola strukturalne (np. CorrelationID, UserLogin), dzięki czemu narzędzia analityczne mogą filtrować i agregować wyniki dużo skuteczniej niż w logach tekstowych. - Lepsza obserwowalność systemu
Strukturalne logi umożliwiają łatwe tworzenie dashboardów, analiz trendów, korelacji zdarzeń i raportów — szczególnie przy integracji z narzędziami takimi jak Seq, Elasticsearch, Grafana czy Application Insights. - Integracja z ekosystemem OpenTelemetry
Połączenie logów z metrykami i śladami (Traces) daje pełen obraz działania systemu, znacznie przyspieszając diagnostykę. - Jednolita struktura logów
Niezależnie od miejsca powstania błędu, logi posiadają spójną strukturę, co ułatwia ich analizę oraz automatyczne przetwarzanie. - Mniejsze ryzyko „szumu” i większa wydajność
Strukturalne logowanie ogranicza nadmiar powtarzalnego tekstu i poprawia wydajność mechanizmów przechowywania logów.