Amazon DOP-C02: Мониторинг, логирование и наблюдаемость — Руководство по подготовке

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

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

Обзор

Мониторинг, ведение журналов и наблюдаемость в AWS требуют объединения метрик, журналов, трассировок, событий и телеметрии о состоянии в полезные сигналы, на которые можно реагировать. Эффективные архитектуры используют Amazon CloudWatch для метрик, сигналов тревоги и панелей управления; CloudWatch Logs и Logs Insights для приёма и анализа журналов; AWS X-Ray для распределённой трассировки; AWS CloudTrail для аудита и обеспечения целостности; Amazon EventBridge для обнаружения и автоматизации на основе событий; AWS Health для событий сервисов, специфичных для аккаунта; и централизованные конвейеры (Kinesis Data Firehose и OpenSearch) для поиска и корреляции в больших масштабах. Приведённые ниже шаблоны подчёркивают важность снижения шума, точной маршрутизации сигналов, автоматизации и операций в нескольких аккаунтах и регионах.

Метрики, сигналы тревоги, панели управления и составные сигналы тревоги CloudWatch

Метрики CloudWatch являются основой для SLO, масштабирования и оповещений. Публикуйте пользовательские метрики с гранулярными измерениями для изоляции сигналов (например, apiOperation, appVersion, statusCode). Используйте формат CloudWatch Embedded Metric Format (EMF) со структурированными журналами для эффективной отправки измерений с высокой кардинальностью из Lambda, контейнеров и EC2, избегая накладных расходов API PutMetricData.

Настраивайте сигналы тревоги с надёжной оценкой:

• Выбирайте периоды, соответствующие гранулярности данных и окнам SLO.
• Устанавливайте datapointsToAlarm (m из n) для устойчивости к временному шуму.
• Используйте TreatMissingData, чтобы избежать ложноположительных срабатываний во время развёртывания или пауз.
• Применяйте диапазоны обнаружения аномалий, когда базовые показатели меняются в зависимости от сезонности, и метрическую математику для производных показателей (задержка p95, процент ошибок, коэффициенты насыщения).
• Привязывайте действия к сигналам тревоги: отправлять уведомления через SNS, создавать OpsItems в OpsCenter, выполнять SSM Automation или восстанавливать экземпляры EC2. Политики масштабирования могут ссылаться на состояния сигналов тревоги для выполнения действий, но составные сигналы тревоги не могут напрямую запускать масштабирование.

Составные сигналы тревоги снижают усталость от оповещений, объединяя несколько базовых сигналов с помощью логики AND/OR. Например, отправлять оповещение только тогда, когда задержка p95 высока, И частота ошибок 5xx превышает порог, И сохраняется насыщение ЦП, тем самым соответствуя влиянию на пользователя. Составные сигналы тревоги принимают обновления состояния от дочерних сигналов тревоги из разных регионов/аккаунтов через меж-аккаунтную наблюдаемость или потоки метрик в центральный аккаунт.

Панели управления (дашборды) визуализируют ключевые показатели по всем сервисам. Используйте виджеты для метрик, результатов запросов Logs Insights и статусов сигналов тревоги. Стандартизируйте соглашения для панелей управления (именование, временные диапазоны, наложение SLO) и используйте межрегиональные/меж-аккаунтные представления с помощью CloudWatch Observability Access Manager (OAM). Для специальной корреляции закрепляйте виджеты Logs Insights и X-Ray ServiceLens рядом с виджетами карты сервисов и показателями ошибок Kinesis Firehose.

CloudWatch Logs: группы журналов, фильтры метрик, фильтры подписки и Logs Insights

Структурируйте группы журналов по приложениям/компонентам и этапам жизненного цикла. Устанавливайте явные политики хранения (не полагайтесь на «Никогда не истекает») и включайте шифрование KMS, где это необходимо. Используйте политики ресурсов и гранулярные IAM-разрешения для контроля производителей и подписчиков. Для высокопроизводительного приёма данных обеспечьте достаточный параллелизм потоков журналов и пакетирование.

Фильтры метрик преобразуют шаблоны журналов в метрики. Определите шаблон фильтра с извлечёнными токенами (в формате JSON или с разделителями-пробелами) и сопоставьте токены с измерениями метрик. Это поддерживает такие сценарии использования, как метрики для каждого API, каждой версии, каждого кода ответа, публикуемые непосредственно из журналов без изменения производителей. Убедитесь, что единицы измерения и значения по умолчанию верны; предпочитайте значение 1 на событие и вычисляйте частоту с помощью метрической математики. Используйте эти метрики для оповещений SLO и панелей управления.

Фильтры подписки передают журналы в потоковом режиме почти в реальном времени в:

• Kinesis Data Firehose для преобразования и доставки в S3/OpenSearch.
• Kinesis Data Streams для пользовательских потребителей.
• Lambda для пользовательской маршрутизации, сокрытия персональных данных (PII) или уведомлений на основе событий. Используйте назначение CloudWatch Logs с IAM-ролью для меж-аккаунтных подписок. Планируйте повторные попытки и противодавление; Lambda и Firehose предоставляют встроенные повторные попытки и очереди недоставленных сообщений (DLQ)/бакеты S3 для ошибок соответственно.

CloudWatch Logs Insights предоставляет интерактивные бессерверные запросы к журналам. Основные операторы включают fields, filter, parse, stats, sort, limit, dedup и bin для группировки по времени. Разбирайте поля JSON или используйте разбор в стиле grok для текстовых журналов. Примеры:

• filter status >= 500 | stats count() by apiOperation, appVersion
• parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service Сохраняйте часто используемые запросы с помощью QueryDefinition для повторного использования командой и встраивайте их в панели управления как виджеты запросов. Для автоматизации запланируйте запуск Lambda через EventBridge для выполнения StartQuery/GetQueryResults и публикации сводок в SNS или OpsCenter. Ограничивайте область запроса конкретными группами журналов и временными окнами, чтобы контролировать затраты.

AWS X-Ray: трассировка, правила выборки, карты сервисов и аннотации

X-Ray собирает распределенные трассировки между сервисами для выявления источников задержек и границ сбоев. Инструментируйте сервисы с помощью AWS Distro for OpenTelemetry (ADOT) или X-Ray SDK, распространяйте заголовок трассировки (например, X-Amzn-Trace-Id) и запускайте демон/агент X-Ray там, где это необходимо (ECS/EKS/EC2). Многие управляемые сервисы имеют встроенную интеграцию (API Gateway, ALB через проксирование трассировок в логах доступа, Lambda с активной трассировкой, Step Functions через подсегменты).

Правила выборки (sampling rules) контролируют объем данных и точность сигнала. Используйте централизованный набор правил выборки, включающий:

• Фиксированный резервуар в секунду для базовых трассировок каждого сервиса.
• Процентная выборка на основе частоты для масштабирования в зависимости от пропускной способности.
• Приоритет правил и сопоставление по сервису/URL для критически важных путей и сценариев с ошибками. Увеличивайте выборку во время инцидентов и для канареечного трафика, чтобы обеспечить наблюдаемость при управлении затратами.

Карты сервисов (service maps) визуализируют граф вызовов, показывая связи с указанием задержек, частоты ошибок и индикаторов троттлинга. Углубляйтесь в трассировки для изучения сегментов и подсегментов для анализа нижестоящих зависимостей. Используйте аннотации (индексируемые пары “ключ-значение”) для фильтрации по данным с высокой кардинальностью, таким как customerTier, apiOperation, appVersion или идентификаторы запросов AWS. Используйте метаданные для подробного, неиндексируемого контекста, чтобы избежать разрастания индекса. Объединяйте группы трассировок X-Ray с CloudWatch ServiceLens для корреляции логов, метрик и трассировок в едином представлении. Создавайте выражения фильтрации (например, annotation.appVersion = "2.3.1" and fault = true), чтобы изолировать регрессии и экспортировать ID трассировок для целевого поиска в логах.

Управление и события: CloudTrail, EventBridge и AWS Health

CloudTrail записывает активность API для управления и криминалистического анализа. Включите организационный trail для всех аккаунтов и всех регионов с доставкой в централизованный бакет S3 с шифрованием SSE-KMS, включите проверку целостности файлов логов и интегрируйте с CloudWatch Logs для обнаружения событий почти в реальном времени. Различайте классы событий:

• События управления (Management events): уровень управления (control plane), например, CreateUser, RunInstances. Настройте для включения событий только для чтения и только для записи по мере необходимости.
• События данных (Data events): высоконагруженные операции на уровне данных (data plane), такие как доступ к объектам S3, вызовы Lambda Invoke, API для элементов DynamoDB, вызовы API-сервера EKS. Ограничивайте область действия событий данных выборочно (по бакету/функции/таблице) для контроля затрат. Используйте CloudTrail Insights для обнаружения аномальных всплесков вызовов API и передавайте события CloudTrail в EventBridge для автоматического исправления. Проверяйте целостность логов во время аудитов с помощью digest-файлов и команды AWS CLI cloudtrail validate-logs.

EventBridge предоставляет фабрику событий для обнаружения и автоматизации. Используйте шину событий по умолчанию для событий сервисов AWS и создавайте пользовательские шины для событий домена приложения. Определяйте шаблоны событий (event patterns), соответствующие полям source, detail-type, detail, префиксам, числовым диапазонам и условию “anything-but” (все, кроме). Применяйте преобразователи ввода (input transformers) для изменения структуры событий, прикрепляйте политики на основе ресурсов для публикации между аккаунтами и настраивайте повторные попытки/очередь недоставленных сообщений (DLQ) для получателей. Типичные получатели включают Lambda (исправление), Step Functions (оркестрация), SQS (разделение компонентов), Systems Manager Automation (операционные действия), CodePipeline (триггеры CI) и SNS (уведомления). Архивируйте и воспроизводите события для восстановления после сбоев потребителей и используйте реестр схем для генерации строго типизированных моделей событий.

AWS Health предоставляет информацию о событиях сервисов, запланированных изменениях и операционных проблемах, специфичных для вашего аккаунта. Интегрируйте через EventBridge с source aws.health и detail-type AWS Health Event, чтобы направлять события в каналы для инцидентов, открывать OpsItems в OpsCenter или запускать безопасное завершение работы или масштабирование на время окон обслуживания. Используйте Organizational View с делегированным аккаунтом администратора для агрегации событий Health по всем аккаунтам и рассмотрите возможность использования AWS Health API или решения AWS Health Aware для отправки отобранных уведомлений в системы дежурных инженеров.

Централизованный сбор логов с помощью Kinesis Data Firehose и OpenSearch

Стратегия сбора логов в среде с несколькими аккаунтами и регионами (multi-account, multi-Region) стандартизирует их приём и поиск. В каждом аккаунте-источнике (producer account) настройте фильтры подписки (subscription filters) CloudWatch Logs на межсетевой приемник логов (cross-account Logs destination), который использует централизованный поток Kinesis Data Firehose. Включите следующие функции Firehose:

• Преобразование данных с помощью Lambda для нормализации (в формат JSON), удаления персональных данных (PII redaction) и обогащения метаданными об аккаунте AWS, регионе, VPC и сервисе.
• Сжатие (GZIP) и динамическое секционирование (dynamic partitioning) при доставке в S3 для оптимизации производительности запросов в Athena.
• Шифрование с помощью KMS и доставка через VPC для использования приватных эндпоинтов. Доставляйте данные в Amazon OpenSearch Service для поиска с низкой задержкой и визуализации в Kibana/OpenSearch Dashboards. Используйте шаблоны индексов (index templates), политики ILM/ISM для ротации (rollover) и хранения (retention), а также гранулярные политики доступа, сопоставляющие пользователей с шаблонами индексов (например, по аккаунту/команде/сервису). Настройте вывод ошибок в S3 для документов, которые не удалось доставить, и отслеживайте метрики доставки Firehose и приёма данных в OpenSearch (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests). При очень больших объёмах данных рассмотрите возможность сначала сохранять все логи в S3 через Firehose, а в OpenSearch передавать только их часть. Для редких и сложных расследований (long-tail investigations) используйте запросы Athena к S3 по требованию, чтобы контролировать затраты.

Совместите этот конвейер с фильтрами метрик (metric filters) CloudWatch для быстрых и недорогих счётчиков и с Logs Insights для глубокого анализа логов по запросу (ad hoc). Используйте правила EventBridge, срабатывающие на аномалии в Firehose/OpenSearch или на сигналы тревоги CloudWatch, чтобы запускать процессы исправления (remediations) или создавать инциденты.

Практический сценарий проблемы

Airbnb сталкивается с периодическими всплесками ошибок и задержек API в микросервисах, развёрнутых на EKS и Lambda, при этом используется несколько версий мобильного приложения. Операционной команде требуется обнаружение проблем почти в реальном времени с разбивкой по операции API, коду ответа и версии приложения; быстрый анализ первопричин (root cause analysis) по трассировкам и логам; автоматическое исправление известных шаблонов сбоев; и аудиторские журналы, соответствующие требованиям управления (governance).

1. Стандартизируйте структурированное логирование

• Внедрите в сервисах (EKS, Lambda) логи в формате JSON, структурированные по EMF, включая поля apiOperation, statusCode, appVersion, tenantId и latencyMs.
• Зачем: EMF позволяет напрямую извлекать метрики в CloudWatch с низкими накладными расходами и измерениями высокой кардинальности (high-cardinality dimensions) для точных сигналов тревоги.

2. Создайте фильтры метрик в CloudWatch Logs

• Для каждой группы логов сервиса определите фильтры метрик, которые увеличивают счётчики с разбивкой по apiOperation, statusCode и appVersion.
• Зачем: Это создаёт метрики для каждого измерения без дополнительного кода, позволяя строить дашборды и настраивать действенные сигналы тревоги для каждого API и версии клиента.

3. Постройте многоуровневые и составной сигналы тревоги в CloudWatch

• Настройте сигналы тревоги на p95 задержки, частоту 5xx ошибок и насыщение (CPU, память, параллелизм/троттлинг). Создайте составной сигнал тревоги (composite alarm): LatencyHigh AND ErrorsHigh в течение 2 из 3 последовательных периодов.
• Зачем: Это уменьшает количество ложных срабатываний и позволяет сосредоточиться на инцидентах, влияющих на пользователей.

4. Разверните трассировку X-Ray с целевой выборкой

• Используйте коллекторы ADOT на EKS и активную трассировку для Lambda. Определите правила выборки (sampling rules) для захвата всех трассировок с ошибками и репрезентативной выборки успешных вызовов, увеличив частоту выборки для новых версий приложения.
• Зачем: Это гарантирует видимость сбоев и достаточное покрытие для выявления узких мест производительности, контролируя при этом затраты.

5. Коррелируйте данные с помощью ServiceLens и Logs Insights

• Создайте дашборды, объединяющие виджеты метрик, карту сервисов (service map) X-Ray и запросы Logs Insights (например,

undefined

).

• Зачем: Единая панель для корреляции данных ускоряет диагностику, позволяя определить, в какой операции и версии клиента произошла регрессия.

6. Централизуйте логи через Firehose в OpenSearch и S3

• Настройте фильтры подписки на центральный Firehose с Lambda-преобразованием для нормализации, удаления PII и обогащения данными об аккаунте/регионе. Доставляйте данные в OpenSearch для «горячего» поиска за 7 дней и в S3 для долгосрочного хранения и запросов через Athena.
• Зачем: Быстрый межкомандный поиск по актуальным проблемам с недорогим анализом исторических данных.

7. Автоматизируйте обнаружение и исправление с помощью EventBridge

• Создайте правила EventBridge для изменений состояния сигналов тревоги CloudWatch и для выбранных событий записи API в CloudTrail (например, изменение групп безопасности). Цели (Targets): Lambda для безопасных откатов (например, отключение feature flags) и Step Functions для многошаговых исправлений.
• Зачем: Циклы управления, основанные на событиях (event-driven), сокращают среднее время восстановления (MTTR) и обеспечивают соблюдение защитных барьеров (guardrails).

8. Интегрируйте AWS Health и обработку технического обслуживания

• Добавьте правила EventBridge для событий aws.health, затрагивающих EC2, EKS или сеть. В качестве цели используйте SSM Automation для изоляции/осушения узлов (cordon/drain) или переключения трафика.
• Зачем: Проактивное смягчение последствий плановых или операционных проблем сокращает время простоя.

9. Усильте управление с помощью организационного трейла CloudTrail и проверки целостности

• Включите организационный, мультирегиональный трейл (trail) с событиями данных (data events) для S3 и Lambda, шифрованием SSE-KMS и проверкой целостности файлов логов. Передавайте данные в CloudWatch Logs и OpenSearch для выявления аномалий и расследований.
• Зачем: Полный, защищённый от подделки аудит соответствует требованиям комплаенса и ускоряет анализ первопричин (RCA).

10. Уведомления и интеграция с Ops

• Направляйте критические события в SNS и системы дежурств, создавайте OpsItems в OpsCenter с прикреплёнными инструкциями (runbooks) и добавляйте к сигналам тревоги теги для определения ответственных и степени серьёзности.
• Зачем: Чёткое распределение ответственности и автоматизированные инструкции улучшают качество и скорость реагирования.

Эта архитектура была выбрана, чтобы объединить метрики с низкой задержкой и богатыми измерениями (CloudWatch + EMF), глубокую корреляцию трассировок (X-Ray + ServiceLens), масштабируемый поиск (OpenSearch + S3/Athena), исправление на основе событий (EventBridge + Lambda/SSM/Step Functions) и аудируемое управление (CloudTrail с проверкой целостности). Она балансирует стоимость и точность данных за счёт выборки, уровней хранения и целевых сигналов тревоги, которые отражают реальное влияние на пользователей.

← Инфраструктура как код и управление конфигурациями · Все домены · Безопасность →

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

Просмотреть Amazon →