System działa. Do momentu, w którym przestaje
Wyobraź sobie sklep internetowy, w którym klienci mogą przeglądać produkty, dodawać je do koszyka i przechodzić do płatności. Serwer odpowiada, strona się otwiera, a podstawowe wskaźniki infrastruktury nie wskazują na żaden poważny problem. Z pozoru wszystko działa prawidłowo.
Tymczasem część klientów nie może sfinalizować zamówienia. U jednych płatność trwa kilkanaście sekund, u innych pojawia się błąd. Zespół techniczny otrzymuje zgłoszenia, ale nie wie jeszcze, czy przyczyną jest bramka płatnicza, baza danych, ostatnia aktualizacja aplikacji, czy może problem z komunikacją między usługami.
To sytuacja, w której zwykły monitoring może okazać się niewystarczający. Potrafi wskazać, że wzrosła liczba błędów albo wydłużył się czas odpowiedzi, ale nie zawsze dostarcza informacji potrzebnych do szybkiego odnalezienia przyczyny.
Właśnie na tę lukę odpowiada observability, czyli obserwowalność systemu. Jej celem nie jest wyłącznie stwierdzenie, że aplikacja działa nieprawidłowo. Chodzi o możliwość przeanalizowania jej zachowania, odtworzenia przebiegu zdarzeń i znalezienia źródła problemu, również wtedy, gdy wcześniej nie przewidziano konkretnego scenariusza awarii.
Monitoring a observability - podobne cele, inne możliwości
Monitoring i observability są ze sobą ściśle powiązane, ale nie oznaczają tego samego.
Monitoring polega na systematycznym zbieraniu i analizowaniu danych o stanie aplikacji oraz infrastruktury. Pozwala śledzić określone parametry, wykrywać odchylenia od przyjętych norm i uruchamiać alerty, gdy wystąpi sytuacja wymagająca reakcji.
Przykładowe pytania, na które odpowiada monitoring, to:
- Czy serwer jest dostępny?
- Jaki jest średni czas odpowiedzi API?
- Czy liczba błędów HTTP 500 przekracza ustalony próg?
- Jakie jest zużycie pamięci i procesora?
- Czy kolejka zadań rośnie szybciej, niż system jest w stanie ją obsługiwać?
Observability idzie dalej. Pozwala analizować dane pochodzące z różnych części systemu i łączyć je w kontekst, który pomaga zrozumieć, dlaczego wystąpiło określone zachowanie.
Można to ująć w trzech pytaniach:
- Monitoring: Czy coś jest nie tak?
- Diagnostyka: Gdzie pojawił się problem?
- Observability: Co się wydarzyło, dlaczego i jaki był wpływ na działanie systemu?
Obserwowalność nie zastępuje monitoringu. Jest podejściem, które wykorzystuje monitoring oraz odpowiednio przygotowane dane telemetryczne, aby umożliwić głębsze badanie zachowania aplikacji. OpenTelemetry opisuje observability jako możliwość zadawania systemowi pytań o jego zachowanie na podstawie sygnałów takich jak logi, metryki i ślady rozproszone. <Cite ref="turn154932search0"/>
Trzy filary observability: logi, metryki i tracing
Podstawą obserwowalności są trzy rodzaje danych telemetrycznych: logs, metrics i traces. Każdy z nich pokazuje inny aspekt działania aplikacji. Dopiero ich korelacja daje szerszy obraz sytuacji.
1. Logi - co wydarzyło się w aplikacji?
Logi (logs) to uporządkowane zapisy zdarzeń generowanych przez aplikację, system operacyjny, serwery, bazy danych i inne elementy infrastruktury.
Mogą rejestrować na przykład:
- rozpoczęcie i zakończenie procesu,
- próbę logowania użytkownika,
- wysłanie żądania do zewnętrznego API,
- błąd walidacji danych,
- nieudaną transakcję,
- wyjątek zgłoszony przez aplikację,
- zmianę stanu zamówienia.
Log może zawierać znacznik czasu, poziom ważności, nazwę usługi, komunikat, identyfikator żądania oraz dodatkowe atrybuty opisujące zdarzenie.
Warto rozróżniać logi tekstowe od logów strukturalnych. Zapis tekstowy może wyglądać następująco:Błąd podczas przetwarzania zamówienia
Taki komunikat informuje o wystąpieniu problemu, ale niewiele mówi o jego kontekście. Log strukturalny może natomiast zawierać osobne pola, takie jak identyfikator zamówienia, nazwa operacji, kod błędu, czas wykonania i identyfikator śladu. Dzięki temu dane można filtrować, grupować i analizować automatycznie.
Dobra praktyka: logi powinny być projektowane z myślą o późniejszej analizie, a nie wyłącznie o zapisywaniu komunikatów. Warto stosować spójne nazewnictwo, poziomy ważności i identyfikatory korelacyjne, które pozwolą powiązać zdarzenia pochodzące z różnych komponentów.
Jednocześnie logowanie wymaga rozsądku. Zapisywanie każdej operacji w pełnym zakresie może generować ogromne ilości danych, zwiększać koszty przechowywania i utrudniać znalezienie istotnych informacji. Co równie ważne, logi nie powinny ujawniać haseł, tokenów dostępowych, danych kart płatniczych ani innych poufnych informacji. Należy stosować maskowanie, kontrolę dostępu, odpowiednie okresy retencji i zasady bezpiecznego przetwarzania danych.
2. Metryki - jak system zachowuje się w czasie?
Metryki (metrics) to zagregowane dane liczbowe opisujące stan, wydajność i zachowanie systemu w określonym czasie.
Przykładowe metryki obejmują:
- liczbę żądań obsłużonych w ciągu sekundy,
- odsetek żądań zakończonych błędem,
- czas odpowiedzi API,
- wykorzystanie CPU i pamięci,
- liczbę aktywnych sesji,
- długość kolejki zadań,
- liczbę zakończonych transakcji,
- czas oczekiwania na połączenie z bazą danych.
Ich największą zaletą jest możliwość obserwowania trendów. Pojedynczy błąd może być incydentem, ale stopniowo rosnący czas odpowiedzi, zwiększająca się liczba nieudanych transakcji lub narastająca kolejka zadań mogą wskazywać na rozwijający się problem.
W praktyce metryki pomagają odpowiedzieć nie tylko na pytanie, czy aplikacja działa, lecz także czy jej wydajność odpowiada oczekiwaniom użytkowników i wymaganiom biznesowym.
Szczególnie użyteczne są percentyle czasu odpowiedzi, na przykład p95 i p99. Średnia może ukrywać sytuację, w której większość użytkowników otrzymuje odpowiedź szybko, ale niewielka część doświadcza bardzo dużych opóźnień. Percentyle pokazują, jak długo trwa obsługa wolniejszych żądań i pomagają dostrzec problemy niewidoczne w średnich wartościach.
Dobra praktyka: dobieraj metryki, które mają znaczenie dla użytkownika i procesu biznesowego. Sama informacja o obciążeniu procesora nie powie, czy klient może złożyć zamówienie. Warto monitorować więc również wskaźniki związane z kluczowymi funkcjami, takie jak skuteczność płatności, czas realizacji zamówienia czy dostępność najważniejszych operacji.
3. Tracing - którędy przebiegało żądanie?
Tracing, a w szczególności distributed tracing, czyli śledzenie rozproszone, pozwala prześledzić drogę pojedynczego żądania przez różne komponenty systemu.
We współczesnej aplikacji operacja użytkownika może obejmować wiele etapów. Kliknięcie przycisku „Złóż zamówienie” może uruchomić żądanie w przeglądarce, które trafia do API, następnie do usługi zamówień, bazy danych, systemu magazynowego i zewnętrznego operatora płatności.
Jeżeli proces się opóźnia, sama informacja o czasie odpowiedzi całego API może nie wystarczyć. Tracing pozwala rozłożyć ten czas na poszczególne operacje i zobaczyć, który etap odpowiada za opóźnienie.
Podstawowym elementem śladu (trace) jest span, czyli zapis pojedynczej operacji. Span może zawierać czas rozpoczęcia i zakończenia, nazwę operacji, status oraz metadane. Powiązane spany tworzą ślad pokazujący przebieg całego żądania.
Przykładowo:
- API otrzymuje żądanie i przekazuje je dalej.
- Usługa zamówień weryfikuje dane.
- Baza danych zapisuje zamówienie.
- Usługa magazynowa sprawdza dostępność produktu.
- Zewnętrzna bramka płatnicza przetwarza transakcję.
- Aplikacja zwraca wynik do użytkownika.
Jeśli cały proces trwa 8 sekund, tracing może pokazać, że 6,5 sekundy zajęła odpowiedź zewnętrznej bramki płatniczej, a pozostałe operacje przebiegły prawidłowo. Zespół otrzymuje wówczas konkretny punkt do dalszej analizy, zamiast rozpoczynać diagnostykę od przypadkowych komponentów.
Tracing jest szczególnie przydatny w architekturach mikroserwisowych, systemach rozproszonych, aplikacjach opartych na kolejkach i rozwiązaniach integrujących wiele zewnętrznych usług. <Cite ref="turn154932search0"/>
Alerty - informacja ma dotrzeć do właściwej osoby
Dane telemetryczne są przydatne tylko wtedy, gdy można na ich podstawie podjąć działanie. Dlatego istotną częścią observability jest system alertowania.
Alert to powiadomienie o zdarzeniu lub stanie, który wymaga uwagi. Może zostać uruchomiony po przekroczeniu progu metryki, wykryciu określonego wzorca błędów lub stwierdzeniu, że kluczowa funkcja aplikacji nie działa zgodnie z oczekiwaniami.
Nie każdy wzrost obciążenia powinien jednak generować alarm. Jeśli system regularnie obsługuje duży ruch w godzinach szczytu, powiadomienie o każdym wzroście liczby żądań będzie powodować szum informacyjny. Zbyt wiele alertów prowadzi do ich ignorowania, a w konsekwencji do przeoczenia faktycznie istotnego incydentu.
Warto zatem ustalić:
- jakie zdarzenia wymagają natychmiastowej reakcji,
- które problemy mogą być analizowane w standardowym trybie pracy,
- kto odpowiada za konkretny typ alertu,
- jakie informacje powinno zawierać powiadomienie,
- jakie działania należy podjąć po jego otrzymaniu.
Dobrym punktem wyjścia jest definiowanie alertów w oparciu o wpływ na użytkownika i cele niezawodności, a nie wyłącznie na parametry infrastruktury. Przykładowo, alert o rosnącym odsetku nieudanych płatności może mieć większe znaczenie biznesowe niż krótkotrwały skok wykorzystania CPU.
Alert powinien prowadzić do działania. Jeśli nie wiadomo, kto ma go obsłużyć ani co należy zrobić, jest jedynie kolejnym komunikatem w systemie.
Przykład z praktyki: jak observability pomaga znaleźć przyczynę awarii?
Załóżmy, że użytkownicy aplikacji B2B zgłaszają, że generowanie raportów trwa znacznie dłużej niż zwykle. Monitoring wykrywa wzrost czasu odpowiedzi i uruchamia alert.
Zespół rozpoczyna analizę:
- Metryki wskazują, że problem dotyczy głównie raportów obejmujących duże zakresy danych. Pozostałe funkcje działają w normie.
- Tracing pokazuje, że największe opóźnienie pojawia się podczas wykonywania zapytania do bazy danych.
- Logi zawierają szczegóły zapytania, jego parametry operacyjne i informacje o błędach, bez ujawniania wrażliwych danych.
- Korelacja danych pozwala powiązać konkretny ślad z odpowiednimi wpisami w logach i zmianami widocznymi na wykresach metryk.
- Analiza zmiany wskazuje, że problem pojawił się po wdrożeniu nowej wersji raportu, która zaczęła wykonywać kosztowne zapytanie.
Dzięki temu zespół nie musi w ciemno sprawdzać całej infrastruktury. Może skoncentrować się na konkretnej operacji, porównać zachowanie przed i po wdrożeniu, a następnie zoptymalizować zapytanie lub wycofać zmianę.
Observability nie usuwa awarii i nie gwarantuje, że każda przyczyna zostanie znaleziona automatycznie. Pozwala jednak ograniczyć obszar poszukiwań, skrócić czas diagnozy i oprzeć decyzje na danych zamiast na przypuszczeniach.
Korelacja danych - największa wartość pojawia się razem
Logi, metryki i tracing są przydatne osobno, ale ich prawdziwa wartość ujawnia się, gdy można je ze sobą powiązać.
Wyobraźmy sobie, że dashboard pokazuje nagły wzrost czasu odpowiedzi. Metryka wskazuje, kiedy i w jakiej skali pojawił się problem. Trace pokazuje, które operacje składały się na wolne żądanie. Logi pozwalają sprawdzić, jakie zdarzenia wystąpiły w konkretnym etapie.
Aby było to możliwe, system powinien konsekwentnie przekazywać kontekst żądania pomiędzy usługami. Identyfikatory trace i span mogą być wykorzystywane do łączenia wpisów logów ze śladami. Warto również zachować spójne informacje o nazwie usługi, środowisku, wersji aplikacji i innych atrybutach opisujących źródło danych.
Bez korelacji zespół może mieć dostęp do wielu dashboardów, plików i narzędzi, ale nadal tracić czas na ręczne ustalanie, które zdarzenia są ze sobą powiązane. OpenTelemetry wskazuje korelację logów, śladów i kontekstu zasobów jako istotny element budowania użytecznej telemetrii. <Cite ref="turn154932search1"/>
OpenTelemetry - wspólny standard dla danych telemetrycznych
Wdrożenie observability nie musi oznaczać uzależnienia od jednego dostawcy narzędzi. Jednym z rozwiązań wspierających interoperacyjność jest OpenTelemetry (OTel) - otwarty zestaw standardów, interfejsów API, bibliotek i narzędzi do instrumentacji, generowania, zbierania i eksportowania danych telemetrycznych.
OpenTelemetry umożliwia aplikacji emitowanie metryk, logów i śladów w spójnym modelu. Dane mogą być następnie przekazywane do wybranego zaplecza obserwowalności, które odpowiada za ich przechowywanie, wyszukiwanie, wizualizację i analizę.
Ważnym elementem ekosystemu jest OpenTelemetry Collector. Może on odbierać dane z różnych źródeł, przetwarzać je, wzbogacać o dodatkowy kontekst i eksportować do skonfigurowanych systemów. Dzięki temu aplikacja nie musi być bezpośrednio powiązana z każdym narzędziem wykorzystywanym do analizy.
To podejście jest szczególnie przydatne, gdy firma korzysta z wielu technologii, rozwija architekturę systemu lub chce zachować możliwość zmiany dostawcy narzędzi. Sam standard nie zapewnia jednak kompletnej obserwowalności. Nadal potrzebne są właściwa instrumentacja, przemyślana strategia zbierania danych, odpowiednie dashboardy, alerty i procedury reagowania. <Cite ref="turn154932search3"/>
Kiedy warto wdrożyć observability?
Observability może być przydatne zarówno w dużych systemach rozproszonych, jak i w mniejszych aplikacjach, w których przestój lub trudna do wykrycia usterka ma istotne konsekwencje biznesowe.
Szczególnie warto rozważyć to podejście, gdy:
- aplikacja składa się z wielu usług lub integracji,
- problemy pojawiają się nieregularnie i trudno je odtworzyć,
- użytkownicy zgłaszają błędy, których nie widać w standardowych testach,
- czas diagnozowania incydentów jest zbyt długi,
- kolejne wdrożenia powodują trudne do przewidzenia skutki,
- firma rozwija system i potrzebuje danych do planowania wydajności,
- aplikacja obsługuje kluczowe procesy sprzedażowe, operacyjne lub finansowe,
- zespół potrzebuje lepiej rozumieć wpływ zewnętrznych usług na działanie całego rozwiązania.
Nie oznacza to jednak, że każda strona internetowa potrzebuje rozbudowanego środowiska telemetrycznego. W niewielkim, prostym serwisie wystarczające mogą być podstawowe logi, kontrola dostępności i kilka kluczowych metryk. Zakres rozwiązania powinien odpowiadać złożoności aplikacji, skali ruchu, wymaganiom niezawodności oraz kosztom potencjalnych przestojów.
Kiedy observability może być przerostem formy nad treścią?
Wdrożenie rozbudowanych narzędzi bez jasno określonego celu może przynieść więcej kosztów niż korzyści.
Do najczęstszych błędów należą:
- Zbieranie wszystkiego bez planu. Nadmiar danych zwiększa koszty i utrudnia wyszukiwanie informacji istotnych dla diagnozy.
- Brak pytań, na które system ma odpowiadać. Dashboardy mogą wyglądać efektownie, ale nie pomagać w rozwiązywaniu rzeczywistych problemów.
- Alertowanie o każdym odchyleniu. Zbyt duża liczba powiadomień powoduje zmęczenie alertami i zwiększa ryzyko przeoczenia incydentu.
- Brak odpowiedzialności za reakcję. Nawet dobrze wykryty problem może trwać długo, jeśli nikt nie wie, kto powinien się nim zająć.
- Brak ochrony danych. Telemetria może zawierać informacje wrażliwe, identyfikatory użytkowników lub dane operacyjne, które wymagają ograniczonego dostępu i odpowiedniej retencji.
- Ignorowanie kosztu instrumentacji. Zbieranie szczegółowych śladów i logów w dużej skali może wpływać na wydajność aplikacji oraz generować znaczące koszty przechowywania i przetwarzania.
- Traktowanie narzędzia jako gotowego rozwiązania. Samo zainstalowanie platformy nie zapewnia poprawnej instrumentacji ani sprawnego procesu diagnozy.
Observability wymaga więc nie tylko technologii, ale również decyzji organizacyjnych: które dane są potrzebne, kto je analizuje, jak reaguje zespół i w jaki sposób wnioski z incydentów przekładają się na zmiany w systemie.
Jak zaplanować wdrożenie observability?
Najbezpieczniej rozwijać obserwowalność etapami, zaczynając od procesów i funkcji, których awaria ma największy wpływ na użytkowników i firmę.
1. Określ kluczowe procesy biznesowe
Zidentyfikuj najważniejsze operacje, takie jak logowanie, składanie zamówień, płatności, generowanie dokumentów czy synchronizacja danych. To one powinny być punktem wyjścia do określenia, co oznacza prawidłowe działanie aplikacji.
2. Ustal wskaźniki niezawodności
Wybierz metryki, które odzwierciedlają doświadczenie użytkownika, na przykład dostępność kluczowych funkcji, czas odpowiedzi czy odsetek operacji zakończonych sukcesem. Dla istotnych usług można określić SLI (Service Level Indicator), czyli wskaźnik poziomu usługi, oraz SLO (Service Level Objective), czyli cel dotyczący tego wskaźnika.
3. Zadbaj o logi strukturalne
Ujednolić format logów, poziomy ważności i podstawowe atrybuty. Zadbaj o identyfikatory korelacyjne i politykę usuwania lub maskowania danych poufnych. Logi powinny być czytelne dla zespołu i możliwe do przetwarzania przez narzędzia.
4. Dodaj tracing w krytycznych ścieżkach
Rozpocznij od procesów, które obejmują wiele usług, baz danych lub zewnętrznych integracji. Śledź przebieg żądania przez system i dbaj o propagację kontekstu pomiędzy komponentami.
5. Zbuduj dashboardy wokół konkretnych pytań
Zamiast tworzyć jeden ogromny panel, przygotuj widoki odpowiadające na potrzeby różnych ról. Zespół techniczny może potrzebować informacji o błędach i opóźnieniach, a właściciel produktu - danych o skuteczności kluczowych procesów i wpływie awarii na użytkowników.
6. Zaprojektuj alerty i procedury reakcji
Ustal progi, priorytety, osoby odpowiedzialne i instrukcje postępowania. Alert powinien zawierać kontekst, który pomaga szybko rozpocząć diagnozę, a nie jedynie informować o przekroczeniu wartości.
7. Testuj obserwowalność
Sprawdź, czy zespół potrafi znaleźć przyczynę przykładowego błędu na podstawie dostępnych danych. Można przeprowadzić kontrolowane testy awarii na środowisku testowym lub ćwiczenia reagowania na incydenty. Warto też weryfikować, czy alerty uruchamiają się wtedy, kiedy powinny.
8. Rozwijaj rozwiązanie na podstawie incydentów
Po każdym istotnym problemie warto sprawdzić, jakie informacje były dostępne, czego zabrakło i jak można usprawnić instrumentację, alertowanie lub procedury. Observability nie jest jednorazowym projektem, lecz procesem doskonalenia wiedzy o działaniu systemu.
Koszty i bezpieczeństwo - dwa aspekty, których nie można pominąć
Dane telemetryczne mają swoją cenę. Koszty mogą wynikać z instrumentacji, transferu, indeksowania, przechowywania, retencji i analizy danych. W systemach o dużym ruchu szczególnie kosztowne może być zbieranie wszystkich śladów lub bardzo szczegółowych logów.
Dlatego warto stosować retencję dopasowaną do potrzeb, filtrowanie danych, próbkowanie śladów (sampling) i różne poziomy szczegółowości w zależności od środowiska. Przykładowo, produkcyjny system może zbierać pełne dane dla błędów i wybranych krytycznych operacji, a część poprawnych żądań próbkować, by ograniczyć wolumen.
Równie ważna jest ochrona danych. Logi i ślady mogą nieświadomie zawierać dane osobowe, identyfikatory sesji, fragmenty zapytań czy informacje o strukturze infrastruktury. Należy ograniczyć dostęp do telemetrii, usuwać zbędne dane, maskować informacje poufne i kontrolować okresy przechowywania. Warto również traktować systemy observability jako element środowiska produkcyjnego, który sam wymaga zabezpieczeń, kopii zapasowych i kontroli uprawnień.
Observability jako narzędzie zarządzania, nie tylko diagnostyki
Choć obserwowalność jest najczęściej kojarzona z pracą programistów, DevOps i administratorów, jej wartość wykracza poza obszar IT.
Dane o czasie odpowiedzi, błędach, dostępności i skuteczności procesów mogą pomóc firmie zrozumieć, które elementy technologii wspierają działalność, a które ją ograniczają. Pozwalają identyfikować powtarzające się problemy, oceniać skutki zmian i planować rozwój na podstawie rzeczywistego zachowania systemu.
Jeżeli na przykład system zamówień regularnie spowalnia w określonych godzinach, dane telemetryczne mogą pomóc ustalić, czy potrzebna jest optymalizacja zapytań, zmiana sposobu przetwarzania zadań, czy rozbudowa infrastruktury. Zamiast inwestować w dodatkowe zasoby na podstawie intuicji, firma może najpierw zidentyfikować rzeczywiste wąskie gardło.
Observability wspiera również analizę skutków wdrożeń. Porównanie metryk, śladów i logów przed zmianą oraz po niej pozwala szybciej wykrywać regresje i oceniać, czy aktualizacja przyniosła oczekiwany efekt.
Nie należy jednak utożsamiać obserwowalności z automatycznym podejmowaniem decyzji. Dane pokazują zachowanie systemu, ale ich interpretacja wymaga znajomości architektury, procesów biznesowych i kontekstu konkretnego incydentu.
Słownik pojęć
- Observability (obserwowalność) - zdolność rozumienia wewnętrznego zachowania systemu na podstawie danych, które emituje.
- Monitoring - ciągłe śledzenie wybranych parametrów i wykrywanie określonych stanów wymagających uwagi.
- Telemetry (telemetria) - dane zbierane i przesyłane z aplikacji oraz infrastruktury w celu analizy ich działania.
- Logs (logi) - zapisy zdarzeń występujących w aplikacji lub infrastrukturze.
- Metrics (metryki) - liczbowe pomiary stanu, wydajności lub zachowania systemu w czasie.
- Tracing - śledzenie przebiegu operacji przez komponenty aplikacji.
- Distributed tracing - śledzenie pojedynczego żądania w systemie złożonym z wielu usług lub procesów.
- Span - zapis pojedynczej operacji będącej częścią śladu.
- Trace - zestaw powiązanych spanów przedstawiających przebieg operacji.
- Alert - powiadomienie o wykrytym stanie lub zdarzeniu wymagającym reakcji.
- SLI - wskaźnik mierzący konkretny aspekt działania usługi.
- SLO - określony cel dla wybranego wskaźnika niezawodności.
- Sampling - technika ograniczania liczby zbieranych danych telemetrycznych przez wybór reprezentatywnej części zdarzeń.
- OpenTelemetry - otwarty zestaw standardów i narzędzi wspierających instrumentację i eksport danych telemetrycznych.
Podsumowanie
Awaria aplikacji nie zawsze zaczyna się od niedostępnego serwera lub komunikatu o błędzie. Czasami system formalnie działa, ale kluczowa funkcja staje się zbyt wolna, część transakcji nie kończy się powodzeniem albo integracja zawodzi tylko w określonych warunkach.
Monitoring pomaga wykryć nieprawidłowości. Observability pozwala zrozumieć, co doprowadziło do ich wystąpienia i jaki był ich wpływ na działanie aplikacji. Logi, metryki, tracing i dobrze zaprojektowane alerty tworzą razem podstawę do sprawniejszej diagnostyki, świadomego rozwoju i ograniczania ryzyka operacyjnego.
Nie chodzi o to, by zbierać jak najwięcej danych ani tworzyć najbardziej rozbudowane dashboardy. Chodzi o to, by w momencie wystąpienia problemu nie pytać wyłącznie: „Czy system działa?”, ale móc ustalić: „Co dokładnie wydarzyło się w systemie, dlaczego i co powinniśmy zrobić dalej?”
Dojrzała aplikacja to nie tylko taka, która działa. To również taka, której zachowanie można zrozumieć, diagnozować i doskonalić.
