Po co w ogóle budować monitoring w chmurze, który „ratuje produkcję”
Cel jest prosty: system ma działać, zarabiać i nie budzić zespołu w nocy z błahych powodów. Monitoring w chmurze ma nie tylko sygnalizować, że coś przestaje działać, ale przede wszystkim pomagać podjąć właściwą decyzję w ciągu pierwszych minut incydentu. Różnica między „szumem” a realną pomocą wynika głównie z tego, jakie metryki, logi i alerty się zbiera i jak są ze sobą powiązane.
Monitoring aplikacji w chmurze wymaga innego podejścia niż monitoring on-premise. Chmura jest bardziej dynamiczna, złożona i rozproszona, ale jednocześnie daje potężne narzędzia: API providerów, usługi managed, mechanizmy autoskalowania, narzędzia observability cloud-native. Właściwie złożone potrafią wykrywać problemy przed użytkownikami, a nie razem z nimi.
Słowa kluczowe, wokół których krąży cały temat, to: metryki infrastruktury i aplikacji, analiza logów w środowisku cloud, alerty oparte na SLO i SLA, dobór progów alertów, monitoring kosztów w chmurze, korelacja logów i metryk, narzędzia monitoringu cloud-native, dashboardy dla zespołów DevOps oraz różnice między observability a tradycyjnym monitoringiem.
Źródło: Pexels | Autor: Tima Miroshnichenko
Dlaczego monitoring w chmurze wygląda inaczej niż w on‑premise
Krótkotrwałe instancje, autoskalowanie i wielość środowisk
W klasycznym on-premise większość elementów jest statyczna: serwery żyją latami, adresy IP rzadko się zmieniają, topologia jest względnie stała. Monitoring często opiera się na „liście serwerów” i agentach zainstalowanych na każdej maszynie. W chmurze taki model bardzo szybko się rozpada.
Środowiska cloud-native mają kilka cech, które mocno komplikują tradycyjny monitoring:
Krótkotrwałe instancje – maszyny wirtualne, kontenery czy funkcje serverless często żyją minuty lub godziny. Nie ma sensu ręcznie „dodawać serwera do monitoringu”, bo ten serwer zniknie szybciej, niż powstanie ticket.
Autoskalowanie – liczba replik aplikacji zmienia się dynamicznie w zależności od ruchu. Metryki, które patrzą na „CPU jednego serwera”, przestają mieć sens – ważna jest agregacja na poziomie całej usługi.
Wiele środowisk i regionów – typowo istnieje co najmniej: dev, test, staging, prod, często w kilku regionach chmury. Monitoring musi nadążać za tym podziałem i umożliwiać filtrowanie i korelację danych między nimi.
Skuteczny monitoring w chmurze musi więc być oparty na dynamicznej odkrywalności (service discovery), tagach/labelach (np. nazwa usługi, środowisko, region, zespół) i agregacji na poziomie usług, a nie pojedynczych maszyn. To jedna z największych różnic kulturowych między światem on-prem a cloud-native.
Monitoring „pudełkowy” vs podejście cloud-native
Monitoring „pudełkowy” to klasyczne narzędzia typu „postaw serwer monitoringu, zainstaluj agenta na maszynach, klikaj w UI”. Dobrze sprawdzają się tam, gdzie infrastruktura jest mało zmienna, a liczba systemów ograniczona. W środowiskach chmurowych zaczynają się schody:
Skalowalność – nagły skok liczby instancji może zalać centralny serwer monitoringu danymi. Usługi monitoringu w chmurze są natywnie skalowane poziomo.
Integracja z API providera – w chmurze wiele metryk (np. IOPS dysku EBS, opóźnienia load balancera) dostępnych jest wyłącznie przez API platformy (CloudWatch, Azure Monitor, Stackdriver). Rozwiązania cloud-native korzystają z nich „z pudełka”.
Managed services – bazy danych, kolejki, systemy cache w modelu PaaS często nie mają „naszego” systemu operacyjnego, na którym da się zainstalować agenta. Zostaje nam API monitoringu chmurowego lub eksportery.
Rozwiązania cloud-native (Prometheus + Grafana, Datadog, New Relic, narzędzia providerów) są projektowane w duchu „usługa monitoruje usługę”. Ich siłą jest łatwe włączanie monitoringu nowych komponentów przez adnotacje, labelki, integracje z Kubernetesem czy serverless, a nie ręczne klikanie czy instalowanie agentów.
Observability vs tradycyjny monitoring
Tradycyjny monitoring skupia się na odpowiedzi na pytanie: „czy coś jest czerwone czy zielone?”. Zbiera głównie proste metryki infrastruktury oraz kilka wskaźników aplikacyjnych. W świecie złożonych, rozproszonych systemów to zwykle za mało.
Observability opiera się na trzech głównych filarach:
Metryki – zagregowane, liczbowe dane w seriach czasowych (np. liczba requestów/s, CPU, latency).
Logi – szczegółowy opis zdarzeń w systemie.
Trace’y rozproszone – ścieżka pojedynczego żądania przez wiele usług (mikroserwisy, kolejki, bazy danych).
Monitoring odpowiada na pytanie „czy działa”, observability pozwala dojść do „dlaczego nie działa” bez konieczności dopisywania kodu za każdym razem. W praktyce: im bardziej rozproszona architektura (mikroserwisy, event-driven, funkcje serverless), tym bardziej opłaca się inwestować w trace’y i korelację metryk z logami i zdarzeniami.
Koszty, limity i shared responsibility
W modelu on-premise ograniczeniem były głównie zasoby sprzętowe. W chmurze dochodzi model rozliczeń „pay-as-you-go”: za przechowywanie metryk, logów i trace’ów płaci się co miesiąc. Monitoring sam w sobie może stać się istotną pozycją na fakturze.
Równocześnie obowiązuje model shared responsibility. Dostawca chmury:
zapewnia dostępność i bezpieczeństwo warstwy fizycznej oraz infrastruktury,
udostępnia swoje metryki (np. stan load balancerów, stan usług managed),
narzuca pewne limity (np. na ilość logów w planie darmowym lub domyślne okresy retencji).
Twoją odpowiedzialnością są: metryki aplikacyjne, logi biznesowe, konfiguracja alertów, dashboardy, SLO oraz decyzje o retencji i samplingach. Różne modele usług (IaaS, PaaS, SaaS, serverless) oznaczają inną głębokość wglądu – i inne miejsce, gdzie trzeba dosztukować własny monitoring. Koszty i odpowiedzialność przesuwają się razem z wyborem modelu.
Fundamenty: rodzaje danych w monitoringu (metryki, logi, zdarzenia, trace’y)
Metryki: podstawa proaktywnych alertów
Metryki to zagregowane dane liczbowe, zazwyczaj w czasie. Są tanie w przechowywaniu i świetnie nadają się do wykrywania trendów oraz budowania alertów, które reagują, zanim użytkownik poczuje ból. Typowe przykłady:
liczba requestów na sekundę do API,
odsetek błędów HTTP 5xx,
średnie i percentylowe opóźnienie (latency),
użycie CPU, pamięci, I/O dysków,
długość kolejek (queue depth),
cache hit ratio.
Metryki świetnie sprawdzają się tam, gdzie potrzeba sygnału „coś się zmienia”, a nie szczegółowego kontekstu. Pozwalają zbudować SLI (Service Level Indicators) i SLO (Service Level Objectives), a następnie alerty oparte na tych wskaźnikach. Ich siła leży w tym, że można je łatwo agregować (sumy, średnie, percentyle) i prezentować na dashboardach.
Logi: kontekst i głębokie debugowanie
Logi to szczegółowy ślad tego, co dzieje się w systemie: komunikaty błędów, ostrzeżenia, logi biznesowe, ślady integracji. Zawierają dużo informacji, ale ich analiza przez człowieka jest kosztowna i czasochłonna. Jeszcze droższe jest długoterminowe przechowywanie w dużych wolumenach.
Logi przydają się szczególnie, gdy:
trzeba zrozumieć pojedynczy incydent (np. błąd z konkretnym requestem),
chodzi o problemy rzadkie i trudne do odtworzenia,
potrzebna jest analiza sekwencji zdarzeń (kto co wykonał, w jakiej kolejności),
wchodzi w grę audyt (bezpieczeństwo, zgodność z regulacjami).
W monitoringach cloud-native logi nie są pierwszą linią obrony. Alerty najlepiej trzymać na metrykach, a logi traktować jako źródło prawdy w śledztwie po incydencie lub przy głębszej analizie trendów błędów.
Zdarzenia i audyt konfiguracji
Zdarzenia (events) to wszelkiego rodzaju informacje o zmianach stanu w systemie: deploy nowych wersji, zmiany konfiguracji, skalowanie, restarty węzłów, zmiany w ustawieniach bezpieczeństwa, operacje administracyjne. W chmurze to także zdarzenia z warstwy platformy: zmiana reguł firewall, rotacja kluczy, zmiana uprawnień IAM.
Bez takiego tła trudno powiązać nagły skok błędów lub wzrost opóźnień z konkretną przyczyną. Zdarzenia wdrożeniowe powinny być widoczne na tych samych wykresach co metryki. Typowy schemat:
deploy o 10:15,
od 10:16 rośnie liczba błędów 500 na jednym z endpointów,
o 10:20 rośnie liczba retry w kolejce.
Dobrze zaprojektowany monitoring pozwala kliknąć w punkt na wykresie i zobaczyć: „w tym momencie została wypuszczona wersja X tej usługi”. Czas diagnozy skraca się z godzin do minut.
Trace’y rozproszone: kiedy są złotem, a kiedy przerostem formy
Trace rozproszony to ścieżka jednego żądania przez cały system: API gateway, kilka mikroserwisów, kolejka, baza danych, REST do systemu zewnętrznego. Każdy fragment ma swoją nazwę, czas wykonania, status, a całość wiąże correlation ID lub trace ID.
Trace’y błyszczą w sytuacjach, gdy:
architektura jest rozproszona (mikroserwisy, event-driven, wiele zależności),
problem dotyczy jedynie części żądań (np. tylko dla konkretnego klienta, regionu, feature flagi),
trzeba znaleźć wąskie gardło w łańcuchu wywołań (konkretny serwis wydłuża response time).
W prostych monolitycznych systemach trace’y bywają przerostem formy nad treścią: koszty wdrożenia i utrzymania przekraczają zysk. W takich przypadkach często wystarczą metryki + logi z dobrym correlation ID i podstawowe informacje o czasie wykonania krytycznych operacji.
Kiedy wystarczy metryka, a kiedy trzeba sięgnąć po log lub trace
Praktyczne podejście:
Metryka – gdy chodzi o pytanie „czy coś jest nie tak w zachowaniu całego systemu lub usługi?”. Np. rośnie error rate, rośnie latency, spada liczba transakcji na minutę.
Log – gdy trzeba zdiagnozować konkretny błąd, sprawdzić parametry requestu, komunikat z wyjątku, szczegóły integracji z zewnętrznym API.
Trace – gdy problem dotyczy przepływu przez wiele usług lub trwałości w czasie (np. żądanie „płynie” kilka minut, częściowo asynchronicznie).
Jeden z typowych wzorców: alert wychodzi z metryki SLI (np. spadek dostępności poniżej 99%), na dashboardzie widać który endpoint jest winny (metryki aplikacyjne), a z tego miejsca jednym kliknięciem przechodzi się do logów lub trace’ów z konkretnym correlation ID. Bez tego łańcucha czas od sygnału do diagnozy wydłuża się wielokrotnie.
Źródło: Pexels | Autor: AS Photography
Kluczowe metryki infrastruktury w chmurze, które naprawdę coś mówią
Compute: VM, kontenery i funkcje serverless
W warstwie compute podstawowe metryki są podobne jak on-premise, ale interpretacja bywa inna. Kluczowe wskaźniki:
CPU – procentowe zużycie CPU w czasie,
Pamięć – wykorzystanie RAM, page faults, OOM (Out Of Memory),
I/O – odczyty/zapisy na dysk, opóźnienia,
Throttling – w środowiskach z limitami (np. CPU limit w Kubernetesie),
Cold starts – w funkcjach serverless (czas startu zimnej instancji).
W VM i kontenerach CPU blisko 100% oznacza różne rzeczy w zależności od kontekstu. W systemie, który świadomie wypełnia CPU zadaniami batchowymi i ma kolejkę z priorytetyzacją, 90–95% zużycia jest normalne. W API, które powinno reagować w milisekundach, 80% CPU może już być problemem, jeśli rośnie latency i error rate.
W funkcjach serverless (np. AWS Lambda, Azure Functions) warto pilnować:
liczby wywołań,
czasów wykonania (wraz z percentylami),
liczby błędów,
liczby cold startów i ich wpływu na opóźnienia.
Storage: dyski, obiekty i bazy danych zarządzane
Warstwa storage w chmurze jest silnie zróżnicowana: klasyczne dyski podpięte do VM, obiekty w S3/Blob Storage oraz usługi bazodanowe typu managed. Każda z nich ma inny profil metryk i inne typowe pułapki.
W przypadku dysków (EBS, Persistent Disk, Managed Disks) najczęściej liczą się:
IOPS i throughput – rzeczywista liczba operacji na sekundę i przepustowość vs. deklarowany limit wolumenu,
latency I/O – czas pojedynczych operacji odczytu/zapisu,
burst credits – w tańszych klasach dysków chwilowe „dopalacze”, które się wyczerpują.
W przypadku storage obiektowego (S3, Blob) istotne są:
liczba requestów w czasie (GET/PUT/LIST),
rozmiar transferu – ingress/egress, wpływ na koszty,
latency operacji – szczególnie przy częstych małych plikach.
Bazy danych zarządzane (RDS, Cloud SQL, Azure Database) łączą metryki klasyczne z platformowymi. Typowy zestaw:
CPU i pamięć instancji bazy,
connection count – liczba aktywnych połączeń vs. limity planu,
buffer cache hit ratio – skuteczność cache w RAM,
I/O na poziomie storage bazy (IOPS, throughput, latency),
replication lag – opóźnienie replik, jeśli są używane read-replicas.
W praktyce najbardziej miarodajna jest kombinacja: latency zapytań + error rate (np. timeouts) + metryki storage. Samo wysokie CPU w bazie bez pogorszenia czasu odpowiedzi bywa normalne; alarmujący jest dopiero zestaw: rosnące opóźnienie, spadek throughputu transakcji i rosnący lag replik.
Sieć i load balancery: gdzie giną pakiety i czas
Sieć w chmurze to nie tylko klasyczne „bandwidth” i „packet loss”. Dochodzi warstwa usług zarządzanych: load balancery, VPN, peeringi, bramy NAT. Każda z nich ma swoje metryki, które pomagają odróżnić problem aplikacji od problemu infrastruktury.
Najbardziej użyteczne wskaźniki:
latency sieciowe między strefami/regionami lub do usług zewnętrznych,
connection errors po stronie load balancera (np. 502/503 generowane przez LB, a nie przez aplikację),
healthy/unhealthy hosts – wyniki health-checków backendów,
bandwidth i packet drops w krytycznych segmentach (np. między VPC a on-prem przez VPN),
active connections i new connections per second na load balancerze.
Zestawienie tych metryk z error rate aplikacji szybko pokazuje, czy problem leży „przed” aplikacją (np. load balancer nie widzi instancji), „w” aplikacji (błędy 5xx z backendu), czy „za” aplikacją (timeouty do bazy lub serwisów zewnętrznych). W porównaniu z on-premise łatwiej zdobyć szczegółowe metryki LB z chmury, ale trudniej zajrzeć w samą warstwę routingu wewnątrz dostawcy – trzeba więc bardziej polegać na tym, co daje platforma.
Usługi zarządzane: „black box” z przydatnymi wskaźnikami
Managed services (kolejki, cache, search, messaging, usługi ML) są wygodne, ale monitoring bywa ograniczony do zestawu metryk udostępnionych przez dostawcę. Zwykle pojawiają się:
throughput – liczba operacji na sekundę (put/get, publikacja/odbiór wiadomości),
opóźnienie operacji – end-to-end latency,
głębokość kolejek (queue depth) i age najstarszej wiadomości,
cache hit/miss dla usług cache’ujących (Redis, Memcached managed),
limity – zbliżanie się do quota (np. connections, throughput per shard).
W odróżnieniu od własnych instalacji, rzadko da się dołożyć niestandardowe metryki wewnątrz takiej usługi. Trzeba więc łączyć metryki platformowe z metrykami po stronie klienta (aplikacji), np. liczyć retry i timeouty w kodzie i korelować je z opóźnieniami raportowanymi przez samą usługę.
Metryki aplikacyjne: od prostego „up/down” do SLI opartych na użytkowniku
Techniczne vs. biznesowe metryki aplikacji
Monitoring aplikacyjny można podzielić na dwa poziomy. Po pierwsze, klasyczne metryki techniczne:
liczba requestów na endpoint,
error rate (np. odsetek HTTP 5xx, specyficznych wyjątków),
latency – średnia, P95, P99 per endpoint,
zajętość puli połączeń, długość kolejek wewnętrznych.
Po drugie, metryki bliskie biznesowi, np.:
liczba złożonych zamówień na minutę/godzinę,
współczynnik konwersji w lejku (widok produktu → koszyk → płatność),
liczba logowań udanych vs. nieudanych,
czas od rozpoczęcia procesu (np. onboarding) do jego zakończenia.
W środowisku cloud-native to właśnie te drugie najczęściej mówią, czy „produkcja jest zdrowa” z perspektywy użytkownika. Można mieć zero błędów HTTP 500, a jednocześnie zablokowaną ścieżkę płatności z powodu problemu z zewnętrznym providerem.
SLI i SLO: co naprawdę mierzyć dla użytkownika
SLI to konkretna metryka opisująca zachowanie systemu, a SLO to cel dla tej metryki (np. 99,9% dostępności w miesiącu). Zamiast mierzyć wszystko, lepiej wybrać kilka wskaźników, które użytkownicy rzeczywiście odczują:
dostępność (availability) kluczowych endpointów z punktu widzenia klienta,
czas odpowiedzi dla krytycznych operacji (np. checkout, wyszukanie),
poprawność (correctness) – brak błędów biznesowych, np. odrzucone transakcje, błędne faktury,
świeżość danych (freshness) – opóźnienie replik, czas propagacji eventów.
Przykład praktyczny: dla API płatności SLI może brzmieć: „odsetek udanych płatności zakończonych w mniej niż 3 sekundy w ciągu 5 minut”. SLO: „≥ 99,5% takich płatności”. Alert uruchamia się dopiero, gdy SLI spada poniżej progu, a nie przy każdej pojedynczej nieudanej transakcji.
Metryki syntetyczne vs. real user monitoring (RUM)
W chmurze łatwo zestawić dwa światy: testy syntetyczne (synthetic monitoring) oraz dane z prawdziwego ruchu użytkowników.
Monitoring syntetyczny to zaplanowane testy (np. co minutę) wykonujące symulowane żądania z konkretnych regionów. plusy:
umożliwia wykrycie problemu, zanim pojawi się ruch prawdziwych klientów,
obraca się wokół precyzyjnie zdefiniowanych scenariuszy (np. pełny flow logowania),
nie zależy od błędów po stronie użytkownika (lokalna sieć, stary browser).
Minus: pokazuje tylko to, co zostało zaprogramowane; nie łapie rzadkich edge-case’ów.
RUM (Real User Monitoring) mierzy rzeczywiste doświadczenie użytkowników – np. czas ładowania strony w przeglądarce, błędy JS, opóźnienia API z perspektywy klienta. plusy:
odzwierciedla realne warunki (sieć mobilna, różne kraje, różne urządzenia),
ujawnia problemy zależne od lokalizacji i peeringów,
pozwala mierzyć „czas do gotowości” aplikacji (Time to Interactive, LCP).
Minus: reaguje dopiero, gdy problem dotknie ludzi. Sensowna architektura łączy oba podejścia: syntetyki jako „czujniki dymu”, RUM jako prawdziwy barometr UX.
Instrumentacja: jak wyciągnąć metryki z kodu
Do wyboru są trzy główne podejścia:
biblioteki metryczne w kodzie (Prometheus, OpenTelemetry SDK, biblioteki vendorów),
auto-instrumentacja – agenty, które wstrzykują się w runtime (Java, .NET, Node.js),
exportery pośrednie, np. Nginx, Envoy, sidecar w Kubernetesie.
Ręczna instrumentacja (biblioteki) daje największą kontrolę; można mierzyć dokładnie te punkty, które mają znaczenie biznesowe (np. liczba generowanych ofert, czas obsługi konkretnego workflow). Wymaga jednak dyscypliny i współpracy zespołów developerskich z SRE/DevOps.
Auto-instrumentacja jest szybkim sposobem na start: bez dotykania kodu pojawiają się metryki dotyczące requestów HTTP, zapytań do bazy, kolejek. Ograniczenie: widoczny jest głównie poziom techniczny, a nie logika biznesowa. W projektach greenfield często łączy się oba podejścia: auto-instrumentacja jako baza + dołożone ręcznie metryki kluczowych scenariuszy.
Źródło: Pexels | Autor: Atypeek Dgn
Logi, które pomagają, a nie zasypują – praktyka w środowisku cloud
Strukturyzacja logów: koniec z parsowaniem byle jakich stringów
W środowisku cloud logi z wielu usług trafiają zwykle do jednego systemu (ELK, Loki, Cloud Logging, Datadog, Splunk). Swobodne, tekstowe logowanie szybko się mści. Zdecydowanie skuteczniejsze są logi strukturyzowane, najczęściej w JSON-ie:
każdy wpis ma stały zestaw pól (timestamp, level, service, request_id, user_id, correlation_id),
dodatkowe pola domenowe (order_id, payment_provider, feature_flag) pozwalają filtrować logi po biznesie, nie tylko po technikaliach,
łatwo jest budować wykresy oparte na polach liczbowych (np. kwota transakcji).
W porównaniu z logami „liniowymi” (surowy tekst) zyskuje się możliwość analizy na poziomie zapytań, klientów, funkcji biznesowych. Kosztowne jest pierwsze przejście – zmiana formatu – ale później każdy kolejny problem diagnozuje się szybciej.
Poziomy logowania i redukcja szumu
Główna różnica między on-premise a chmurą polega na tym, że „więcej” logów wprost oznacza „drożej” na fakturze. Trzeba więc traktować poziomy logowania bardziej świadomie:
DEBUG – tylko w środowiskach testowych lub tymczasowo w produkcji przy konkretnym incydencie,
INFO – zdarzenia biznesowe i kluczowe kroki, ale bez spamowania (np. nie każdy request, tylko zakończone workflowy),
WARN – anomalie, które nie przerywają działania, ale w dużej liczbie mogą sygnalizować problem,
ERROR – faktyczne błędy, które wpływają na użytkownika lub dane,
FATAL – sytuacje krytyczne, po których usługa nie działa.
Najczęstszy błąd w chmurze: pozostawienie ogromnej liczby logów INFO/DEBUG z czasów developmentu, które w produkcji nic nie wnoszą. Lepsze jest mądre wybranie kilku punktów w przepływie, które logują pełny kontekst, niż setki małych wpisów bez sensu.
Filtrowanie, sampling i retencja logów
Trzy dźwignie pomagają trzymać koszty i nie utonąć w danych:
filtrowanie u źródła – agent lub sidecar (np. Fluent Bit) może odrzucać konkretne klasy logów (np. głośne health-checki) zanim trafią do centralnego systemu,
sampling – np. tylko 1% logów INFO z bardzo głośnych endpointów, pełny zestaw ERROR/WARN bez samplingu,
zróżnicowana retencja – logi techniczne trzymane 7–14 dni, logi bezpieczeństwa/audytowe kilka miesięcy lub lat, często w tańszym, chłodnym storage.
W praktyce zwykle zaczyna się od pełnego zbierania logów, a potem na podstawie analizy rachunków i typowych zapytań ustala się, co można przyciąć. Najłatwiej ograniczać logi powtarzalne (np. endpoint health) oraz rozbudowane stack trace’y, które można skrócić lub agregować.
Correlation ID i powiązanie logów między usługami
W architekturach mikroserwisowych logi są użyteczne dopiero wtedy, gdy można prześledzić jeden request przez wiele usług. Tu pojawia się correlation ID:
generowany na wejściu (API gateway, edge service),
przekazywany w nagłówkach HTTP, komunikatach w kolejce, eventach,
zapisywany w każdym logu jako pole.
Maskowanie danych wrażliwych i kontekst bezpieczeństwa
Centralizacja logów w chmurze zderza się z tematyką bezpieczeństwa i zgodności. Ten sam mechanizm, który ułatwia debugowanie, zwiększa też potencjalny zasięg wycieku danych. Dlatego logowanie trzeba projektować z myślą o minimalizacji danych wrażliwych już na poziomie aplikacji:
maskowanie numerów kart, PESEL, adresów e‑mail (np. tylko ostatnie 4 cyfry lub fragment nazwy),
nie logowanie pełnych tokenów JWT, kluczy API, tajnych nagłówków,
zastępowanie wrażliwych pól placeholderami (np. <PII_REMOVED>) i przechowywanie szczegółów w bezpieczniejszych systemach.
W środowiskach regulowanych (fintech, medyczny) dodatkowo stosuje się policy as code w agentach logujących – reguły, które parsują wpisy i automatycznie anonimizują wybrane pola, zanim trafią do systemu SIEM czy narzędzia observability. Dwa podejścia spotykają się w praktyce:
sanityzacja w aplikacji – więcej pracy po stronie devów, ale pełna kontrola nad tym, co opuszcza proces,
sanityzacja w agencie – szybsza do wdrożenia, pozwala „naprawić” stare serwisy, ale opiera się na regułach opartych o wzorce (regexy), które mogą nie złapać wszystkich przypadków.
W projektach greenfield zwykle wygrywa pierwsza opcja, w migracjach lift‑and‑shift częściej druga. Często kończy się hybrydą: aplikacja maskuje to, co zna domenowo, agent pilnuje wzorców technicznych (np. ciągów podobnych do numerów kart czy tokenów OAuth).
Logi zdarzeń biznesowych vs. logi techniczne
W dużych systemach coraz częściej rozdziela się logi techniczne (stack trace, błędy, komunikaty frameworków) od logów zdarzeń biznesowych (złożone zamówienie, rozpoczęty onboarding, odrzucona płatność). Te drugie często bliższe są analityce niż klasycznemu debugowaniu.
W podejściu „event sourcing light” takie zdarzenia lądują najpierw w kolejce lub strumieniu (Kafka, Kinesis, Pub/Sub), a dopiero z nich kopiowane są do dwóch światów:
systemu analitycznego (BigQuery, Snowflake, Redshift) – do raportów i dashboardów biznesowych,
systemu logowania/observability – do korelacji z metrykami i trace’ami.
Różnica w stosunku do klasycznych logów polega na tym, że wpis biznesowy jest z definicji stabilny w czasie (ma określony schemat, wersjonowanie, jasną semantykę). To ułatwia analizę trendów i budowanie alertów opartych nie na błędach technicznych, ale na wskaźnikach typu „odsetek odrzuconych wniosków kredytowych w danym kanale sprzedaży”.
Trace’y jako „klej” między metrykami i logami
Same logi i metryki często nie wystarczają do zrozumienia incydentu w mikroserwisach. Trace’y (distributed tracing) pozwalają zobaczyć całą ścieżkę requestu: który serwis kogo woła, gdzie pojawia się opóźnienie, jak zmienia się kontekst.
Typowy zestaw danych w pojedynczym trace’u to:
span – jednostkowa operacja (np. wywołanie endpointu, zapytanie do bazy),
trace_id – identyfikator całej ścieżki,
span_id i parent_span_id – powiązania między kolejnymi krokami,
tagi/atrybuty – informacje o endpointach, statusach, rozmiarach payloadu, tenantach.
W praktyce trace’y dobrze rozwiązują dwa typowe problemy:
„Gdzie ginie czas?” – opóźnienia okazują się nie w samej aplikacji, lecz w zewnętrznym API, którym nikt się wcześniej nie interesował, bo metryki patrzyły tylko na infrastrukturę.
„Dlaczego ten request jest inny?” – trace pokazuje, że przy specyficznej kombinacji parametrów aplikacja przechodzi przez alternatywną ścieżkę kodu lub dodatkowy serwis.
Standard propagacji kontekstu: W3C Trace Context i bagaż
Trace’y skutecznie działają dopiero wtedy, gdy informacja o nich przechodzi przez wszystkie składowe systemu. Współczesne stacki coraz częściej opierają się na standardzie W3C Trace Context, który definiuje nagłówki takie jak traceparent i tracestate. Dzięki nim:
gateway, backend, kolejki, funkcje serverless i zewnętrzne usługi rozumieją ten sam identyfikator trace’a,
narzędzia od różnych vendorów są w stanie „skleić” ścieżkę bez vendor‑lock‑in w warstwie protokołu.
Obok tego pojawia się baggage – mechanizm przenoszenia dodatkowego kontekstu (np. tenant_id, plan=premium) między usługami. Różnica w stosunku do logów polega na tym, że bagaż „jedzie” z requestem i może wpływać na zachowanie aplikacji (np. inne limity dla różnych planów), a logi tylko opisują to, co już się wydarzyło. Zbyt rozbudowany bagaż zwiększa rozmiar nagłówków i koszty, dlatego typowo ogranicza się go do 2–3 naprawdę potrzebnych atrybutów.
Sampling trace’y: jak widzieć problemy bez bankructwa
Wysokoruchowe API wygeneruje ogromną liczbę trace’y. Przechowywanie ich wszystkich bywa nieopłacalne. Tu pojawia się sampling:
head sampling – decyzja o próbkowaniu zapada na wejściu (np. co 100. request). Tanie w implementacji, ale może przegapić rzadkie, lecz ważne błędy.
tail sampling – decyzja podejmowana po zakończeniu requestu na podstawie jego cech (np. status HTTP, latency, typ klienta). Droższe obliczeniowo, ale pozwala zbierać niemal wszystkie trace’e z błędami lub bardzo wolne, a mniej interesować się resztą.
Typowa konfiguracja w środowisku produkcyjnym:
100% trace’y z ERROR lub 5xx,
większy sampling (np. 20–30%) dla bardzo wolnych requestów powyżej ustalonego progu,
niski sampling (1–5%) dla „zdrowego” ruchu, zróżnicowany per endpoint (więcej dla rzadkich ścieżek).
Różnica w stosunku do on‑premise jest prosta: kiedyś ograniczeniem była głównie pojemność storage, w chmurze równie istotny jest koszt egressu i opłaty za produkt APM/observability, który liczy trace’y jako jednostkę rozliczeniową.
Alerty, które nie budzą bez sensu: projektowanie progów i reguł
Alerting a monitoring: dwa różne cele
Monitoring opisuje stan systemu. Alerting ma zmusić ludzi lub automaty do działania. To drobna różnica w teorii, w praktyce decyduje o tym, czy zespół będzie reagował, czy wyciszy wszystkie kanały. Dobre reguły alertowe spełniają trzy kryteria:
wymagają akcji (manualnej lub automatycznej),
dotyczą obecnego lub bardzo bliskiego problemu, a nie spekulacji,
są zrozumiałe z perspektywy biznesu („transakcje nie przechodzą”), a nie tylko techniki („CPU > 80%”).
W praktyce prowadzi to do rozróżnienia na:
alerty symptomów – to, co widzi użytkownik (spadek odsetka udanych płatności, wzrost błędów 5xx),
alerty przyczyn – techniczne sygnały pomocne w diagnozie (błąd w kolejce, niedostępne zewnętrzne API).
Symptomy powinny iść na pager, przyczyny częściej na kanały o niższym priorytecie lub jako kontekst w narzędziu do obsługi incydentów.
Progi oparte na SLO vs. progi „techniczne”
Dwa podejścia widać wyraźnie na przykładzie API produkcyjnego:
progi techniczne: „więcej niż 5% requestów HTTP 5xx w ciągu 5 minut” albo „latency P95 powyżej 800 ms”,
progi SLO-based: „prognozowany budżet błędów wyczerpie się w ciągu 4 godzin” albo „utrata 20% budżetu w ostatniej godzinie”.
Reguły oparte o SLO lepiej skalują w dużych systemach, bo biorą pod uwagę, jak długo może trwać problem i jaki ma wpływ na całościową obietnicę złożoną użytkownikom. Dają też mniej szumu przy krótkich pikach ruchu. Z kolei progi techniczne są prostsze do zrozumienia i wdrożenia, co bywa istotne na starcie migracji do chmury.
Rozsądnym kompromisem jest kombinacja:
1–2 alerty SLO per kluczowy produkt (np. płatności, logowanie, wyszukiwanie),
kilka alertów technicznych o niższym priorytecie, pilnujących infrastruktury (dyski, kolejki, worker pools).
Alerty oparte na trendach vs. stałe progi
W środowisku on‑premise progi często były „sztywne”: CPU powyżej 90% przez 5 minut, dysk powyżej 80% itd. W chmurze, przy autoskalowaniu i zmiennym ruchu, lepiej sprawdzają się mechanizmy patrzące na odchylenia od typowego zachowania:
progi dynamiczne – wyznaczane z rolling window (np. średnia z 7 dni) z marginesem tolerancji,
detekcja anomalii – narzędzia APM, które same uczą się „normalnych” zakresów i flagują nietypowe wartości.
Porównanie podejść:
stałe progi – lepsze dla zasobów fizycznych (dysk, pamięć) i wskaźników „twardych” (np. przekroczenie limitu API partnera),
progi dynamiczne – sensowne przy zachowaniach silnie sezonowych (ruch dzienny vs. nocny, dni tygodnia, okresy świąteczne).
Przykład: w e‑commerce alert na „spadek liczby transakcji o 30% względem typowego wtorku o tej godzinie” bywa użyteczniejszy niż sztywny próg „mniej niż X transakcji na godzinę”. Z drugiej strony brak miejsca na dysku w klastrze bazodanowym lepiej pilnować stałym, konserwatywnym limitem.
Najlepsze metryki i trace’y na niewiele się zdadzą, jeśli pager ogłasza alarm co kwadrans. Kilka praktycznych mechanizmów pomaga utrzymać higienę:
agregacja – zamiast jednego alertu na każdą instancję, jedna reguła na poziomie usługi / regionu (np. „co najmniej 3 instancje z 5 zgłosiły błąd health check”),
grupowanie incydentów – narzędzia typu incident management potrafią łączyć wiele podobnych zdarzeń w jeden „problem” (np. „Degradacja checkout EU‑west‑1”),
dedyplikacja – filtrowanie powtarzających się powiadomień o tym samym problemie, dopóki status się nie zmieni,
quiet hours / rate limiting – ograniczenie liczby powiadomień na kanał (Slack/SMS/PagerDuty) w określonym oknie czasu.
W odróżnieniu od on‑premise, gdzie zespół często siedział fizycznie blisko serwerowni i łatwiej było „na ucho” wychwycić problemy, w chmurze niemal wszystko przechodzi przez kanały cyfrowe. Tym bardziej trzeba pilnować, aby każde powiadomienie miało sensowną treść: co się dzieje, kogo dotyczy, jaki jest sugerowany pierwszy krok.
Runbooki i automatyczne działania po alercie
Alert bez jasnego „co dalej” zwiększa stres i wydłuża MTTR. W dojrzałych środowiskach każdy alert wysokiego priorytetu ma powiązany runbook – krótki opis kroków diagnostycznych i możliwych remediów. Najprostszy format to:
Opis problemu – „Spadek SLI płatności poniżej 99% w oknie 5 min”.
Potencjalne przyczyny – „problemy z providerem X, awaria kolejki Y, nowe wdrożenie w serwisie Z”.
Kroki sprawdzające – linki do dashboardów, komendy kubectl czy zapytania SQL.
Opcje mitigacji – feature flag off, rollback, zmiana konfiguracji routingu, przełączenie regionu.
Coraz częściej runbooki przeradzają się w automatyczne playbooki: system incident management sam odpala wstępne akcje (np. dodatkowe testy syntetyczne, restart konkretnej grupy podów, przełączenie ruchu na zdrowy region), a osoba on‑call dostaje już informacje po pierwszej próbie naprawy. Różnica między chmurą a on‑premise polega tu głównie na łatwości integracji z API dostawcy: skrypt może wywołać zmianę autoskalera, przełączyć load balancer czy podnieść tymczasowo limity.
Alerting w architekturach wieloregionowych i multi‑cloud
Najczęściej zadawane pytania (FAQ)
Na czym polega różnica między monitoringiem w chmurze a on‑premise?
Monitoring on‑premise opiera się zwykle na stałej liście serwerów i agentach zainstalowanych na konkretnych maszynach. Infrastruktura zmienia się rzadko, więc łatwo „odhaczyć” co jest monitorowane i śledzić zdrowie pojedynczych hostów.
W chmurze środowisko jest dynamiczne: instancje żyją krótko, działa autoskalowanie, a usługi są rozproszone po wielu środowiskach i regionach. Kluczowe jest więc monitorowanie poziomu usługi (API, mikroserwisu, kolejki), a nie pojedynczej maszyny. Zamiast „listy serwerów” używa się service discovery, tagów/labeli i integracji z API dostawcy chmury.
Czym różni się monitoring „pudełkowy” od podejścia cloud‑native?
Monitoring „pudełkowy” to klasyczne rozwiązania typu własny serwer monitoringu + agent na każdym serwerze, konfigurowane głównie ręcznie. Sprawdza się, gdy infrastruktura jest mała i stabilna, ale przy chmurze szybko zaczyna brakować skalowalności i elastyczności.
Podejście cloud‑native (Prometheus + Grafana, Datadog, New Relic, natywne narzędzia AWS/Azure/GCP) zakłada, że monitoring sam odkrywa nowe instancje, korzysta z API providera i integruje się z managed services oraz Kubernetesem czy serverless. Różnica jest podobna jak między ręcznym spisywaniem stanów magazynowych a systemem ERP, który sam zlicza stany na bieżąco.
Co to jest observability i czym różni się od tradycyjnego monitoringu?
Tradycyjny monitoring odpowiada głównie na pytanie „czy coś działa?” i bazuje na prostych metrykach typu CPU, RAM, status serwisu. Gdy system jest prosty, to często wystarcza, ale w złożonych architekturach rozproszonych łatwo utknąć na etapie „wiemy, że nie działa, ale nie wiemy dlaczego”.
Observability łączy trzy filary: metryki, logi i trace’y rozproszone. Dzięki temu można nie tylko zobaczyć, że np. rośnie latency, ale też prześledzić konkretne żądanie przez mikroserwisy, kolejki i bazy oraz zestawić metryki z logami. Innymi słowy: monitoring pyta „czy świeci się na czerwono?”, a observability pomaga dojść do przyczyny bez ciągłego dopisywania nowych logów i metryk ad hoc.
Jakie metryki, logi i alerty są kluczowe w monitoringu w chmurze?
W metrykach podstawą są wskaźniki obciążenia i jakości usługi: liczba requestów/s, odsetek błędów 5xx, latency (np. percentyl 95), wykorzystanie CPU/pamięci, długość kolejek, cache hit ratio. Te dane służą do budowy SLI/SLO i alertów reagujących na faktyczne problemy użytkowników, a nie na każdy skok CPU.
Logi najlepiej traktować jako źródło kontekstu: błędy aplikacyjne, logi biznesowe, zdarzenia integracyjne, audyt. Alerty opłaca się opierać głównie na metrykach, a logi wykorzystywać do analizy incydentów. Przykład: alert włącza się, gdy przez 5 minut odsetek 5xx przekracza określony próg; logi służą do zrozumienia, które endpointy i klienci wywołują błędy.
Jak ustawiać progi alertów w chmurze, żeby nie tonąć w szumie?
W podejściu cloud‑native progi alertów lepiej wiązać z SLO (np. dopuszczalny odsetek błędów lub opóźnień) niż z surowymi metrykami infrastruktury (np. „CPU > 70%”). Alert ma mówić „użytkownicy zaczynają mieć problem” zamiast „serwer ma chwilowo wysokie obciążenie”. Dobrze działają progi oparte na średnich kroczących i percentylach, a nie pojedynczych pikach.
Praktyczne podejście to podział na kilka poziomów: ostrzeżenia (warning) dla trendów, które mogą stać się problemem, oraz krytyczne alerty (critical) związane z przekroczeniem SLO lub realną niedostępnością usługi. W chmurze, gdzie autoskalowanie potrafi szybko łagodzić piki, agresywne alerty na każdy skok CPU zwykle prowadzą tylko do „alert fatigue”.
Jak w praktyce monitorować koszty i retencję danych (metryk, logów, trace’ów)?
W modelu pay‑as‑you‑go monitoring sam w sobie jest kosztem, więc potrzebny jest drugi „monitoring monitoringu”. Stosuje się metryki kosztowe (np. koszt logów na usługę, wolumen danych na indeks), limity retencji per typ danych oraz sampling trace’ów. Dane operacyjne (SLO, główne metryki) trzyma się dłużej, szczegółowe logi – krócej lub w tańszym storage.
Dobrym kompromisem jest podejście warstwowe: kluczowe metryki i logi zdarzeń bezpieczeństwa z długą retencją, pełne logi aplikacyjne jedynie dla produkcji i na krótszy okres, a trace’y próbkowane – intensywniej przy awariach, słabiej przy stabilnej pracy. W środowiskach, gdzie koszty rosną lawinowo, zwykle bardziej opłaca się dopracować metryki niż trzymać „wszystkie logi na wszelki wypadek”.
Co wchodzi w zakres shared responsibility przy monitoringu w chmurze?
Dostawca chmury odpowiada za fizyczną infrastrukturę, warstwę sieciową i dostępność usług bazowych oraz udostępnia swoje metryki (np. stan load balancerów, IOPS dysków, statystyki usług managed). Jednocześnie narzuca limity, domyślne okresy retencji i modele cenowe dla metryk, logów i trace’ów.
Po stronie zespołu leżą: metryki aplikacyjne i biznesowe, konfiguracja alertów, dobór SLO, projekt dashboardów oraz decyzje, co i jak długo przechowywać. Inaczej wygląda to dla IaaS (dużo własnego monitoringu), inaczej dla PaaS/serverless (mniej wglądu w infrastrukturę, więcej nacisku na poziom usługi i logikę aplikacji). W praktyce im wyższy poziom usługi (bliżej SaaS), tym bardziej monitorujesz zachowanie aplikacji i doświadczenie użytkownika, a mniej – surowe zasoby.
Najważniejsze wnioski
Monitoring w chmurze ma przede wszystkim pomagać w podejmowaniu decyzji w pierwszych minutach incydentu – ograniczać „szum” alertów i skupiać się na sygnałach, które realnie wpływają na działanie biznesu i zespół on‑call.
Środowisko cloud-native wymusza odejście od monitoringu opartego na „liście serwerów” na rzecz dynamicznego service discovery, tagów/labeli oraz agregacji metryk na poziomie usług, środowisk i regionów, a nie pojedynczych maszyn.
Klasyczny monitoring „pudełkowy” dobrze sprawdza się w stabilnych, on-premise’owych infrastrukturach, natomiast w chmurze skuteczniejsze są natywne rozwiązania (Prometheus, Datadog, usługi providerów), które skalują się poziomo i integrują się z API oraz usługami managed.
Różnica między monitoringiem a observability polega na tym, że monitoring odpowiada na pytanie „czy działa”, a observability – „dlaczego nie działa”, wykorzystując wspólnie metryki, logi i trace’y rozproszone, co jest kluczowe w mikroserwisach, architekturze event-driven i serverless.
Alerty w chmurze powinny być oparte na SLO/SLA i dobrze dobranych progach, łączących metryki infrastruktury z metrykami aplikacyjnymi i biznesowymi; inaczej zespół będzie reagował głównie na problemy techniczne, a nie na realne degradacje doświadczenia użytkownika.
W modelu pay-as-you-go monitoring sam staje się kosztem, dlatego trzeba świadomie zarządzać retencją metryk i logów, samplingiem trace’ów oraz zakresem zbieranych danych, zamiast „logować wszystko na zawsze”.
