Тревога CloudWatch для ConsumedWriteCapacityUnits в DynamoDB

Коротко о метриках DynamoDB

Для мониторинга таблиц Amazon DynamoDB данные метрик автоматически отправляются в CloudWatch. Многие метрики агрегируются с периодом 1 минута; некоторые — с периодом 5 минут. Ниже — перечень ключевых метрик, доступных для таблиц, и краткое пояснение к каждой.

1. ConditionalCheckFailedRequests — число неудачных попыток условных записей (conditional writes).
2. ConsumedReadCapacityUnits — число потреблённых единиц чтения (RCU) за период. Помогает понять, какая часть выделенной пропускной способности используется.
3. ConsumedWriteCapacityUnits — число потреблённых единиц записи (WCU) за период. Центральная для нашей тревоги.
4. ReadThrottleEvents — количество запросов, превысивших provisioned read capacity, и, соответственно, подвергшихся троттлингу.
5. ReturnedBytes — объём байт, возвращённых операциями GetRecords за период.
6. ReturnedItemCount — число элементов, возвращённых операциями Query, Scan или ExecuteStatement за период.
7. ReturnedRecordsCount — число записей потока (stream records), возвращённых GetRecords.
8. SuccessfulRequestLatency — измеряет задержку успешных запросов к DynamoDB или Streams за период.
9. SystemErrors — количество запросов, завершившихся HTTP 500 за период.
10. TimeToLiveDeletedItemCount — число элементов, удалённых TTL за период.
11. ThrottledRequests — число троттлинговых ответов из-за превышения throughput.
12. TransactionConflict — количество отклонённых item-level запросов из-за конфликтов транзакций.
13. UserErrors — количество запросов, завершившихся HTTP 400 за период.
14. WriteThrottleEvents — количество запросов, превысивших provisioned write capacity.

Важно: метрики с granularity 1 минута подходят для быстрого обнаружения всплесков нагрузки. Метрики с 5-минутной агрегацией полезны для долгосрочного анализа.

Предварительные условия

1. Аккаунт AWS.
2. Существующая таблица DynamoDB.
3. SNS topic с подписками (email, SMS, Lambda и/или HTTPS).

Если у вас нет SNS topic, создайте его заранее и подпишитесь на уведомления.

Что сделаем

1. Войдём в AWS Management Console.
2. Через CloudWatch создадим тревогу по метрике ConsumedWriteCapacityUnits для выбранной таблицы.
3. Настроим действие — отправку уведомления в SNS.
4. Добавим тесты и план реагирования на срабатывание.

Вход в AWS

Click here to go to AWS Login Page.

Вы увидите страницу входа. Введите свои учётные данные.

После входа откроется главный экран консоли AWS.

Создание тревоги для существующей таблицы DynamoDB

1. В верхней строке поиска введите “CloudWatch” и откройте сервис.

2. В левой панели выберите “Alarms”.

3. Нажмите “Create alarm”.

4. Нажмите “Select metric” и в поиске введите “dynamodb”. Затем выберите DynamoDB > Table Metrics.

5. В списке метрик найдите ConsumedWriteCapacityUnits для нужной таблицы и нажмите “Select metric”.

6. Установите статистику, тип порога и условие. В примере мы используем Sample Count > 5 в течение 5 минут — т.е. тревога сработает, если за 5 последовательных минут Sample Count превысит 5.

7. Выберите состояние тревоги для срабатывания (например, In alarm) и укажите SNS topic, на который будут отправляться уведомления.

8. Добавьте имя и описание тревоги и нажмите Next.

9. Проверьте конфигурацию и нажмите Create alarm.

10. После создания тревога появится в списке Alarms. Состояние будет отражать текущее состояние по заданному порогу.

11. Когда тревога срабатывает, подписчики SNS получат сообщение (в примере — уведомление в подписке).

Практические рекомендации по порогам и статистикам

• Granularity: используйте 1 минуту для быстрых оповещений о всплесках; 5 минут — для шумоподавления и трендов.
• Statistic: Average даёт среднюю загрузку, Sum — суммарную нагрузку за период, Sample Count полезен для оценки числа событий; выбирайте в зависимости от сценария.
• Threshold type: Static подходит для фиксированных лимитов, Anomaly Detection полезна для динамических, ненормальных пиков.
• Учитывайте автошкалирование таблицы (Auto Scaling). Если включено, пороги нужно привязывать к ожидаемым уровням масштабирования.

Важно: низкий порог по ConsumedWriteCapacityUnits может генерировать ложные срабатывания при коротких всплесках. Применяйте оконные условия (например, >5 минут подряд) или Anomaly Detection.

Когда такой алерт не подойдёт (контраргументы)

• Если ваша таблица использует On-Demand capacity, фиксированные пороги по WCU неинформативны — On-Demand автоматически обслуживает всплески.
• Для проблем с латентностью лучше смотреть SuccessfulRequestLatency или Percentile (p95/p99).
• Для ошибок приложения лучше смотреть SystemErrors и UserErrors.

Альтернативные способы создания тревог

• AWS CLI: cloudwatch put-metric-alarm — удобно для автоматизации.
• Infrastructure as Code: CloudFormation, Terraform или CDK позволяют поддерживать тревоги в коде и версии.
• Использовать Lambda как action вместо SNS для запуска автоматической коррекции (scale-up сценарии, запуск отладочных скриптов).

Мини-методология настройки alarm в продуктиве

1. Определите цель мониторинга (SRE: доступность; Dev: целевые SLA).
2. Выберите метрику и statistic, соответствующие цели.
3. Выставьте порог и период; начните консервативно, затем скорректируйте по наблюдениям.
4. Настройте уведомления и определите ответственных.
5. Протестируйте тревогу и отработайте runbook.
6. Пересматривайте пороги раз в релиз или при изменении архитектуры.

Runbook при срабатывании тревоги

Краткий план действий для инженера, получившего уведомление:

1. Подтвердить срабатывание в CloudWatch: проверить график ConsumedWriteCapacityUnits и метки времени.
2. Сравнить с автошкалированием (если включено): увеличивалось ли provisioned capacity.
3. Проверить логи приложения на резкое увеличение write-load.
4. Проверить связанные метрики: ThrottledRequests, WriteThrottleEvents, SystemErrors.
5. При необходимости временно увеличить provisioned WCU или включить On-Demand, либо ускорить autoscaling policy.
6. Если причиной — тест/деплой, связаться с командой и откатить изменения при необходимости.
7. После решения инцидента записать причину и корректирующие действия в постмортем.

Критерии приёмки

• Тревога срабатывает при заявленном условии (Sample Count > 5 в течение 5 минут).
• Уведомление доставляется в SNS подписки (email/SMS/Lambda).
• Runbook выполним и содержит контактные данные ответственных.

Тестовые сценарии и критерии приёмки

Тест 1: Симулировать нагрузку записей

• Действие: запустить скрипт, генерирующий write-операции в таблицу, пока Sample Count не превысит 5 в каждой из 5 минут.
• Ожидаемый результат: тревога переходит в состояние In alarm и подписчики получают уведомление.

Тест 2: Ложная тревога

• Действие: кратковременный всплеск write-операций на 1 минуту.
• Ожидаемый результат: тревога не срабатывает, если условие требует превышения 5 минут подряд.

Тест 3: Валидация Auto Scaling

• Действие: вызвать увеличение нагрузки и проверить, как autoscaling реагирует на рост WCU и влияет на метрику.
• Ожидаемый результат: при корректной настройке autoscaling WCU повышается, троттлинг уменьшается.

Чек-листы ролей

SRE

• Проверить интеграцию CloudWatch -> SNS -> Pager/Slack.
• Обновить runbook и SLA.
• Настроить автоматическое восстановление (Lambda/Auto Scaling).

DevOps

• Добавить правило в IaC (Terraform/CloudFormation) для тревоги.
• Протестировать deployment pipeline.

Разработчик

• Проверить поведение приложения при возрастании write-load.
• Оптимизировать записи (batching, уменьшение размеров items).

Ментальные модели и эвристики

• WCU отражает нагрузку записи пропорционально размеру и типу операции (обычная запись ≈ 1 WCU для 1KB и т.д.).
• Если ConsumedWriteCapacityUnits стабильно близок к provisioned — ресурс узкий; подумайте об autoscaling или On-Demand.
• ThrottledRequests и WriteThrottleEvents — прямые указатели на нехватку capacity.

Полезные шаблоны имён тревог

• ddb-{table-name}-consumed-wcu-high
• prod-{table}-wcu-alert
• ddb-{table}-wcu-anomaly

Mermaid: быстрая логика реагирования

flowchart TD
  A[Тревога CloudWatch] --> B{In alarm?}
  B -- Да --> C[Отправить SNS уведомление]
  C --> D{Auto Scaling включён?}
  D -- Да --> E[Проверить политику Auto Scaling]
  D -- Нет --> F[Увеличить provisioned WCU или переключить на On-Demand]
  B -- Нет --> G[Мониторинг продолжается]

Частые ошибки и как их избегать

• Установка слишком низкого порога без оконной агрегции — приводит к шуму и «alarm fatigue».
• Игнорирование Auto Scaling — ручное увеличение capacity может быть ненужным.
• Отправка уведомлений только на email — медленно для on-call; используйте интеграции с PagerDuty, Slack или мобильными пушами.

Заключение

В статье мы создали тревогу CloudWatch для метрики ConsumedWriteCapacityUnits таблицы DynamoDB и настроили уведомления в SNS. Мы рассмотрели лучшие практики по выбору порогов, сценарии тестирования, runbook и шаблоны имён тревог. Применяйте предложенные чек-листы и тесты, чтобы уменьшить шум и повысить оперативность реагирования.

Важно: периодически пересматривайте пороги и runbook при изменениях трафика или архитектуры.