Amazon DVA-C02: Monitorowanie, logowanie i debugowanie (CloudWatch, X‑Ray, Śledzenie, Alarmy) — Przewodnik do nauki

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

CloudWatch Logs, Metrics i filtry metryk logów

CloudWatch Logs to główny potok dla telemetrii aplikacji i platformy; deweloperzy powinni projektować logi tak, aby były ustrukturyzowane (JSON), co umożliwi ich niezawodne parsowanie przez Metrics i Insights. W przypadku niestandardowych metryk aplikacji preferuj format CloudWatch Embedded Metric Format (EMF) lub PutMetricData dla natychmiastowych wymiarów i potrzeb wysokiej rozdzielczości; EMF osadza _aws JSON w liniach logów i pozwala CloudWatch na ekstrakcję wielu metryk w jednym wywołaniu PutLogEvents, co zapewnia efektywność kosztową i przepustowość. Gdy potrzebujesz uzyskać metryki z logów tekstowych po stronie usługi, utwórz filtry metryk (PutMetricFilter) dla grupy logów, które mapują wzorce filtrów na MetricTransformations; generują one metryki CloudWatch, które można przedstawiać na wykresach i alarmować. Typowe operacyjne API to CreateLogGroup, CreateLogStream i PutLogEvents (zwróć uwagę na sequenceToken i limity rozmiaru partii PutLogEvents) oraz AssociateKmsKey do dołączania zarządzanego przez klienta klucza KMS do grupy logów w celu szyfrowania w spoczynku. Uważaj na IAM: PutLogEvents i PutMetricData wymagają jawnych uprawnień, a granty KMS muszą pozwalać jednostce głównej usługi (service principal) na używanie kluczy do szyfrowania. Używaj polityk retencji do kontrolowania kosztów i preferuj metryki o wysokiej rozdzielczości (PutMetricData z StorageResolution=1) tylko wtedy, gdy potrzebujesz widoczności na poziomie subminutowym.

Śledzenie i X-Ray dla systemów rozproszonych

Śledzenie rozproszone (distributed tracing) instrumentuje przepływ żądań między usługami, aby ujawnić, gdzie występują opóźnienia i błędy; AWS X-Ray jest zintegrowaną opcją. Włącz aktywne śledzenie (Active tracing) w funkcjach Lambda (Lambda TracingConfig Mode: Active) i włącz X-Ray dla etapów (stages) API Gateway, aby propagować nagłówek śledzenia X-Ray. Użyj AWS X-Ray SDK w swoim środowisku uruchomieniowym (aws-xray-sdk-core dla Node, aws_xray_sdk dla Python, AWSXRayRecorder dla Java), aby tworzyć subsegmenty, dodawać adnotacje (indeksowane, małe wartości) i metadane (nieindeksowane, większe obiekty). Przechwytuj wywołania SDK do usług podrzędnych, opakowując klientów AWS SDK za pomocą X-Ray recorder, dzięki czemu SDK automatycznie instrumentuje żądania do S3, DynamoDB i wywołania HTTP. W przypadku obciążeń skonteneryzowanych uruchamiaj demona X-Ray jako kontener sidecar lub używaj warstwy z demonem; akceptuje on pakiety UDP (domyślny port 2000) i przesyła je partiami do usługi X-Ray. Skonfiguruj reguły próbkowania (CreateSamplingRule), aby uniknąć szumu, ale dostosuj reguły lub użyj nadpisania w SDK dla krytycznych przepływów, które zawsze chcesz śledzić. Pamiętaj o limitach rozmiaru dokumentu segmentu i nigdy nie umieszczaj danych osobowych (PII) w adnotacjach, ponieważ są one indeksowane i przeszukiwalne.

Alarmy, powiadomienia i projektowanie alertów

Alarmy powinny wykrywać zdarzenia wymagające działania, redukować szum i integrować się z runbookami. Używaj alarmów CloudWatch Alarms na metrykach natywnych, niestandardowych (z PutMetricData lub filtrów metryk) lub wyrażeniach matematycznych na metrykach; dostosuj DatapointsToAlarm i EvaluationPeriods, aby unikać niestabilności (flapping) i preferuj alarmy złożone (composite alarms) dla warunków wielosygnałowych (uszkodzona usługa podrzędna + zwiększona liczba błędów), aby zmniejszyć liczbę alertów. Akcje alarmów mogą publikować do tematów SNS dla przepływów pracy dla ludzi i automatyzacji, wywoływać Auto Scaling lub Systems Manager OpsCenter (tworząc OpsItems) lub kierować przez reguły EventBridge dla złożonych scenariuszy (playbooks) (źródło: aws.cloudwatch). Dla pilnych potrzeb dyżurnych użyj integracji SNS -> punkt końcowy HTTP lub PagerDuty; dla zautomatyzowanej naprawy użyj EventBridge -> Step Functions lub Lambda z IAM o najmniejszych wymaganych uprawnieniach. Rozważ modele wykrywania anomalii do ustalania linii bazowej ruchu i ustawiaj progi OK z histerezą. Typowe pułapki to tworzenie zbyt wielu alarmów z wymiarami (eksplozja kosztów monitoringu), poleganie wyłącznie na wyzwalaczach opartych na pojedynczym punkcie danych oraz niezabezpieczenie tematów powiadomień (polityki dostępu SNS), przez co alerty nie wyciekają do niezamierzonych odbiorców.

Wzorce rozwiązywania problemów i dobre praktyki SDK/API

Rozwiązywanie problemów rozpocznij od zestawienia osi czasu zdarzeń oczekiwanych z zaobserwowanymi, a następnie skoreluj logi, metryki i ślady (traces). Użyj CloudWatch Logs Insights do zapytań ad-hoc (

undefined

), aby znaleźć nagłe wzrosty (spikes), a następnie przejdź do śladów X-Ray w celu analizy szczegółowych opóźnień. W przypadku API opartych na Lambda, sprawdź zimne starty (cold-starts), czasy dołączania VPC ENI (dla funkcji w VPC) oraz czy skonfigurowano miejsca docelowe Lambda (destinations) lub kolejki DLQ do przechwytywania nieudanych wywołań asynchronicznych. Aby przechwytywać nieudane wywołania, użyj Lambda Destinations (onFailure do SNS, SQS lub EventBridge) lub asynchronicznej kolejki DLQ w celu zachowania ładunku (payload). Podczas instrumentacji kodu obsługuj dławienie API (throttling), implementując wykładnicze wycofywanie z fluktuacją (exponential backoff with jitter) i monitorując błędy 429 za pomocą filtrów metryk lub liczników EMF. Częste pułapki: PutLogEvents wymaga poprawnego tokenu sekwencji (sequence token) i wcześniejszego wywołania CreateLogStream; PutMetricData może być dławione — grupuj i emituj zagregowane metryki; X-Ray wymaga uprawnień xray:PutTraceSegments i xray:PutTelemetryRecords (zarządzana polityka AWSXRayDaemonWriteAccess); a próbkowanie (sampling) może ukrywać problemy, chyba że dostosujesz reguły dla rzadkich, ale krytycznych przepływów.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Acme Retail prowadzi bezserwerową usługę płatności na AWS, używając architektury API Gateway -> Lambda -> DynamoDB. Zespół korzysta ze scentralizowanych logów CloudWatch i X-Ray, ale brakuje mu metryk przepustowości urządzeń na minutę i potrzebuje niezawodnych alertów o skokach opóźnień API, które nie generują zbędnego szumu informacyjnego.

Wyzwanie: Przechwytywanie liczby urządzeń/wiadomości na minutę w czasie zbliżonym do rzeczywistego, zapewnienie śledzenia end-to-end dla wolnych żądań oraz stworzenie alarmu o niskim poziomie szumu, który uruchamia zautomatyzowaną funkcję Lambda do naprawy i powiadamia dyżurnego inżyniera (on-call).

Zalecane podejście:

1. Zinstrumentuj funkcję Lambda obsługującą płatności, aby emitowała niestandardową metrykę o wysokiej rozdzielczości za pomocą API PutMetricData z parametrami Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 i StorageResolution=1; grupuj je w pamięci i opróżniaj co 30 sekund, aby uniknąć dławienia API.
2. Dodatkowo, osadzaj format EMF JSON w logach Lambda, aby uzyskać bogatsze wymiary (customerId, region) i polegaj na CloudWatch Logs w celu ekstrakcji dodatkowych metryk za pomocą PutLogEvents i filtrów metryk (PutMetricFilter) do zliczania błędów.
3. Włącz śledzenie X-Ray: ustaw TracingConfig Mode dla Lambda na Active, włącz X-Ray na etapie (stage) API Gateway i użyj X-Ray SDK do dodawania adnotacji (bez danych PII) oraz subsegmentów wokół zewnętrznych wywołań HTTP do API firm trzecich.
4. Stwórz złożony alarm CloudWatch (composite alarm), który łączy metrykę wysokiego opóźnienia 95. percentyla (używając metric math) ze skokiem w DeviceReportsPerMinute; ustaw EvaluationPeriods=3, DatapointsToAlarm=2, a jako Action wskaż temat SNS, który wyzwala endpoint dyżurny (on-call) oraz regułę EventBridge, która wywołuje naprawczą funkcję Lambda (z rolą o najniższych uprawnieniach).

Uzasadnienie: Emitowanie metryk o wysokiej rozdzielczości oraz EMF zapewnia zarówno natychmiastowe zliczanie na minutę, jak i bogatszą wymiarowość; X-Ray pozwala na analizę przyczyn źródłowych opóźnień aż do poziomu wywołań podrzędnych; alarmy złożone redukują szum, wymagając spełnienia skorelowanych warunków przed uruchomieniem alertu, i umożliwiają automatyzację za pomocą EventBridge.

← Bezpieczeństwo · Wszystkie domeny · Pamięć masowa →

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

Przeglądaj Amazon →