Co to jest observability? Przewodnik dla fanów arkuszy

Co to jest observability? To zdolność ustalenia, co robi system i dlaczego, wyłącznie na podstawie danych, które sam emituje: logów, metryk i śladów. Jeśli monitoring mówi, że coś się zepsuło, observability pozwala zadać kolejne pytanie: gdzie, dla kogo i od kiedy. Jeśli pracujesz w arkuszach, już robisz jej małą wersję za każdym razem, gdy cofasz się od dziwnej liczby do wiersza, z którego pochodzi.

Wersja na minutę dla ludzi, którzy żyją w arkuszach

Wyobraź sobie miesięczny arkusz przychodów, w którym suma wygląda źle. Dashboard, który mówi „suma się nie zgadza", to monitoring. Możliwość filtrowania po regionie, dniu i produkcie oraz znalezienie jednego importu, który zdublował 400 wierszy, to już observability.

Zespoły programistyczne trafiają na tę samą ścianę w działających systemach. Strona płatności zaczyna się ładować wolno. Odpala się alert. Ktoś musi ustalić, który serwis, który segment klientów i który deploy są winne. Dane, które to umożliwiają, nazywają się telemetrią, a to, jak dobrze z nich korzystasz, jest tym, co ludzie mają na myśli, mówiąc observability.

Biscuit ma w tym swoją wersję. Nie trzeba mu mówić, że piłka zginęła. Musi prześledzić, gdzie piłkę widziano ostatnio.

Monitoring kontra observability: znane problemy kontra niespodzianki

Monitoring pilnuje rzeczy, które wcześniej postanowiłeś obserwować. Obciążenie CPU powyżej 90 procent, wskaźnik błędów powyżej 2 procent, strona, która przestaje odpowiadać. Sam piszesz regułę, a narzędzie krzyczy, gdy zostaje złamana.

Observability służy do problemów, dla których nie napisałeś żadnej reguły. Projekt OpenTelemetry opisuje ją jako sposób rozumienia systemu z zewnątrz, bez znajomości jego wnętrza, co pomaga w przypadku tak zwanych „niewiadomych niewiadomych" (ang. unknown unknowns).

Nie traktuj tego jako wyboru jednego zamiast drugiego. Monitoring to czujnik dymu. Observability to plan budynku i nagranie z kamer, które przeglądasz potem. Potrzebujesz obu.

Logi, metryki i ślady: trzy surowe składniki

Prawie każde wyjaśnienie kończy się na tych samych trzech sygnałach. Oto każdy z nich w języku arkuszy.

Logi to znaczniki czasu przy pojedynczych zdarzeniach. W arkuszu to jeden wiersz na zdarzenie: czas, użytkownik, akcja, wynik. Zawierają najwięcej szczegółów i zajmują najwięcej miejsca.

Metryki to liczby zagregowane w czasie, jak wskaźnik błędów, liczba żądań na minutę czy zużycie pamięci. W arkuszu to twoja zakładka z podsumowaniem. Są tanie w przechowywaniu i szybko się je rysuje na wykresie, ale nie powiedzą, które pojedyncze żądanie się nie udało.

Ślady (traces) śledzą jedno żądanie na drodze przez kilka serwisów, z czasem spędzonym na każdym etapie. W arkuszu wyobraź sobie jeden numer zamówienia, który śledzisz przez pięć zakładek, notując, ile czasu spędził w każdej z nich.

Typowe skrócenie brzmi tak: metryki mówią, że coś jest nie tak, ślady mówią mniej więcej gdzie, logi mówią szczegóły. Zobaczmy, jak to wygląda w prawdziwej komórce, w minutę.

Masz 5000 linii logów w pliku: przykład w Sheets

Załóżmy, że wyeksportowałeś 5000 linii logu aplikacji do Google Sheets. Kolumna A to znacznik czasu, kolumna B nazwa serwisu, kolumna C kod statusu, a kolumna D czas odpowiedzi w milisekundach. Działa w Excelu i w Sheets, chyba że zaznaczono inaczej.

Najpierw wskaźnik błędów, klasyczna metryka:

=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)

• Zakres to C2:C5001, czyli kody statusu.

• Kryterium ">=500" liczy wszystkie błędy serwera.

• Dzielenie przez COUNTA daje udział we wszystkich żądaniach. Sformatuj komórkę jako procent.

To jest monitoring: jedna liczba, jeden próg. Teraz część observability. Który serwis odpowiada za błędy?

=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)

Ta formuła działa tylko w Google Sheets, bo QUERY nie ma odpowiednika w Excelu. Argumenty:

• Dane to A1:D5001, razem z nagłówkami.

• Tekst to mały zapis w stylu SQL: policz błędy na serwis, od największej liczby.

• Ostatnie 1 oznacza, że jest jeden wiersz nagłówka.

W Excelu 365 dostaniesz ten sam wynik innym przepisem:

=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))

Potrzebujesz Excela 365 lub 2021, bo FILTER, UNIQUE i HSTACK nie istnieją w Excelu 2016. Starsze wersje lepiej obsłuży tabela przestawna.

A przy wolnych żądaniach 95. percentyl jest uczciwszy niż średnia:

=PERCENTILE(D2:D5001, 0.95)

Jeśli średni czas odpowiedzi to 180 ms, a 95. percentyl to 2,400 ms, to jeden na dwudziestu użytkowników ma zły dzień. Średnie to ukrywają, a właśnie tej pułapce narzędzia observability starają się pomóc uniknąć.

Biscuit już ją przyniósł, jeśli formuła to część, którą zawsze zapominasz. Formula.dog zamienia opis zwykłym językiem w gotową formułę.

Gdzie observability pojawia się w zwykłym dniu pracy

Nie musisz prowadzić serwerów, żeby się na nią natknąć. Lider wsparcia, który pyta „dlaczego zgłoszenia podwoiły się we wtorek?", właśnie to robi. Tak samo analityk finansowy, który prześledzi odchylenie do jednej faktury dostawcy, albo osoba z operacji, która odkrywa, że nocny import po cichu pominął plik.

W oprogramowaniu te same pytania są ostrzejsze, bo systemy są rozproszone. Jedno kliknięcie przycisku może dotknąć bramy API, usługi uwierzytelniania, bazy danych i dostawcy płatności. Gdy coś pada, komunikat o błędzie, który widzisz, rzadko jest miejscem, w którym wszystko się zaczęło. Ślad pokazuje cały łańcuch, z wyróżnionym wolnym lub zepsutym ogniwem, więc nikt nie musi zgadywać.

Trzy pojęcia pojawiają się ciągle, więc oto one prostym językiem:

• Instrumentacja to dodawanie kodu, który emituje telemetrię. Pomyśl o tym jak o dodaniu znacznika czasu i kolumny z ID do raportu, który nigdy ich nie miał.

• Kardynalność to liczba różnych wartości, jakie może przyjąć pole. Region ma niską kardynalność, ID użytkownika bardzo wysoką. Pola o wysokiej kardynalności odpowiadają na najostrzejsze pytania i kosztują najwięcej, jeśli je przechowujesz.

• SLO (cel poziomu usług) to zobowiązanie, jakie składasz sobie samemu, na przykład „99.5 procent płatności kończy się w mniej niż dwie sekundy". Zamienia niejasny niepokój w liczbę, którą można obserwować.

Dlaczego stos dashboardów to nie to samo co observability

Oto opinia, która irytuje dostawców: posiadanie wszystkich trzech sygnałów nie oznacza, że masz observability. Jeśli metryki żyją w jednym narzędziu, logi w drugim, a ślady w trzecim, ktoś musi je ręcznie zestawić o drugiej w nocy. To odpowiednik trzech skoroszytów bez wspólnej kolumny ID.

Test jest prosty. Gdy pęknie coś nieoczekiwanego, czy możesz zadać nowe pytanie swoim danym bez wdrażania nowego kodu? Jeśli odpowiedź brzmi „musielibyśmy dodać logowanie i wdrożyć ponownie", to monitoring z dodatkowymi krokami.

W praktyce o różnicy decydują dwie rzeczy:

• Kontekst przy każdym zdarzeniu. Każda linia logu niesie ID żądania, nazwę serwisu i wersję, więc możesz grupować i filtrować później. To kolumna ID, jakiej chciałbyś w każdym eksporcie.

• Szczegóły przechowywane wystarczająco długo. Dane o wysokiej kardynalności (ID użytkowników, ID zamówień) to miejsce, w którym kryją się odpowiedzi, i to też one podbijają rachunek.

Narzędzia, z których ludzie naprawdę korzystają, i ich koszt

Nie musisz nic kupować, żeby zrozumieć ideę, ale warto znać rynek.

OpenTelemetry to otwarty standard do produkowania telemetrii, a nie miejsce na jej przechowywanie ani podgląd. Instrumentujesz raz i wysyłasz dane tam, gdzie chcesz.

Grafana Cloud jest zbudowana wokół otwartych standardów i ma darmowy plan: 10,000 aktywnych serii metryk oraz po 50 GB logów, śladów i profili miesięcznie. Możesz też hostować otwartoźródłowy stos samodzielnie, za cenę samodzielnego składania Prometheus, Loki i Tempo.

Datadog to opcja „pod klucz": instalujesz agenta, po kilku minutach masz działające dashboardy i jedno miejsce na infrastrukturę, APM oraz logi. Haczyk tkwi w rozliczeniach. Cena za host (około $15 miesięcznie samej infrastruktury) plus osobne opłaty za logi i metryki niestandardowe mogą szybko urosnąć powyżej około 50 hostów, a stałego darmowego planu nie ma.

New Relic plasuje się pośrodku pod względem cen: 100 GB przyjętych danych miesięcznie za darmo, potem $0.40 za GB, z jednym pełnym użytkownikiem platformy w cenie.

Warto zapłacić, jeśli masz mały zespół platformowy i nie masz ochoty prowadzić infrastruktury o infrastrukturze. Pomiń, jeśli masz dwa serwery i jednego programistę. Dobry format logów oraz formuły powyżej zajdą zaskakująco daleko.

Co zrobić w poniedziałek, jeśli nie jesteś inżynierem

Być może nigdy nie dotkniesz śladu. Ale myślenie w kategoriach observability dobrze przenosi się na każdego, kto zawodowo raportuje liczby.

1. Dodaj ID do każdego eksportu. Kolumna, po której można złączyć dane, pokona każdą sprytną formułę.

2. Zachowuj surowe wiersze. Nie wklejaj wartości nad zakładkę ze szczegółami. Podsumowania to metryki, surowe wiersze to logi.

3. Zapisz, co znaczy „normalnie". Próg, którego nigdy nie zdefiniowałeś, nie może zadziałać.

4. Zadaj trzecie pytanie. „Przychody spadły" to alert. „Gdzie spadły?" to metryka. „Przez które wiersze spadły?" to observability.

Dobrym sposobem na start jest wybranie jednego pytania, które wraca co tydzień. Może to być: które klienty zgłaszają problemy po aktualizacji, dlaczego raport o zamówieniach ma inną sumę niż księgowość albo który dostawca najczęściej opóźnia faktury. Zapisz to pytanie w pierwszej komórce arkusza, a pod nim zbierz wiersze, które na nie odpowiadają. Po kilku tygodniach zobaczysz wzorzec, którego sama zakładka z podsumowaniem nigdy by ci nie pokazała. To właśnie observability w miniaturze: nie większe narzędzia, tylko lepiej zadane pytania i dane, do których masz dostęp.

Zrób to, a następna dziwna suma w arkuszu zajmie ci dziesięć minut wyjaśnienia zamiast popołudnia. Dobra robota, arkuszu.

Szybkie odpowiedzi na pytania, które ludzie naprawdę wpisują

Krótkie wersje najczęstszych pytań znajdziesz w FAQ poniżej. Jeśli zapamiętasz jedno: observability to nie produkt, który się kupuje. To, jak dobrze dane emitowane przez system pozwalają odpowiedzieć na pytania, których nie zaplanowałeś.