NLog vs Serilog

Wszyscy zdają się polecać Serilog, jako ten nowszy, lepszy, elengantszy.

I rzeczywiście: NLog ze swoim XMLowym plikiem konfiguracyjnym wygląda tak jakoś... frameworkowo. Dodatkowo dokumentacja pisana w Broken English, no cóż maintainer nie jest native speaker.

Serilog jest nowszy, błyszczący, ze swoim Fluent Api i wieloma paczkami nugetowymi bardziej.. Corowy.

Ale - ostatecznie - NLog jest, moim zdaniem, bardziej dopracowany i ma wiecej istotnych ficzerów.

• Serilog listy domyślnie serializuje do plików / konsoli / innych czysto tekstowych sinków w ten sposób: I have ["apples", "bananas", "oranges"] in my basket. Nie mam pojęcia, czy i jak można to zmienić. Na Discordzie ktoś powiedział, że robi z tym String.Join(", ", fruitInBasket), ale czy to z kolei nie psuje logowania strukturalnego? NLog za to domyślnie do pliku / na konsolę itp pisze tak: I have apples, bananas, oranges in my basket. To wydaje mi się dużo bardziej poprawne zachowanie.
• W przypadku logowania do EventLoga windowsowskiego, bym mógł przekazać własny event Id, Serilog każe mi override'ować klasę. W NLogu jest na to trywialny layout
• Logowanie do maili w Serilog: Wybiera backend (MailKit albo System.Net.Mail.SmtpClient) w zależności od tego, czy działa na Frameworku (wtedy System.Net.Mail.SmtpClient) czy też na Standard albo Core (wtedy MailKit). Niestety, System.Net.Mail.SmtpClient jest deprecated, nie obsługuje implicit SSL a tylko STARTTLS, z czego wynika, że nie da się go użyć przy wielu serwerach SMTP. Innymi słowy, na Frameworku sink e-mailowy Seriloga po prostu nie działa. Co gorsza, to zachowanie Seriloga jest nawet nieudokumentowane, musiałem czytać kod źródłowy, by znaleźć przyczynę, dla której wysyłanie maili mi nie działało. Tak, wciąż są sytuacje, gdzie trzeba pisać na Frameworku, nic nie poradzę. W NLogu łatwo wybrać backend, niezależnie od wersji .NET.
• Dalej maile: NLog pozwala wyspecyfikować wiele więcej opcji, takich jak np. cc i bcc. W Serilog nie widzę tego
• Serilog nie pozwala flushować bufora logów bez dispose'owania logera; NLog pozwala. Niby niewiele, ale bywa przydatne.
• Logowanie do pliku: Nie można starym plikom dokleić sensownie sformatowanej daty, np plikzlogami-2021-06-29.txt W NLog można.
• I chyba jeszcze coś, o czym zapomniałem.

Dodatkowo, maintainer NLoga zdaje się być zaangażowany w projekt i kontaktowny - nie wiem, jak jest z Serilogiem, tam nie mam doświadczeń, więc nie piszę tego jako zaletę Nloga nad Serilogiem, tylko jako zaletę Nloga w ogóle.

Aha - czy to wszystko jest zbędne, co piszę? Pewnie zaraz się ktoś znajdzie, kto powie, że to wszystko zbędne, bo powinienem logować do Seqa, Sentry, w najgorszym razie Elastic, a o plikach a tym bardziej mailach zapomnieć. No cóż, wciąż są admini, którzy zamiast Elastica korzystają z OSSECa czytającego plik z logami i piszą regexpy, albo co gorsza mają logi w nosie i nie da się ich inaczej powiadomić o problemie niż wysyłając maila z aplikacji. Lajf.

YetAnohterone napisał(a):

No cóż, wciąż są admini, którzy zamiast Elastica korzystają z OSSECa czytającego plik z logami i piszą regexpy, albo co gorsza mają logi w nosie i nie da się ich inaczej powiadomić o problemie niż wysyłając maila z aplikacji. Lajf.

No, a technologię dobierasz do rozwiązania problemu, a problem przedstawia Ci Twój klient. Więc jak ma być pisanie do pliku, to wybierz tę bibliotekę, która potrafi to lepiej/wygodniej.

A jeszcze tak, co do pierwszej kropki - to format Seriloga jest w takim razie znacznie bardziej czytelny. Z drugiego nic nie wynika, nie wiadomo co jest zmienną, a co nie.