Dużo się teraz mówi o Observability, czyli rozszerzonym monitoringu, w którym poza pilnowaniem logów tekstowych i metryk, obserwujemy również co dzieje się wew. aplikacji. Większość materiałów na ten temat skupia się na rozbudowie narzędzi z perspektywy programisty, ja bym chciał podejść do tematu ściśle od strony administracyjnej i utrzymaniowej (bez dotykania kodu aplikacji).
Narzędzia i rozwiązania (natywne Microsoft)
System Center Operations Manager
Od wersji 2012 w SCOMie jest moduł APM. Działa on na zasadzie rozszerzenia możliwości agenta SCOMa (musimy doinstalować moduł APM). Poza tym że doinstalujemy moduł APM, trzeba skonfigurować jakie aplikacje będą monitorowane i z jakimi ustawieniami (próbkowanie, czasy odpowiedzi, itp.).
Rozwiązanie świetne, ale niestety przeterminowało się, ponieważ od wersji 2012, do dzisiaj nie zostało zaktualizowane, a co gorsza, do wyświetlania zebranych danych wymaga IE 11. Tak, kiedyś była taka przeglądarka…
Microsoft Azure Applications Insights
Miałem ogromne nadzieje, że skoro Microsoft przeniósł funkcjonalność APM do Azure, to niedługo zaktualizuje również wersję obecną w SCOMie. Na razie niestety nic na to nie wskazuje. Dlatego jeżeli chcemy korzystać z tego narzędzia, możemy użyć wersji chmurowej. Działa ona dokładnie tak samo, tyle że jest aktualizowana i da się z niej korzystać.
Wadą będzie na pewno koszt, bo każde rozwiązanie chmurowe coś kosztuje. Nie badałem dokładnie tematu ile to może kosztować i jak ten koszt konkuruje z innymi rozwiązaniami na rynku.
Jak działa tracing w .NET
Nie wspominałem o tym wcześniej jak to działa pod spodem. Żeby zbierać dane telemetryczne najczęściej trzeba dodawać biblioteki w kodzie i robić jakieś wywołania. Ale już na wstępie zaznaczyłem że kodu nie tykam, szukamy rozwiązania dla adminów.
.NET ma funkcje profilera, dzięki któremu możemy podglądać (debugować?) co się dzieje w aplikacji. Domyślnie z tych narzędzie mogą korzystać programiści w Visual Studio.
https://learn.microsoft.com/pl-pl/visualstudio/profiling/profiling-feature-tour?view=vs-2022
Jest nawet cała sekcja w MS Learn odnoście badania wydajności aplikacji – https://learn.microsoft.com/en-us/visualstudio/profiling/?view=vs-2022
Włączenie profilera w .NET umożliwia zbieranie danych z .NET CLR odnośnie całego kodu aplikacji. Możemy to robić per pula aplikacji lub dla całego serwera (SCOM robił to per pula aplikacji). Dla wygody dla mnie najlepszym rozwiązaniem jest zbieranie danych ze wszystkich aplikacji na serwerze, więc profiler uruchamiam dla WASa.
Samo uruchomienie profilera to jedno, ale ktoś (coś) te dane musi zebrać i przesłać dalej. W SCOMie jest to agent APM, który odczytuje dane z profilera i przesyła je do bazy SCOMa. W przypadku Open Telemetry (które wydaje się najbardziej obiecującym rozwiązaniem na przyszłość) jest to kilka bibliotek, którym konfiguracyjnie ustawiamy co mają z tymi danymi robić. Cała konfiguracja odbywa się przez ustawienia w rejestrze (ustawiamy włączenie profilera, jaka biblioteka zbierająca dane ma być użyta, itp.).
Narzędzia i rozwiązania (inni dostawcy)
Teraz skupmy się na narzędziach, które współpracują z Open Telemetry. Zakładam, że wrzuciliśmy sobie gdzieś biblioteki Open Telemetry, zrobiliśmy odpowiednie wpisy w rejestrze i chcemy gdzieś te dane dalej przesyłać. Przy uruchomieniu pul aplikacji zostanie uruchomiony profiler, zauważy że ma uruchomić biblioteki Open Telemetry, a te biblioteki w konfiguracji będą miały zapisany endpoint, na który mają kierować dane.
Logz.io
Kilka lat temu zacząłem korzystać z Logz.io w celu zbierania i agregacji logów aplikacji i nieśmiało obserwowałem w którą stronę zmierza rynek. Poza Microsoftem o którego narzędziach wspomniałem wyżej, nie było nic dostępnego na rynku, co by działało w środowisku windowsowym.
Pierwszy pojawił się Jaeger, ale niedługo później weszło Open Telemetry.
Logz.io ma również własnego agenta APM, który dodatkowo umożliwia próbkowanie (jak SCOM i Azure Applications Insights), czego na razie nie ma Open Telemetry.
Wadą będzie to samo co w przypadku Azure Application Insights, jest to rozwiązanie chmurowe i nie da się go użyć we własnej serwerowni. Dodatkowo nie można wysyłać wszystkich danych jak leci, ale należy postawić w swoim środowisku kolektor, który będzie dane agregował i dopiero takie dane przesyłał dalej.
Elastic Cloud Enterprise
Elastic umożliwia odbieranie danych z Open Telemetry, a jego głównym atutem jest możliwość postawienia go na własnych serwerach (w formie dockerów na linuksie albo jakimś Kubernetesie).
Za ECE płacimy za każde rozpoczęte 64GB pamięci w klastrze, wydaje mi się to trochę lepszym sposobem licencjonowania, niż liczenie każdej transakcji albo ich wielkości, bo w takim modelu najwyżej będzie wszystko wolno działało, a koszty nie wystrzelą bez kontroli.
Z moich testów niestety to rozwiązanie działa bardzo ociężale. Logz.io dla porównania robi świetną robotę ze swoimi narzędziami i one działają zdecydowanie wydajniej.
SigNoz
To jest najmłodsze rozwiązanie, w pełni Open Source. Ba, możemy z niego korzystać za darmo bez ograniczeń. Stawia się podobnie jak ECE od Elastica (kontenery na linuksie lub Kubernetesie). Działa na bazie Clikchouse, która jest bazą kolumnową, więc idealną do trzymania danych powtarzających się. Najlepszą rekomendację dla tej bazy jest to, że korzysta z niej Cloudflare do analizy wszystkich zapytań HTTP, a mają ich trochę.
https://blog.cloudflare.com/log-analytics-using-clickhouse/
Wady tego rozwiązania to obecnie brak wsparcia, a jak będzie to od firmy z Indii (bo tam to narzędzie powstało). Ale chyba najbardziej trzymam kciuki za nich bo to jest coś, czego na rynku brakuje.
Datadog
Nie testowałem, głównie dlatego że cena za takie rozwiązanie jest abstrakcyjna.