Serilog vs NLog vs log4net - którą bibliotekę logowania wybrać w .NET?

Dobre logi to jedna z tych rzeczy, których nie doceniasz, dopóki nie siedzisz o 2 w nocy nad produkcyjnym bugiem. Wtedy nagle okazuje się, że różnica między "coś się wywaliło" a "zamówienie 48213 poległo na walidacji płatności dla klienta 991" to różnica między 1 godziną a 5 minutami roboty. Logowanie ułatwia debugowanie, monitoring, a często bywa też podstawą audytu działania systemu.

W ekosystemie .NET prym wiodą 3 biblioteki: Serilog, NLog i log4net. Wybór tej właściwej to nie tylko kwestia gustu - decyduje o tym, jak szybko diagnozujesz błędy i jak czytelne są logi dla całego zespołu. W tym artykule porównam je pod kątem tego, co realnie ma znaczenie: logów strukturyzowanych, wydajności, dostępnych wyjść (sinks / targety / appendery - pliki, bazy, Elasticsearch itd.) oraz wygody konfiguracji. Na końcu znajdziesz konkretną rekomendację, żeby lider techniczny mógł ustalić jeden spójny standard dla całego projektu.

TL;DR

Szybkie porównanie

Serilog - nowoczesne logowanie strukturyzowane

log.Information($"Przetwarzam zamówienie o Id {orderId} dla klienta {customerId}");

w Serilogu użyjesz szablonu z nazwanymi polami:

log.Information("Przetwarzam zamówienie {OrderId} dla klienta {CustomerId}", orderId, customerId);

Taki wpis zapisze się ze strukturą zawierającą OrderId i CustomerId jako osobne właściwości - i później przeszukasz logi po tych polach zamiast męczyć się z wyrażeniami regularnymi.

Serilog słynie z bardzo bogatego ekosystemu sinków (wyjść) oraz dodatków. Od plików i konsoli, przez bazy SQL, po Elasticsearch, usługi chmurowe i wyspecjalizowane agregatory logów jak Seq - prawdopodobnie dla każdej potrzeby znajdziesz gotowy sink. Równie imponujący jest zestaw enricherów, czyli rozszerzeń dopisujących kontekst do każdego wpisu (ID wątku, nazwa aplikacji, dane żądania HTTP w ASP.NET itd.).

Konfiguracja odbywa się zwykle w kodzie, czytelnym, fluentowym API. Żeby zapisywać logi jednocześnie do konsoli i do pliku z dzienną rotacją, wystarczy:

Log.Logger = new LoggerConfiguration()
    .MinimumLevel.Debug()
    .WriteTo.Console()
    .WriteTo.File("app.log", rollingInterval: RollingInterval.Day)
    .CreateLogger();

Żadnego żmudnego pisania XML-a - choć jeśli wolisz, możesz konfigurować z pliku JSON lub XML. W ASP.NET Core integracja też jest banalna: instalujesz Serilog.AspNetCore, wołasz UseSerilog() przy konfiguracji hosta i wewnętrzne logi platformy (z Microsoft.Extensions.Logging) lądują w Serilogu.

Zalety w skrócie: domyślne wsparcie dla logów strukturyzowanych, czysta i elastyczna konfiguracja, ogromna biblioteka sinków oraz aktywna społeczność. Serilog jest intensywnie rozwijany, więc nadąża za nowymi wersjami .NET. Wydajnościowo też trzyma bardzo wysoki poziom - w jednym z benchmarków osiągał około dwukrotnie większą przepustowość niż NLog przy połowie jego opóźnienia (dla logów zapisywanych do pliku z buforowaniem). Wynik zależy oczywiście od scenariusza, ale pokazuje, że nowoczesna architektura Serilog nie ustępuje starszym bibliotekom, a bywa, że je przewyższa.

NLog - wydajność i elastyczność konfiguracji

NLog jest rozwijany od 2006 roku i ceniony przede wszystkim za wysoką wydajność oraz bogate możliwości konfiguracji. Podobnie jak log4net, długo bazował głównie na szablonach tekstowych, ale również zaadaptował logi strukturyzowane - wspiera Message Templates, czyli ten sam mechanizm nazwanych parametrów co Serilog. Obsługa pojawiła się później (wersja 4.5+), ale jest już pełnoprawną częścią biblioteki i pozwala zachować kontekstowe dane bez ręcznego sklejania stringów.

NLog daje bardzo elastyczną konfigurację - możesz go ustawić przez plik (nlog.config w XML lub JSON) albo w całości w kodzie, zależnie od preferencji zespołu. Domyślna składnia pliku jest dość zwięzła i czytelna (zwłaszcza w porównaniu z log4net), a ustawienia da się przeładować bez restartu aplikacji.

Prosty nlog.config zapisujący logi do pliku i na konsolę wygląda tak:

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd">
  <targets>
    <target name="file" xsi:type="File" fileName="app.log"
            layout="${longdate} ${level:uppercase=true} ${message} ${exception:format=tostring}" />
    <target name="console" xsi:type="Console" />
  </targets>
  <rules>
    <logger name="*" minlevel="Debug" writeTo="file,console" />
  </rules>
</nlog>

NLog oferuje szeroki wachlarz targetów: pliki (w tym rotowane), konsola, Event Log Windows, bazy przez ADO.NET, e-mail, a nawet wysyłkę przez HTTP. Dzięki dodatkom społeczności dostępne są też integracje z narzędziami monitorującymi - np. NLog.Targets.ElasticSearch pozwala wysyłać logi wprost do Elasticsearch (przydatne przy budowie centralnego repozytorium logów w oparciu o stack ELK). Elastyczność dotyczy zarówno formy (layouty: tekst, JSON, CSV…), jak i celu logowania.

Pod kątem wydajności NLog od lat uchodzi za jedną z najszybszych bibliotek dla .NET. Zaprojektowano go z myślą o minimalnym narzucie - oferuje m.in. logowanie asynchroniczne (async wrappers), które nie blokuje wątku aplikacji przy intensywnym zapisie. Świetnie sprawdza się tam, gdzie generujesz mnóstwo wpisów (systemy o wysokiej częstotliwości zdarzeń). W bezpośrednich porównaniach z Serilogiem wyniki bywają różne w zależności od scenariusza: Serilog zwykle zyskuje przy mocnym korzystaniu z logów strukturyzowanych i zaawansowanych funkcji, a NLog błyszczy w prostym, bardzo intensywnym logowaniu. W praktyce różnice rzadko są na tyle duże, by przesądzały o wyborze - obie biblioteki są wystarczająco szybkie dla większości zastosowań.

Zalety NLog: świetna wydajność, bogata konfiguracja (kodowo lub plikowo), duży wybór wbudowanych targetów i wieloletnia dojrzałość. Dokumentacja jest dobrze utrzymana. Minusem bywa nieco mniejsza społeczność niż wokół Serilog - przy bardzo niestandardowych potrzebach trudniej czasem znaleźć gotowy przykład - ale NLog jest na tyle popularny, że wsparcia i wtyczek nie brakuje. W nowoczesnym .NET spokojnie zintegrujesz go z ILogger (paczka NLog.Extensions.Logging), więc współpraca z ASP.NET Core nie jest problemem. Jeśli zespół ceni przejrzystość konfiguracji i maksymalną kontrolę nad loggerem - NLog będzie doskonałym wyborem.

log4net - klasyk, który wrócił do gry

log4net to prawdziwy weteran - projekt ruszył w 2001 roku jako port javowego log4j. Przez wiele lat był standardem logowania w .NET, a jego koncepcje (loggery, poziomy logów, appendery) stały się fundamentem, na którym wzorują się nowsze rozwiązania. Do dziś działa w niezliczonych aplikacjach produkcyjnych, co najlepiej świadczy o jego stabilności.

log4net oferuje bogaty wybór appenderów (odpowiedników sinków/targetów): konsola, pliki (rotowane wg rozmiaru lub daty), Event Log Windows, strumienie, bazy danych (wbudowany AdoNetAppender), a także SMTP (e-mail) czy zdalne serwery. Funkcjonalnie wciąż potrafi sprostać większości wymagań.

Ważna aktualizacja dla tego, kto pamięta log4net sprzed lat: biblioteka przez długi czas rozwijała się w ślimaczym tempie, ale to się zmieniło. W listopadzie 2024 ukazała się duża wersja 3.0.0, a kolejne wydania pojawiały się w 2025 roku (aktualnie dostępna jest już seria 3.3.x). Wersja 3.0 porzuciła wsparcie dla przestarzałych runtime'ów, zmodernizowała kod i naprawiła szereg problemów - w tym część historycznych kłopotów z działaniem na Linuksie, które wcześniej wynikały z wywołań specyficznych dla Windows. Wbudowane layouty renderują dziś m.in. Text, XML, JSON i Syslog, więc dodatkowy pakiet log4net.Ext.Json nie zawsze jest już potrzebny (warto to sprawdzić pod kątem konkretnej wersji, której używasz).

Mimo odświeżenia log4net wciąż odstaje od młodszych konkurentów w kilku obszarach. Konfiguracja opiera się głównie na plikach XML i przy bardziej złożonych wymaganiach potrafi się rozrosnąć do trudnego w utrzymaniu monstrum. Integracja z .NET Core bywa mniej "gładka" niż w Serilogu czy NLog i częściej wymaga dodatkowej konfiguracji (np. podpięcia pod ILogger).

Największą piętą achillesową pozostają logi strukturyzowane. log4net w swojej naturze traktuje log jako tekst formatowany według wzorca - nie ma natywnej koncepcji nazwanych właściwości z zachowaną semantyką. Owszem, skonfigurujesz layout JSON i uzyskasz efekt logów strukturyzowanych, ale to nadal serializacja tekstu według szablonu, a nie prawdziwa struktura danych, którą biblioteka rozumie. W porównaniu z Serilogiem (gdzie to biblioteka zarządza strukturą logu) wydobycie bogatego kontekstu jest po prostu trudniejsze - bliżej temu do szukania igły w stogu siana niż do wygodnej filtracji. Jeśli projekt mocno stawia na Elastic/Kibana, metryki z logów czy analizę zdarzeń, log4net będzie wymagał więcej pracy.

Zalety log4net: dojrzałość, niezawodność i "po prostu działa" od dwóch dekad. Jest bardzo rozszerzalny (własne appendery i layouty), a dzięki popularności historycznej znajdziesz mnóstwo przykładów i gotowych pluginów. Zapewnia też dynamiczną konfigurację – poziomy logowania czy plik docelowy zmienisz bez rekompilacji, samą edycją pliku konfiguracyjnego.

Wady log4net: rozwlekła konfiguracja XML, brak natywnego wsparcia dla logów strukturyzowanych oraz - mimo ożywienia projektu - wciąż mniej "nowoczesny" komfort pracy w świecie .NET Core niż u konkurentów. log4net najlepiej sprawdza się w projektach legacy, gdzie już jest osadzony, albo gdy potrzebujesz bardzo rozbudowanej konfiguracji i wiesz, jak ją okiełznać. W nowym projekcie warto jednak rozważyć nowocześniejsze podejście.

Podsumowanie i rekomendacje

Wybór zależy od potrzeb projektu i doświadczenia zespołu. Wszystkie 3 biblioteki są sprawdzone i potrafią zapisywać logi do rozmaitych źródeł - więc pod względem podstaw żadna nie odstaje drastycznie. Ale kilka wniosków nasuwa się samo:

Serilog - najlepszy wybór, jeśli zależy Ci na nowoczesnym podejściu. Wspiera logi strukturyzowane domyślnie, ma ogromny ekosystem sinków i aktywną społeczność. Konfiguracja w kodzie plus bogactwo pluginów (enrichery, filtry) pozwala szybko zbudować zaawansowany, spójny system logowania w dużym projekcie. Do tego łatwo wdrożysz go w ASP.NET Core. Jeśli chcesz inwestować w czytelne logi, które później centralnie przeanalizujesz (Elasticsearch/Kibana, Seq), to jest Twój standard.

NLog - doskonała opcja, gdy priorytetem jest wydajność i elastyczna konfiguracja. Sprawdzi się w aplikacjach generujących mnóstwo logów przy minimalnym narzucie. Obsługuje logi strukturyzowane (nie tak wyrafinowanie jak Serilog, ale "dowozi" potrzebne funkcje bez zbędnej złożoności). Jeśli zespół lubi konfigurację przez XML/JSON albo już zna NLog, pozostanie przy nim przyspieszy pracę. Z ASP.NET Core integrujesz go bez problemu przez NLog.Extensions.Logging.

log4net - uzasadniony głównie tam, gdzie projekt już z niego korzysta lub zespół zna go na wylot. To wciąż solidne narzędzie, a wersja 3.0 tchnęła w projekt nowe życie - ale w kwestii łatwości uzyskania nowoczesnych, strukturyzowanych logów oraz prostoty konfiguracji nadal ustępuje konkurentom. W nowym projekcie na najświeższym .NET rozważ, czy status "klasyka" przeważa nad wygodą, jaką dają Serilog i NLog. Jeśli stabilność i wieloletnie obycie zespołu liczą się bardziej niż najnowsze udogodnienia - log4net nie zawiedzie.

Na koniec rzecz ważniejsza niż sam wybór biblioteki: wdróżcie w zespole spójne zasady logowania. Ustalcie wspólny format (najlepiej strukturyzowany, z wymaganymi polami i kontekstem), konwencje poziomów (kiedy Debug, Info, Warning, Error) oraz sposób przechowywania i przeglądania logów. Zadbajcie o agregację - wysyłkę do wspólnego systemu typu Elastic/Kibana, Azure Application Insights czy Seq - tak, żeby każdy mógł szybko przeszukać logi w jednym miejscu. Logi mają służyć ludziom: być czytelne, zrozumiałe i dostępne. Jeden standard (obojętnie: Serilog, NLog czy log4net) sprawia, że cały zespół mówi tym samym "językiem logów", a to przekłada się wprost na sprawniejsze debugowanie i monitoring.

PS. Jeśli chcesz regularnie podnosić swój poziom w .NET - nie tylko w temacie logowania, ale też architektury, dobrych praktyk i rozwiązań, które realnie ułatwiają codzienną pracę z kodem - mam dla Ciebie coś ekstra. Raz na jakiś czas wysyłam grupie programistów .NET praktyczne wskazówki, konkretne przykłady i przemyślenia, których nie publikuję na blogu. Bez lania wody - same rzeczy, które od razu wykorzystasz w projekcie. Jeśli chcesz do nich dołączyć, zostaw swój adres tutaj: modestprogrammer.pl/vip. Do zobaczenia po drugiej stronie.