Amazon DVA-C02: Мониторинг, логирование и отладка (CloudWatch, X-Ray, трассировка, оповещения) — Руководство по подготовке

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

Часть AWS Developer Associate DVA-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

CloudWatch Logs, метрики и фильтры метрик логов

CloudWatch Logs — это основной конвейер для телеметрии приложений и платформы; разработчикам следует проектировать логи так, чтобы они были структурированными (JSON), чтобы Metrics и Insights могли надежно их анализировать. Для пользовательских метрик приложений предпочтительнее использовать CloudWatch Embedded Metric Format (EMF) или PutMetricData для мгновенной передачи измерений и для нужд высокого разрешения; EMF встраивает _aws JSON в строки логов и позволяет CloudWatch извлекать множество метрик в одном вызове PutLogEvents для эффективности по стоимости и пропускной способности. Когда вам нужно извлекать метрики из текстовых логов на стороне сервиса, создавайте фильтры метрик (PutMetricFilter) для лог-группы, которые сопоставляют шаблоны фильтров с MetricTransformations; это создает метрики CloudWatch, которые можно отображать на графиках и использовать для оповещений. Распространенные операционные API — это CreateLogGroup, CreateLogStream и PutLogEvents (следите за sequenceToken и ограничениями на размер пакета PutLogEvents), а также AssociateKmsKey для привязки управляемого клиентом ключа KMS к лог-группе для шифрования при хранении. Следите за IAM: PutLogEvents и PutMetricData требуют явных разрешений, а гранты KMS должны позволять сервисному принципалу использовать ключи для шифрования. Используйте политики хранения для контроля затрат и отдавайте предпочтение метрикам высокого разрешения (PutMetricData с StorageResolution=1) только тогда, когда вам нужна субминутная детализация.

Трассировка и X-Ray для распределенных систем

Распределенная трассировка инструментирует потоки запросов между сервисами, чтобы выявить, где возникают задержки и ошибки; AWS X-Ray — это интегрированное решение. Включите активную трассировку (Active tracing) для функций Lambda (Lambda TracingConfig Mode: Active) и активируйте X-Ray для стадий API Gateway, чтобы распространять заголовок трассировки X-Ray. Используйте AWS X-Ray SDK в вашей среде выполнения (aws-xray-sdk-core для Node, aws_xray_sdk для Python, AWSXRayRecorder для Java), чтобы создавать субсегменты, добавлять аннотации (индексируемые, небольшие значения) и метаданные (неиндексируемые, большие объекты). Перехватывайте последующие вызовы SDK, оборачивая клиенты AWS SDK рекордером X-Ray, чтобы SDK автоматически инструментировал запросы к S3, DynamoDB и HTTP-вызовы. Для контейнеризированных рабочих нагрузок запускайте демон X-Ray как sidecar-контейнер или используйте слой с демоном; он принимает UDP-пакеты (порт по умолчанию 2000) и пакетирует их для отправки в сервис X-Ray. Настройте правила сэмплирования (CreateSamplingRule), чтобы избежать шума, но корректируйте правила или используйте переопределение в SDK для критически важных потоков, которые вы всегда хотите трассировать. Помните об ограничениях на размер документов сегментов и никогда не помещайте персональные данные (PII) в аннотации, поскольку они индексируются и доступны для поиска.

Оповещения, уведомления и проектирование системы оповещений

Оповещения должны обнаруживать события, требующие действий, уменьшать шум и интегрироваться с регламентами (runbooks). Используйте CloudWatch Alarms для нативных метрик, пользовательских метрик (из PutMetricData или фильтров метрик) или выражений метрической математики; настраивайте DatapointsToAlarm и EvaluationPeriods, чтобы избежать частого переключения состояний (flapping), и отдавайте предпочтение составным оповещениям (composite alarms) для условий с несколькими сигналами (например, сбой в нижестоящем сервисе + рост числа ошибок), чтобы уменьшить количество оповещений. Действия по оповещению могут публиковать сообщения в топики SNS для рабочих процессов, выполняемых людьми или автоматикой, вызывать Auto Scaling или Systems Manager OpsCenter (создавая OpsItems), или маршрутизироваться через правила EventBridge для сложных сценариев реагирования (playbooks) (source: aws.cloudwatch). Для быстрой связи с дежурным инженером используйте SNS -> HTTP endpoint или интеграцию с PagerDuty; для автоматизированного исправления используйте EventBridge -> Step Functions или Lambda с IAM-ролями с минимальными привилегиями. Рассмотрите возможность использования моделей обнаружения аномалий для определения базовых показателей трафика и устанавливайте пороги для состояния OK с гистерезисом. Распространенные ловушки включают создание слишком большого количества оповещений с измерениями (что ведет к взрывному росту затрат на мониторинг), использование только триггеров, срабатывающих по одной точке данных, и недостаточную защиту топиков уведомлений (политики доступа SNS), что приводит к утечке оповещений к непреднамеренным потребителям.

Паттерны устранения неполадок и лучшие практики SDK/API

Начинайте поиск неисправностей со сравнения ожидаемой и наблюдаемой временной шкалы, а затем сопоставляйте логи, метрики и трассировки. Используйте CloudWatch Logs Insights для специализированных запросов (например,

undefined

) чтобы находить всплески, а затем переключайтесь на трассировки X-Ray для детального изучения задержек. Для API на базе Lambda проверяйте холодные запуски, время подключения ENI в VPC (для функций в VPC), а также настроены ли назначения Lambda (destinations) или очереди DLQ для захвата неудачных асинхронных вызовов. Для захвата неудачных вызовов используйте Lambda Destinations (onFailure в SNS, SQS или EventBridge) или асинхронную DLQ для сохранения полезной нагрузки. Инструментируя код, обрабатывайте троттлинг API, реализуя экспоненциальную задержку с джиттером (exponential backoff with jitter) и отслеживая ошибки 429 с помощью фильтров метрик или счетчиков EMF. Распространенные подводные камни: PutLogEvents требует правильный токен последовательности (sequence token) и предварительного вызова CreateLogStream; PutMetricData может подвергаться троттлингу — пакетируйте и отправляйте агрегированные метрики; X-Ray требует разрешений xray:PutTraceSegments и xray:PutTelemetryRecords (управляемая политика AWSXRayDaemonWriteAccess); семплирование может скрывать проблемы, если не настроить правила для низкочастотных, но критически важных потоков.

Практическая задача: сценарий использования

Сценарий: Acme Retail использует бессерверный сервис оформления заказов на AWS, состоящий из API Gateway -> Lambda -> DynamoDB. Команда использует централизованные CloudWatch Logs и X-Ray, но ей не хватает поминутных метрик пропускной способности устройств и нужны надежные оповещения о всплесках задержки API, которые не создают лишнего шума.

Задача: Собирать поминутный подсчет устройств/сообщений почти в реальном времени, обеспечить сквозную трассировку для медленных запросов и создать оповещение с низким уровнем шума, которое запускает автоматизированную Lambda-функцию для исправления и уведомляет дежурного инженера.

Рекомендуемый подход:

Инструментировать Lambda-функцию оформления заказа для отправки пользовательской метрики высокого разрешения с помощью API PutMetricData с параметрами Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 и StorageResolution=1; пакетировать их в памяти и сбрасывать каждые 30 секунд, чтобы избежать троттлинга API.
Также встраивать EMF JSON в логи Lambda для получения более богатых измерений (dimensions), таких как customerId и region, и полагаться на CloudWatch Logs для извлечения дополнительных метрик через PutLogEvents и фильтры метрик (PutMetricFilter) для подсчета ошибок.
Включить трассировку X-Ray: установить для Lambda TracingConfig Mode значение Active, включить X-Ray на стейдже API Gateway и использовать X-Ray SDK для добавления аннотаций (не содержащих PII) и подсегментов вокруг внешних HTTP-вызовов к сторонним API.
Создать составное оповещение (composite alarm) CloudWatch, которое объединяет метрику высокого 95-го перцентиля задержки (с помощью metric math) со всплеском DeviceReportsPerMinute; установить EvaluationPeriods=3, DatapointsToAlarm=2, в качестве Action указать SNS-топик, который активирует эндпоинт дежурного инженера, а также правило EventBridge, которое вызывает Lambda-функцию для исправления (с ролью с минимальными привилегиями).

Обоснование: Отправка метрик высокого разрешения и EMF обеспечивает как мгновенные поминутные подсчеты, так и более богатые измерения; X-Ray позволяет находить первопричины задержек вплоть до вызовов нижестоящих сервисов; составные оповещения уменьшают шум, требуя совпадения нескольких условий перед срабатыванием, и позволяют автоматизировать действия через EventBridge.

← Безопасность · Все домены · Хранилище →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →