Amazon DOP-C02: Monitorowanie, logowanie i obserwowalność — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Część AWS DevOps Engineer Professional DOP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Monitorowanie, logowanie i obserwowalność w AWS wymagają łączenia metryk, logów, śladów (traces), zdarzeń i telemetrii kondycji w użyteczne sygnały. Efektywne architektury wykorzystują Amazon CloudWatch do obsługi metryk, alarmów i dashboardów; CloudWatch Logs i Logs Insights do pozyskiwania i analizy logów; AWS X-Ray do śledzenia rozproszonego (distributed tracing); AWS CloudTrail do audytu i zapewnienia integralności; Amazon EventBridge do wykrywania i automatyzacji opartej na zdarzeniach; AWS Health do zdarzeń serwisowych specyficznych dla konta; oraz scentralizowane potoki (Kinesis Data Firehose i OpenSearch) do wyszukiwania i korelacji na dużą skalę. Poniższe wzorce kładą nacisk na redukcję szumu, precyzyjne kierowanie sygnałów, automatyzację oraz operacje w środowiskach wielokontowych i wieloregionowych.

Metryki, alarmy, dashboardy i alarmy złożone CloudWatch

Metryki CloudWatch są podstawą dla SLO, skalowania i alertów. Publikuj niestandardowe metryki z precyzyjnymi wymiarami, aby izolować sygnały (na przykład apiOperation, appVersion, statusCode). Używaj formatu CloudWatch Embedded Metric Format (EMF) ze strukturalnymi logami, aby efektywnie emitować wymiary o wysokiej kardynalności z Lambda, kontenerów i EC2, unikając narzutu związanego z API PutMetricData.

Konfiguruj alarmy z solidną ewaluacją:

Wybieraj okresy dopasowane do ziarnistości danych i okien czasowych SLO.
Ustawiaj datapointsToAlarm (m z n), aby zapewnić odporność na przejściowy szum.
Używaj TreatMissingData, aby unikać fałszywych alarmów podczas wdrożeń lub przerw w działaniu.
Wykorzystuj pasma detekcji anomalii, gdy wartości bazowe zmieniają się w zależności od sezonowości, oraz metric math do tworzenia wskaźników pochodnych (latencja p95, procent błędów, wskaźniki nasycenia).
Dołączaj akcje do alarmów: powiadamiaj przez SNS, twórz OpsItems w OpsCenter, wykonuj automatyzacje SSM lub odzyskuj instancje EC2. Polityki skalowania mogą odwoływać się do stanów alarmów w celu podjęcia działań, ale alarmy złożone nie mogą bezpośrednio wyzwalać skalowania.

Alarmy złożone (Composite alarms) redukują zmęczenie alarmami, łącząc wiele alarmów składowych za pomocą logiki AND/OR. Na przykład, alarmuj tylko wtedy, gdy latencja p95 jest wysoka ORAZ wskaźnik błędów 5xx przekracza próg ORAZ nasycenie CPU utrzymuje się, co pozwala dostosować alerty do rzeczywistego wpływu na użytkownika. Alarmy złożone akceptują aktualizacje stanu od alarmów podrzędnych z różnych regionów/kont za pośrednictwem obserwowalności międzykontowej lub strumieni metryk (metric streams) do konta centralnego.

Dashboardy wizualizują kluczowe wskaźniki z różnych usług. Używaj widżetów do wyświetlania metryk, wyników zapytań Logs Insights i statusu alarmów. Standaryzuj konwencje dotyczące dashboardów (nazewnictwo, zakresy czasowe, nakładki z SLO) i wykorzystuj widoki międzyregionalne i międzykontowe za pomocą CloudWatch Observability Access Manager (OAM). Do korelacji ad hoc, przypinaj widżety Logs Insights i X-Ray ServiceLens obok widżetów mapy usług i wskaźników błędów Kinesis Firehose.

CloudWatch Logs: Grupy logów, filtry metryk, filtry subskrypcji i Logs Insights

Strukturuj grupy logów według aplikacji/komponentu i etapu cyklu życia. Ustawiaj jawne polityki retencji (nie polegaj na opcji „Never Expire”) i włączaj szyfrowanie KMS tam, gdzie jest to wymagane. Używaj polityk zasobów i precyzyjnych uprawnień IAM do kontrolowania producentów i subskrybentów. W przypadku pozyskiwania danych o wysokiej przepustowości, zapewnij odpowiednią współbieżność strumieni logów i batching.

Filtry metryk (Metric filters) przekształcają wzorce w logach na metryki. Zdefiniuj wzorzec filtra z wyodrębnionymi tokenami (w formacie JSON lub rozdzielanymi spacją) i przypisz tokeny do wymiarów metryk. Umożliwia to realizację przypadków użycia, takich jak publikowanie metryk per-API, per-wersja, per-kod-odpowiedzi bezpośrednio z logów, bez modyfikowania producentów. Upewnij się, że jednostki i wartości domyślne są poprawne; preferuj wartość 1 na zdarzenie i obliczaj wskaźniki za pomocą metric math. Używaj tych metryk do alertów SLO i na dashboardach.

Filtry subskrypcji (Subscription filters) strumieniują logi w czasie zbliżonym do rzeczywistego do:

Kinesis Data Firehose w celu transformacji i dostarczenia do S3/OpenSearch.
Kinesis Data Streams dla niestandardowych konsumentów.
Lambda w celu niestandardowego routingu, redakcji danych osobowych (PII) lub powiadomień opartych na zdarzeniach. Użyj CloudWatch Logs destination z rolą IAM do subskrypcji międzykontowych. Zaplanuj mechanizmy ponawiania prób i backpressure; Lambda i Firehose zapewniają odpowiednio wbudowane ponawianie prób oraz kolejki DLQ / buckety S3 na błędy.

CloudWatch Logs Insights umożliwia interaktywne, serwerowe zapytania do logów. Podstawowe operatory to fields, filter, parse, stats, sort, limit, dedup oraz bin do grupowania w przedziałach czasowych. Parsuj pola JSON lub używaj parsowania w stylu grok dla logów tekstowych. Przykłady:

filter status >= 500 | stats count() by apiOperation, appVersion
parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service Zapisuj często używane zapytania jako QueryDefinition, aby umożliwić ich ponowne wykorzystanie przez zespół, i osadzaj je na dashboardach jako widżety zapytań. W celu automatyzacji, zaplanuj uruchamianie funkcji Lambda za pomocą EventBridge, aby wykonywała StartQuery/GetQueryResults i publikowała podsumowania do SNS lub OpsCenter. Ograniczaj zakres zapytania do określonych grup logów i okien czasowych, aby kontrolować koszty.

AWS X-Ray: Śledzenie, reguły próbkowania, mapy usług i adnotacje

X-Ray przechwytuje rozproszone ślady (traces) między usługami, aby znaleźć źródła opóźnień i granice błędów. Instrumentuj usługi za pomocą AWS Distro for OpenTelemetry (ADOT) lub X-Ray SDK, propaguj nagłówek śledzenia (np. X-Amzn-Trace-Id) i uruchamiaj demona/agenta X-Ray tam, gdzie jest to potrzebne (ECS/EKS/EC2). Wiele usług zarządzanych integruje się natywnie (API Gateway, ALB poprzez logi dostępowe przekazujące ślady, Lambda z aktywnym śledzeniem, Step Functions poprzez subsegmenty).

Reguły próbkowania (sampling rules) kontrolują wolumen danych i wierność sygnału. Użyj centralnego zestawu reguł próbkowania z:

Stałym rezerwuarem (reservoir) na sekundę dla bazowych śladów dla każdej usługi.
Procentowym próbkowaniem opartym na wskaźniku (rate-based) w celu skalowania wraz z przepustowością.
Priorytetem reguły i dopasowywaniem usług/URL dla gorących ścieżek (hot paths) i scenariuszy błędów. Zwiększ próbkowanie podczas incydentów i dla ruchu typu canary, aby chronić obserwowalność, jednocześnie zarządzając kosztami.

Mapy usług (service maps) wizualizują graf wywołań, pokazując krawędzie z opóźnieniami, wskaźnikami błędów i wskaźnikami dławienia (throttling). Analizuj szczegółowo ślady (traces), aby badać segmenty i subsegmenty pod kątem zależności podrzędnych (downstream). Używaj adnotacji (indeksowane pary klucz-wartość) do filtrowania o wysokiej kardynalności, takich jak customerTier, apiOperation, appVersion lub identyfikatory żądań AWS. Używaj metadanych do przechowywania szczegółowego, nieindeksowanego kontekstu, aby uniknąć nadmiernego rozrostu indeksu. Połącz grupy śledzenia X-Ray z CloudWatch ServiceLens, aby korelować logi, metryki i ślady w jednym widoku. Twórz wyrażenia filtrujące (np.

undefined

), aby izolować regresje i eksportować identyfikatory śladów do ukierunkowanego przeszukiwania logów.

Zarządzanie i zdarzenia: CloudTrail, EventBridge i AWS Health

CloudTrail rejestruje aktywność API na potrzeby zarządzania (governance) i analizy śledczej. Włącz ścieżkę (trail) organizacyjną na wszystkich kontach i we wszystkich regionach, dostarczaj logi do scentralizowanego bucketu S3 z SSE-KMS, włącz walidację plików logów i zintegruj z CloudWatch Logs w celu wykrywania zdarzeń w czasie zbliżonym do rzeczywistego. Rozróżnij klasy zdarzeń:

Zdarzenia zarządzania (Management events): płaszczyzna sterowania (np. CreateUser, RunInstances). Skonfiguruj tak, aby w razie potrzeby obejmowały zdarzenia tylko do odczytu i tylko do zapisu.
Zdarzenia danych (Data events): operacje na płaszczyźnie danych o dużej objętości, takie jak dostęp do obiektów S3, wywołania Lambda Invoke, operacje API na elementach DynamoDB, wywołania serwera API EKS. Ograniczaj zakres zdarzeń danych selektywnie (według bucketu/funkcji/tabeli), aby kontrolować koszty. Użyj CloudTrail Insights do wykrywania nietypowych skoków aktywności API i przekazuj zdarzenia CloudTrail do EventBridge w celu automatycznej naprawy. Weryfikuj integralność logów za pomocą plików skrótów (digest files) i polecenia AWS CLI

undefined

podczas audytów.

EventBridge dostarcza szynę zdarzeń (event fabric) do wykrywania i automatyzacji. Używaj domyślnej magistrali zdarzeń (default event bus) dla zdarzeń usług AWS i twórz niestandardowe magistrale dla zdarzeń z domeny aplikacji. Definiuj wzorce zdarzeń (event patterns) dopasowujące źródło (source), typ szczegółów (detail-type), pola szczegółów (detail), prefiksy, zakresy numeryczne i warunki „wszystko oprócz” (anything-but). Stosuj transformatory wejściowe (input transformers) do przekształcania zdarzeń, dołączaj polityki oparte na zasobach (resource-based policies) do publikowania między kontami i konfiguruj ponawianie prób (retry) / DLQ na celach (targets). Typowe cele (targets) obejmują Lambda (naprawa), Step Functions (orkiestracja), SQS (odsprzęganie), Systems Manager Automation (działania operacyjne), CodePipeline (wyzwalacze CI) i SNS (powiadomienia). Archiwizuj i odtwarzaj zdarzenia, aby odzyskać sprawność po awariach konsumentów, i używaj rejestru schematów (schema registry) do generowania silnie typowanych modeli zdarzeń.

AWS Health udostępnia specyficzne dla konta zdarzenia serwisowe, zaplanowane zmiany i problemy operacyjne. Integruj poprzez EventBridge ze źródłem

undefined

i typem szczegółów

undefined

, aby kierować zdarzenia do kanałów incydentów, otwierać OpsItems w OpsCenter lub wyzwalać bezpieczne zamykanie/skalowanie na czas okien konserwacyjnych. Użyj widoku organizacyjnego (Organizational View) z delegowanym kontem administratora, aby agregować zdarzenia Health ze wszystkich kont, i rozważ użycie AWS Health API lub rozwiązania AWS Health Aware do przesyłania wyselekcjonowanych powiadomień do systemów dyżurów (on-call).

Scentralizowane logowanie za pomocą Kinesis Data Firehose i OpenSearch

Strategia logowania obejmująca wiele kont i regionów (multi-account, multi-Region) standaryzuje pozyskiwanie i przeszukiwanie danych. Na każdym koncie produkującym logi (producer account) skonfiguruj filtry subskrypcji CloudWatch Logs do docelowego zasobu Logs na innym koncie (cross-account), który jest obsługiwany przez centralny strumień Kinesis Data Firehose. Włącz funkcje Firehose:

Transformacja danych za pomocą Lambda w celu normalizacji (do formatu JSON), redakcji danych osobowych (PII) i wzbogacania o metadane konta AWS, regionu, VPC i usługi.
Kompresja (GZIP) i dynamiczne partycjonowanie podczas dostarczania do S3 w celu optymalizacji wydajności zapytań w Athena.
Szyfrowanie za pomocą KMS i dostarczanie w ramach VPC do prywatnych punktów końcowych (private endpoints). Dostarczaj dane do Amazon OpenSearch Service w celu wyszukiwania z niskim opóźnieniem i wizualizacji w panelach Kibana/OpenSearch Dashboards. Używaj szablonów indeksów (index templates), polityk ILM/ISM do rotacji (rollover) i retencji danych oraz szczegółowych polityk dostępu (fine-grained access policies) mapujących użytkowników na wzorce indeksów (np. według konta/zespołu/usługi). Skonfiguruj zapisywanie błędnych dokumentów do S3 i monitoruj metryki dostarczania Firehose oraz pozyskiwania danych przez OpenSearch (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests). W przypadku bardzo dużej ilości danych rozważ składowanie wszystkich logów w S3 za pośrednictwem Firehose i przesyłanie strumieniowe tylko podzbioru do OpenSearch, z wykorzystaniem zapytań Athena na żądanie do danych w S3 w celu analizy rzadkich przypadków (long-tail investigations) i kontroli kosztów.

Połącz ten potok (pipeline) z filtrami metryk CloudWatch w celu uzyskania szybkich, tanich liczników oraz z Logs Insights do dogłębnych zapytań ad hoc. Używaj reguł EventBridge wyzwalanych przez anomalie w Firehose/OpenSearch lub alarmy CloudWatch, aby inicjować działania naprawcze (remediations) lub zgłaszać incydenty.

Praktyczny scenariusz problemowy

Airbnb doświadcza okresowych skoków błędów i opóźnień API w mikrousługach wdrożonych na EKS i Lambda, przy wielu wersjach aplikacji mobilnej dostępnych dla użytkowników. Dział operacyjny (Operations) potrzebuje wykrywania w czasie zbliżonym do rzeczywistego z podziałem na operację API, kod odpowiedzi i wersję aplikacji; szybkiej analizy przyczyn źródłowych (root cause analysis) na podstawie śladów (traces) i logów; zautomatyzowanej naprawy dla znanych wzorców awarii; oraz ścieżek audytowych (audit trails) spełniających wymogi ładu korporacyjnego (governance).

Standaryzacja logowania strukturalnego

Zaimplementuj logi JSON w formacie EMF (Embedded Metric Format) w usługach (EKS, Lambda), zawierające pola takie jak apiOperation, statusCode, appVersion, tenantId i latencyMs.
Dlaczego: EMF umożliwia bezpośrednią ekstrakcję metryk w CloudWatch przy niskim narzucie i z wymiarami o wysokiej kardynalności (high-cardinality dimensions) dla precyzyjnych alarmów.

Tworzenie filtrów metryk w CloudWatch Logs

Dla każdej grupy logów usługi zdefiniuj filtry metryk, które inkrementują liczniki z podziałem na apiOperation, statusCode i appVersion.
Dlaczego: Generuje to metryki dla każdego wymiaru bez dodatkowych ścieżek w kodzie, umożliwiając tworzenie paneli (dashboards) i alarmów operacyjnych (actionable alarms) dla każdej wersji API i klienta.

Budowa warstwowych alarmów CloudWatch i alarmu złożonego (composite alarm)

Ustaw alarmy na 95. percentyl opóźnienia (p95 latency), wskaźnik błędów 5xx oraz nasycenie (saturacja) zasobów (CPU, pamięć, współbieżność/dławienie). Stwórz alarm złożony: LatencyHigh AND ErrorsHigh dla 2 z 3 kolejnych okresów.
Dlaczego: Redukuje to szum informacyjny i pozwala skupić się na incydentach mających wpływ na użytkownika.

Wdrożenie śledzenia X-Ray z ukierunkowanym próbkowaniem (sampling)

Użyj kolektorów ADOT na EKS i aktywnego śledzenia (active tracing) dla Lambda. Zdefiniuj reguły próbkowania, aby przechwytywać wszystkie ślady błędów (error traces) i reprezentatywną próbkę udanych wywołań, z wyższym próbkowaniem dla nowych wersji aplikacji.
Dlaczego: Gwarantuje to wgląd w awarie i wystarczające pokrycie do identyfikacji wąskich gardeł wydajnościowych (performance hotspots), jednocześnie kontrolując koszty.

Korelacja danych za pomocą ServiceLens i Logs Insights

Stwórz panele łączące widżety metryk, mapę usług X-Ray (service map) i zapytania Logs Insights (np.

undefined

Dlaczego: Korelacja danych w jednym miejscu (single-pane) przyspiesza diagnozę, w której operacji i wersji klienta nastąpiła regresja.

Centralizacja logów przez Firehose do OpenSearch i S3

Skonfiguruj filtry subskrypcji do centralnego strumienia Firehose z transformacją Lambda w celu normalizacji, redakcji PII i wzbogacenia o dane konta/regionu. Dostarczaj dane do OpenSearch dla 7-dniowego dostępu do danych gorących (hot search) oraz do S3 w celu trwałego przechowywania i zapytań Athena.
Dlaczego: Umożliwia to szybkie, międzyzespołowe przeszukiwanie bieżących problemów oraz tanią analizę historyczną.

Automatyzacja wykrywania i naprawy za pomocą EventBridge

Stwórz reguły EventBridge dla zmian stanu alarmów CloudWatch i wybranych zdarzeń zapisu API z CloudTrail (np. modyfikacje grup bezpieczeństwa). Cele (Targets): funkcja Lambda do bezpiecznego wycofywania zmian (np. przywracanie flag funkcyjnych) i Step Functions do wieloetapowych działań naprawczych.
Dlaczego: Pętle kontrolne sterowane zdarzeniami (event-driven control loops) skracają średni czas do naprawy (MTTR) i wymuszają stosowanie barier ochronnych (guardrails).

Integracja z AWS Health i obsługa prac konserwacyjnych

Dodaj reguły EventBridge dla zdarzeń aws.health dotyczących EC2, EKS lub sieci. Jako cel ustaw SSM Automation, aby odizolować i opróżnić węzły (cordon/drain nodes) lub przenieść ruch.
Dlaczego: Proaktywne łagodzenie skutków zaplanowanych lub operacyjnych problemów redukuje przestoje.

Wzmocnienie ładu korporacyjnego (governance) za pomocą ścieżki CloudTrail dla organizacji i weryfikacji integralności

Włącz ścieżkę (trail) dla całej organizacji, obejmującą wiele regionów, z zdarzeniami danych (data events) dla S3 i Lambda, szyfrowaniem SSE-KMS i walidacją plików logów. Przesyłaj strumieniowo do CloudWatch Logs i OpenSearch w celu wykrywania anomalii i prowadzenia dochodzeń.
Dlaczego: Kompletny, odporny na manipulacje audyt spełnia wymogi zgodności (compliance) i przyspiesza analizę przyczyn źródłowych (RCA).

Powiadomienia i integracja z działem operacyjnym (Ops)

Przekieruj krytyczne zdarzenia do SNS i systemów obsługi dyżurów (on-call), otwieraj zgłoszenia OpsItems w OpsCenter z dołączonymi instrukcjami (runbooks) i dołączaj do alarmów tagi określające właściciela i wagę problemu.
Dlaczego: Jasno zdefiniowana odpowiedzialność i zautomatyzowane instrukcje (runbooks) poprawiają jakość i szybkość reakcji.

Ten projekt został wybrany, aby połączyć metryki o niskim opóźnieniu i bogatych wymiarach (CloudWatch + EMF), głęboką korelację śladów (X-Ray + ServiceLens), przeszukiwanie na dużą skalę (OpenSearch + S3/Athena), naprawę sterowaną zdarzeniami (EventBridge + Lambda/SSM/Step Functions) oraz audytowalny ład korporacyjny (CloudTrail z weryfikacją integralności). Równoważy on koszty i wierność odwzorowania danych poprzez próbkowanie, warstwy retencji i ukierunkowane alarmy, które odzwierciedlają rzeczywisty wpływ na użytkownika.

← Infrastruktura jako kod i zarządzanie konfiguracją · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →