Monitoring IT — najlepsze praktyki, czyli system, który nie krzyczy bez powodu

Prawdziwy test monitoringu to nie dashboardy

Każdy zespół umie zrobić dashboardy. Prawdziwy test systemu monitoringu odbywa się o 3:00 w nocy, gdy zadzwoni pager: czy inżynier wie dokładnie co zrobić, czy spędza pierwsze 20 minut grzebiąc w nieistotnych wykresach? Jeśli to drugie — Twój monitoring to teatr.

Ten przewodnik to uporządkowane przejście przez monitoring, który nie krzyczy bez powodu — od czterech złotych sygnałów, przez SLI/SLO/error budgety po ludzku, higienę alertów, po checklist do audytu istniejącego stanu.

Plan

1. Cztery złote sygnały
2. SLI, SLO i error budgety bez żargonu
3. Higiena alertów — reguły chroniące ludzi
4. Logi vs metryki vs ślady — kiedy co
5. Synthetic monitoring i RUM
6. Wybór stosu narzędzi
7. Zdrowy on-call dla małych zespołów
8. Checklist do audytu istniejącego monitoringu

1. Cztery złote sygnały

Dla każdego serwisu user-facing zmierz najpierw te cztery i nic więcej:

• Latencja — czas obsługi udanego requestu. p50, p95, p99.
• Ruch — requesty na sekundę lub odpowiednik biznesowy (zamówienia/min).
• Błędy — failed requesty jako odsetek, w podziale na kategorie.
• Saturacja — jak pełen jest system (CPU, RAM, głębokość kolejki, pule połączeń).

Te cztery prawidłowo zakrywają 80% incydentów. Metryki infrastrukturalne (dysk, sieć, zdrowie hosta) dodawaj wtedy, gdy faktycznie zapowiadają impact biznesowy.

2. SLI, SLO i error budgety po ludzku

• SLI to co mierzysz: „% requestów obsłużonych poniżej 300 ms”.
• SLO to cel, do którego się zobowiązujesz: „99,5% requestów <300 ms w ciągu 30 dni”.
• Error budget to co wolno wydać: 0,5% w tym przykładzie.

Sens error budgetów to nie kara. To jawny trade-off między niezawodnością a tempem dostaw funkcji. Wypaliłeś budżet tego miesiąca — zwalniasz wydania, inwestujesz w stabilność. Nie wypaliłeś — możesz dowozić szybciej. Ta rozmowa musi odbywać się na poziomie liderów inżynierii, nie tylko w zespole SRE.

3. Higiena alertów — reguły chroniące ludzi

Pięć reguł, wszystkie nienegocjowalne:

1. Każdy alert ma runbook. Brak runbooka — brak alertu.
2. Alerty są actionable. Jeśli on-call nie może coś zrobić w pięć minut — to ticket, nie alert.
3. Alerty oparte na objawach, nie przyczynach. „p99 latencji API >800 ms” bije „CPU na web-3 >80%”.
4. Alerty szanują godziny pracy. Buduj pager tylko dla rzeczy szkodzących klientom/przychodom teraz. Reszta do dziennej kolejki.
5. Wolumen alertów przeglądany co tydzień. Każdy alert wyzwalający bez akcji — strojony lub kasowany.

Zespół z pagerem dwa razy w tygodniu (z realnymi, actionable incydentami) jest zdrowszy od zespołu z 30 alertami szumu.

4. Logi vs metryki vs ślady — kiedy co

Sygnał	Najlepszy do	Najgorszy do
Metryki	Alertów, SLO, dashboardów	„Dlaczego ten konkretny request padł”
Logi	Forensyki, audytu, debugu	Dashboardów wysoko-kardynalnościowych (koszt eksploduje)
Ślady	Latencja root-cause między serwisami	Tani long-term storage

Nie loguj tego, co powinno być metryką. Nie traceuj tego, co powinno być logiem. Trzy są komplementarne, nie wymienne.

5. Synthetic monitoring i RUM

Synthetic (skryptowe sprawdzenia z lokalizacji zewnętrznych co minutę) łapie outage i wygasające certyfikaty zanim zauważą użytkownicy. RUM (real-user monitoring) mówi, co realnie przeżywają użytkownicy — wraz z wolnymi sieciami i starymi przeglądarkami, których nie masz na stagingu.

Uruchom oba. Alertuj z synthetic. Diagnozuj z RUM.

6. Wybór stosu narzędzi

Nie ma jednej poprawnej odpowiedzi. Uczciwa matryca wyboru:

• Prometheus + Grafana + Loki + Tempo — najlepszy TCO dla zespołów z inżynierem lubiącym operować takim stosem. Najgorszy dla pozostałych.
• Zabbix — mocny dla środowisk infra-heavy, on-prem, mix Linux/Windows. Cichszy w application observability.
• Datadog / New Relic / Dynatrace — najszybciej do wartości, najwyższa cena cennikowa, lock-in przez custom data model. Często słuszne dla firmy 20–100 osób, która nie chce operować platformą.
• Native chmurowe (CloudWatch, Azure Monitor, GCP Cloud Monitoring) — wygodne, słabsze w cross-cloud i cross-on-prem.

Wybieraj po trzech kryteriach: TCO w 3 lata (z czasem inżyniera), portability danych, czy zespół on-call faktycznie chce tego używać.

7. Zdrowy on-call dla małych zespołów

• Minimum dwóch inżynierów on-call. Jeden = single-point-of-failure (dla ludzi).
• Primary rotuje co tydzień. Secondary kryje primary. Bohaterowie 24/7 z jednym pagerem — nie.
• Spotkanie handover co poniedziałek: otwarte incydenty, najgłośniejsze alerty, co naprawić w tym tygodniu.
• Polityka wynagradzania on-call spisana.
• Po każdym incydencie: pięć linijek postmortem w wspólnym repo. Bez winnych, o systemach i sygnałach.

8. Checklist do audytu istniejącego monitoringu

• Czy cztery złote sygnały działają dla każdego serwisu user-facing?
• Czy każdy aktywny alert ma spisany runbook?
• Jaki jest tygodniowy wolumen alertów vs liczba incydentów wymagających działania?
• Kiedy ostatnio synthetic udanie sprawdził najbardziej krytyczny przepływ?
• Czy logi i metryki są w jednym miejscu (albo przynajmniej w jednym UI)?
• Czy narzędzie kosztuje tyle ile powinno w 12 miesięcy przy prognozowanym wzroście?
• Czy rotacja on-call jest udokumentowana, wynagradzana i wolna od single-point-of-failure?

Jeśli na któreś nie odpowiesz jednym zdaniem — od tego zacznij.

Kluczowe wnioski

• Buduj na czterech złotych sygnałach, nie na infrastrukturalnych ciekawostkach.
• Error budgety to rozmowa liderska o tempie vs niezawodności.
• Każdy alert potrzebuje runbooka i akcji; reszta to ticket.
• Logi, metryki i ślady są komplementarne, nigdy nie wymienne.
• Wybór narzędzia to decyzja TCO na 3 lata, nie checkbox z funkcji.

Jeśli chcesz zewnętrzny przegląd Twojego monitoringu pod ten checklist — napisz do nas. Rozmawiasz z inżynierem, nie ze sprzedażą.