Brown Bag Session: Monitorowanie serwisów

Przypomnijmy: Brown Bag Session to nasze regularne, wirtualne spotkania przy lunchu, podczas których rozwijamy zagadnienia techniczne. Ich celem jest udoskonalanie naszej pracy, jej efektywności, a także rozwijanie możliwości naszych systemów i narzędzi. Na ostatniej sesji kwestię monitoringu naszych serwisów poruszył Paweł Przybyła. Przeczytaj, do jakich wniosków doszedł.

Monitorowanie serwisów Metapack

Tematem naszej kolejnej sesji Brown Bag było zapewnienie pełnej obserwowalności (ang. observability) naszych systemów. Do monitorowania naszych serwisów wykorzystujemy NewRelic, który jest narzędziem klasy APM (Application Performance Monitoring). Pozwala on na zebranie w jednym miejscu ogromnej ilości danych telemetrycznych (zdarzenia, metryki oraz informacje o rozproszonych transakcjach w formie tzw. trace’ów i spanów).

Dane te są emitowane zarówno przez nasze serwisy, jak i przez wszystkie elementy naszej wirtualnej infrastruktury. New Relic posiada natywną integrację z AWS. Dzięki temu możemy skorelować zachowanie naszych serwisów z informacjami o działaniu serwisów AWS. W przypadku złożonych, rozproszonych rozwiązań i dużej ilości rejestrowanych danych telemetrycznych wyzwaniem staje się szybkie znalezienie przyczyny w przypadku incydentów.

Monitoring a obserwowalność

Tutaj dochodzimy do różnicy pomiędzy monitoringiem i pełną obserwowalnością. Monitoring w większości przypadków informuje nas, jeżeli coś nie działa. Najczęściej definiuje się wówczas „dashboardy” lub alerty na podstawie rejestrowanych danych. W przypadku New Relic można do tego użyć język NRQL, który jest bardzo podobny do SQL. Wymaga to jednak zadania konkretnego pytania już przed wystąpieniem problemu. W przypadku złożonych systemów nie jest to takie łatwe.

Dzięki uzyskaniu obserwowalności chcemy nie tylko zostać poinformowani, że coś nie działa. Przede wszystkim musimy wiedzieć, dlaczego coś nie działa. Chcemy znać tę odpowiedź w ciągu kilku minut. Naszym celem jest zrozumienie, jak w momencie incydentu działał nasz system. Informację tę chcemy pozyskać w oparciu o dokładną analizę wiarygodnych danych telemetrycznych, a nie w oparciu o przeczucia i domysły.

Nowe standardy szansą na większe możliwości

Zawsze dużym wyzwaniem w przypadku śledzenia rozproszonych systemów jest zrozumienie drogi jaką przebywa „request” oraz korelacja zdarzeń i logów generowanych przez poszczególne serwisy. Do niedawna każdy dostawca rozwiązań do monitorowania implementował własny standard. Do przesyłania identyfikatorów oraz kontekstu poszczególnych „spanów” używał swoje specyficzne nagłówki http. W lutym 2020 została opublikowana rekomendacja (https://www.w3.org/TR/trace-context/), nad którą pracowali między innymi inżynierowie z New Relic, Google i Microsoft. Standard ten został już zaimplementowany przez New Relic oraz przez Microsoft w .NET Core. Daje to nadzieję na łatwiejsze śledzenie żądań klientów. Nawet jeżeli serwisy je obsługujące będą monitorowane przez różne systemy.

Temat ten jest bardzo ważny i złożony. Pomimo, że nasze rozwiązania w tym obszarze są już bardzo zaawansowane, ciągle uczymy się nowych rzeczy oraz usprawniamy nasze systemy. Bardzo wartościowe jest to, że regularnie rozmawiamy o naszych rozwiązaniach i wyzwaniach z inżynierami z New Relic oraz Elastic. Dzięki temu korzystamy z najlepszych wzorców. Jednocześnie mamy wpływ na rozwój tych narzędzi.