Освоение AWS CloudWatch для проактивного мониторинга производительности и оптимизации

AWS CloudWatch — это сервис, с помощью которого многие инциденты в AWS начинают обретать смысл. Медленный процесс оформления заказа, функция Lambda, которая внезапно начинает троттлиться, база данных RDS, исчерпавшая соединения, или очередь SQS, которая постоянно растет, — все это оставляет следы в метриках и логах. Сложность не в том, чтобы включить CloudWatch. Сложность в том, чтобы выбрать сигналы, которые помогут вам действовать до того, как пользователи сообщат, что что-то сломалось.

Хороший мониторинг CloudWatch связывает симптомы платформы с поведением приложения. ЦП, память и ввод-вывод важны, но также важны сбои оформления заказа, возраст очереди, задержка платежей и количество успешных заданий в минуту.

Основные компоненты AWS CloudWatch

CloudWatch работает на основе системы сбора данных временных рядов, известных как Метрики, которые затем оцениваются на соответствие пороговым значениям с помощью Оповещений. Эти данные визуализируются через Панели мониторинга и дополняются Логами и Событиями.

1. Метрики: Основа мониторинга

Метрики — это числовые измерения, отслеживаемые с течением времени. Каждый сервис AWS автоматически публикует стандартные метрики (например, загрузка ЦП EC2, количество запросов S3). Однако для истинного мониторинга производительности требуется выйти за рамки стандартных настроек.

Стандартные и пользовательские метрики

• Стандартные метрики: Автоматически собираются сервисами AWS. Разрешение варьируется в зависимости от сервиса и конфигурации; многие распространенные сервисы публикуют метрики с интервалом в 1 минуту, в то время как некоторые базовые или старые конфигурации используют 5-минутные периоды.
• Пользовательские метрики: Данные, которые вы публикуете самостоятельно, часто используются для измерения специфических для приложения показателей производительности.

Публикация пользовательских метрик с помощью AWS CLI:

Вы можете публиковать пользовательские метрики с помощью команды put-metric-data. Это важно для мониторинга времени отклика приложения, глубины очереди или критически важных для бизнеса операционных статусов.

aws cloudwatch put-metric-data \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --value 150 \
    --unit "Milliseconds" \
    --region us-east-1

Гранулярность метрик

Пользовательские метрики CloudWatch могут быть стандартного или высокого разрешения. Пользовательские метрики высокого разрешения могут храниться с разрешением в 1 секунду и вызывать оповещения за более короткие периоды, что полезно для быстро меняющихся систем. Используйте это выборочно, потому что больший объем и большее количество оповещений могут увеличить стоимость.

2. Оповещения: Запуск действий на основе пороговых значений

Оповещения переходят между тремя состояниями: OK, INSUFFICIENT_DATA и ALARM. Оповещение запускает действие, когда указанное пороговое значение превышено в течение определенного количества периодов.

Настройка оповещений о производительности

Эффективные оповещения о производительности фокусируются на опережающих индикаторах, а не только на реактивных сбоях. Например, мониторинг загрузки ЦП EC2 — это хорошо, но мониторинг метрики BurstBalance для экземпляров семейства T может предсказать будущее троттлинг до того, как загрузка достигнет 100%.

Пример: Настройка оповещения о высокой задержке

Если ваша пользовательская метрика CheckoutLatency в среднем превышает 500 мс в течение трех последовательных 1-минутных периодов, запустите оповещение и уведомите тему SNS.

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCheckoutLatencyAlarm" \
    --alarm-description "Alert when P95 latency exceeds 500ms" \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --statistic Average \
    --period 60 \
    --threshold 500 \
    --evaluation-periods 3 \
    --datapoints-to-alarm 3 \
    --comparison-operator GreaterThanThreshold \
    --actions-enabled \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Лучшая практика: Использование процентилей (p99, p95) При мониторинге задержки избегайте использования только Average. Небольшая, но проблемная группа медленных запросов может исчезнуть внутри здорового на вид среднего значения. Используйте статистику P99 или P95, когда важна хвостовая задержка.

3. Панели мониторинга: Визуализация состояния системы

Панели мониторинга объединяют соответствующие метрики в единое окно. Эффективные панели мониторинга адаптированы для аудитории (например, эксплуатация, разработка, руководство).

Создание панели мониторинга оптимизации производительности

Хорошо структурированная панель мониторинга для оптимизации производительности должна группировать связанные метрики.

• Панель состояния системы: Загрузка ЦП, входящий/исходящий трафик, операции чтения/записи диска (для EC2/EBS).
• Панель производительности приложения: Пользовательские метрики задержки (P99), уровень ошибок (количество HTTP 5xx), пропускная способность запросов.
• Панель стоимости/эффективности: Количество запущенных экземпляров, использование зарезервированных экземпляров, использование томов EBS (для выявления недоиспользуемого хранилища).

Панели мониторинга CloudWatch поддерживают сложные виджеты, включая текстовые аннотации, выражения метрической математики (например, расчет коэффициентов эффективности) и даже встраивание результатов запросов CloudWatch Logs Insights.

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

Данные мониторинга ценны только тогда, когда они приводят к действиям. Оповещения CloudWatch являются основным механизмом для запуска автоматизированных рабочих процессов оптимизации.

Интеграция оповещений с Auto Scaling

Одним из самых мощных методов оптимизации является использование оповещений CloudWatch для управления группами автоматического масштабирования AWS (ASG). Это гарантирует, что мощность точно соответствует спросу, предотвращая избыточное выделение ресурсов (экономия средств) и недостаточное выделение (ухудшение производительности).

Пример: Масштабирование на основе глубины очереди

Вместо того чтобы полагаться только на ЦП, масштабируйтесь на основе отставания, ожидающего обработки. Для очереди SQS вы создадите оповещение на основе метрики ApproximateNumberOfMessagesVisible. Когда оповещение переходит в состояние ALARM, оно запускает действие Auto Scaling для добавления экземпляра EC2 в ASG.

Совет по настройке: Убедитесь, что ваши политики масштабирования используют Target Tracking Scaling, настроенный на поддержание среднего показателя использования (например, поддержание средней загрузки ЦП на уровне 60%). Это позволяет AWS динамически управлять масштабированием, что обычно предпочтительнее статического ступенчатого масштабирования.

Использование логов для глубокого анализа

Когда возникают проблемы с производительностью, CloudWatch Logs необходим для анализа первопричин.

• Централизованное ведение логов: Настройте все приложения и сервисы (VPC Flow Logs, логи Lambda, логи контейнеров ECS/EKS) на потоковую передачу в CloudWatch Logs.
• Log Insights: Используйте мощный язык запросов в Log Insights для быстрого поиска по огромным объемам логов. Например, чтобы найти все запросы, которые выполнялись дольше 2 секунд:

fields @timestamp, @message
| filter @message like /duration: \d{4,}/ 
| parse @message "*duration: *ms*" as duration
| filter as_number(duration) > 2000
| sort @timestamp desc
| limit 50

Лучшие практики мониторинга CloudWatch

Чтобы максимизировать ценность, получаемую от CloudWatch, и оптимизировать производительность:

1. Мониторинг лимитов сервисов: Установите оповещения на ваши квоты сервисов AWS (например, максимальное количество одновременных выполнений Lambda, максимальное количество операций ввода-вывода EBS, доступных вашей учетной записи). Достижение квоты полностью останавливает производительность, часто без четкой ошибки приложения.
2. Установите базовую производительность: Перед оптимизацией отслеживайте вашу систему в часы пик и вне пика, чтобы определить, что такое норма. Это предотвращает установку оповещений на основе нерелевантного шума.
3. Используйте метрическую математику для соотношений: Рассчитывайте коэффициенты эффективности непосредственно в CloudWatch. Например, (Всего ошибок / Всего запросов) * 100, чтобы получить прямой процент частоты отказов, вместо того чтобы жонглировать несколькими отдельными метриками.
4. Управление затратами: Пользовательские метрики высокого разрешения стоят дороже. Будьте разумны. Используйте разрешение в 1 минуту только для критических, быстро меняющихся систем (например, балансировщиков нагрузки). Разрешения по умолчанию в 5 минут достаточно для большинства внутренних сервисов.
5. Стратегия тегирования: Убедитесь, что все отслеживаемые ресурсы (EC2, RDS, Lambda) последовательно тегированы. Это позволяет создавать отфильтрованные панели мониторинга и оповещения, специфичные для сред (например, Env: Prod, App: CheckoutService).

Сделайте панель мониторинга соответствующей инциденту

Панель мониторинга CloudWatch должна помогать кому-то принимать решение под давлением. Если панель мониторинга только доказывает, что у системы много метрик, она не поможет во время сбоя.

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

• Количество запросов и количество ошибок от балансировщика нагрузки или API Gateway.
• Задержка P95 или P99 для той же точки входа.
• Метрики успеха и неудачи на уровне приложения.
• ЦП, память и количество задач для ECS, EKS, Lambda или EC2.
• Метрики RDS, DynamoDB, Redis, SQS или внешних зависимостей, которые обычно объясняют медленные запросы.

Конкретные сервисы меняются, но форма остается той же. Если задержка оформления заказа возрастает, вы хотите видеть, увеличился ли трафик, выросли ли ошибки, увеличилась ли задержка базы данных или отстали ли рабочие процессы. Поместите эти подсказки в одно место.

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

Используйте процентили осторожно

Процентили полезны для задержки, потому что средние значения скрывают болезненный пользовательский опыт. Если большинство запросов завершаются за 100 мс, но меньшая группа занимает 8 секунд, среднее значение может все еще выглядеть приемлемым. График процентилей делает длинный хвост видимым.

Тем не менее, процентили — это не магия. Им требуется достаточный трафик, чтобы быть значимыми, и они могут выглядеть зашумленными на сервисах с низким объемом. Для небольшого внутреннего задания, которое выполняется несколько раз в час, максимальная продолжительность или явная метрика сбоя могут быть более полезными, чем P99. Для публичного API со стабильным трафиком P95 и P99 часто стоит отслеживать.

Когда вы создаете оповещение, убедитесь, что команда CLI использует ту статистику, которую вы на самом деле намереваетесь. Для оповещения на основе процентиля используйте --extended-statistic p95 или p99, а не --statistic Average:

aws cloudwatch put-metric-alarm \
  --alarm-name "HighCheckoutP95Latency" \
  --metric-name "CheckoutLatency" \
  --namespace "MyApp/ECommerce" \
  --extended-statistic p95 \
  --period 60 \
  --threshold 500 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Настройка datapoints-to-alarm имеет значение. Требование трех из пяти периодов может выявить устойчивую проблему без вызова страницы из-за одной шумной минуты. Для критических систем настройте это на основе реального исторического трафика, а не догадок.

Размещайте метрики приложения рядом с метриками AWS

Метрики сервисов AWS говорят вам, что видит платформа. Метрики вашего приложения говорят вам, что пытается сделать пользователь. Вам нужны и те, и другие.

Например, сервис ECS может показывать нормальную загрузку ЦП и памяти, в то время как оформление заказа сломано, потому что платежный провайдер превышает время ожидания. CloudWatch не узнает об этом, если ваше приложение не опубликует метрику, такую как PaymentAuthorizationFailure, CheckoutCompleted или PaymentProviderLatency.

Хорошие пользовательские метрики обычно привязаны к бизнес-действиям:

• LoginSucceeded и LoginFailed
• OrderCreated
• PaymentAuthorizationLatency
• QueueJobProcessed
• ImportRowsFailed

Делайте измерения полезными, но не взрывоопасными. Service, Environment и Region обычно подходят. Измерение для каждого идентификатора пользователя, идентификатора запроса или пути URL может создать высокую стоимость кардинальности и затруднить использование данных. Для детального исследования каждого запроса лучше подходят логи и трассировки.

CloudWatch Embedded Metric Format удобен, когда вы уже пишете структурированные JSON-логи. Он позволяет отправлять логи и метрики из одного события, что упрощает инструментирование приложения. Компромисс — стоимость и объем: структурированные логи мощны, но шумные логи быстро становятся дорогими.

Стройте оповещения вокруг симптомов и причин

Одна распространенная ошибка мониторинга — оповещение только о причинах: высокий ЦП, высокая память, высокая очередь диска. Они полезны, но не всегда означают, что пользователи затронуты. Другая ошибка — оповещение только о симптомах: высокий уровень ошибок, высокая задержка, сбои заказов. Они говорят вам, что пользователи затронуты, но не объясняют почему.

Практичная настройка использует и то, и другое:

• Оповещения о симптомах отправляют страницу владельцу сервиса: высокий уровень ошибок, высокая задержка, отсутствие успешных заказов, рост возраста очереди.
• Оповещения о причинах поддерживают диагностику: ЦП базы данных, троттлинг запросов DynamoDB, параллелизм Lambda, исчерпанный баланс всплесков, низкое дисковое пространство.
• Оповещения о емкости предупреждают заранее: Auto Scaling близок к максимуму, приближается квота сервиса, отставание в очереди растет быстрее, чем рабочие процессы могут его обработать.

Если каждое оповещение отправляет страницу в один и тот же канал с одинаковой срочностью, люди перестают доверять каналу. Сделайте предупреждающие оповещения видимыми, не будя никого, и оставьте страницы для воздействия на пользователей или почти гарантированного воздействия на пользователей.

Используйте Log Insights для вопросов, а не только для поиска

CloudWatch Logs Insights наиболее полезен, когда команда сохраняет запросы для вопросов, которые они задают повторно. Примеры:

fields @timestamp, status, path, durationMs
| filter status >= 500
| stats count() as errors by path
| sort errors desc
| limit 20

fields @timestamp, requestId, customerId, durationMs
| filter durationMs > 2000
| sort durationMs desc
| limit 50

fields @timestamp, @message
| filter @message like /ThrottlingException|Rate exceeded/
| sort @timestamp desc
| limit 100

Эти запросы не заменяют трассировку, но они достаточно быстры для первого ответа. Сохраните их в runbooks или текстовых виджетах панели мониторинга, чтобы следующему человеку не пришлось вспоминать синтаксис, пока система медленная.

Пересматривайте стоимость, пока улучшаете видимость

CloudWatch может стать дорогим, когда команды включают пользовательские метрики высокого разрешения, хранят каждый лог вечно или создают слишком много уникальных измерений метрик. Мониторинг производительности не должен создавать неожиданный счет.

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

Для метрик начинайте с разрешения, которое соответствует действиям, которые вы можете предпринять. Если сервису требуется несколько минут для безопасного масштабирования, одномиллисекундные метрики могут не улучшить реакцию. Если всплеск задержки должен быть обнаружен немедленно, метрики высокого разрешения могут стоить того для этого узкого сигнала.

Полезная первая настройка CloudWatch

Для нового производственного сервиса хороший первый проход включает:

1. Панель мониторинга с трафиком, задержкой, ошибками, насыщением и состоянием зависимостей.
2. Оповещения о высоком уровне ошибок, высокой задержке, отсутствии успешного трафика, когда трафик ожидается, возрасте очереди и низком дисковом пространстве, где это применимо.
3. Метрики приложения для основных действий пользователя.
4. Структурированные логи с идентификаторами запросов и достаточным количеством полей для фильтрации по маршруту, статусу, продолжительности и зависимости.
5. Сохраненные запросы Log Insights для медленных запросов, ошибок 5xx, троттлинга и неудачных фоновых заданий.
6. Ежемесячный обзор шумных оповещений, отсутствующих оповещений и стоимости CloudWatch.

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