CloudWatch: метрики, логи, алармы и счёт

Метрики: namespace, dimensions и разрешение, за которое платишь

Прежде чем публиковать первую кастомную метрику, спроси себя: сколько это будет стоить при 10-кратном трафике и по правильному ли числу я алармирую? Ответы лежат в трёх решениях — namespace/dimensions, разрешение и то, какую статистику ты читаешь.

Метрика CloudWatch — это упорядоченный по времени набор точек данных, одна переменная во времени, например CPU одного EC2-инстанса. Каждая метрика однозначно определяется namespace (контейнером, напр. AWS/EC2 или твоим MyApp/Checkout), именем метрики и нулём или более dimensions — парами имя/значение вроде InstanceId=i-0abc. Тонкость, которая кусает: каждая уникальная комбинация dimensions — это отдельная метрика. Добавь dimension customerId с 50 000 значений — и ты только что создал 50 000 метрик, каждая тарифицируется независимо. Это и есть ловушка высокой кардинальности, и она — самый быстрый способ превратить счёт за метрики в тикет к финансистам.

Разрешение (resolution) — второй регулятор. Метрика либо стандартного разрешения (гранулярность 1 минута), либо высокого (вплоть до 1 секунды). Метрики AWS-сервисов по умолчанию стандартные; для EC2 можно включить detailed monitoring ради 1-минутных данных вместо базовых 5-минутных. Для своих метрик ты вызываешь PutMetricData и решаешь сам. Цена разрешения: каждый вызов PutMetricData тарифицируется, поэтому публикация метрики высокого разрешения каждую секунду — это резко больше запросов и денег, чем раз в минуту. CloudWatch также автоматически прореживает данные метрик: 1-секундные живут около 3 часов, 1-минутные около 15 дней, 5-минутные около 63 дней, а часовые свёртки около 455 дней (15 месяцев), после чего метрика истекает, если новых данных нет.

# Публикуем кастомную метрику стандартного разрешения (гранулярность 1 мин, дефолт)
aws cloudwatch put-metric-data \
  --namespace "MyApp/Checkout" \
  --metric-name CheckoutLatencyMs \
  --dimensions Service=checkout,Env=prod \
  --value 412 --unit Milliseconds

# Высокое разрешение: --storage-resolution 1 хранит с гранулярностью 1 секунда.
# Каждый вызов тарифицируется, так что 1-сек публикация = ~60x запросов PutMetricData против 1-мин.
aws cloudwatch put-metric-data \
  --namespace "MyApp/Checkout" \
  --metric-name CheckoutLatencyMs \
  --storage-resolution 1 \
  --value 412 --unit Milliseconds

Когда ты читаешь метрику, ты выбираешь статистику — Average, Sum, Maximum или перцентиль вроде p99. Этот выбор не косметический. Среднее прячет хвост: если 99 процентов запросов быстрые, а 1 процент падает по таймауту, среднее почти не сдвигается, пока реальные пользователи страдают. Для любого SLO по латентности ставь аларм по p99 (или p95), никогда по среднему. (Заметь: перцентилям нужны сырые точки данных; если ты публикуешь предагрегированный statistic set, p99 обычно не восстановить.) Цены ниже иллюстративны и зависят от региона — в US East (N. Virginia) кастомная метрика стоит около $0.30/метрика/месяц за первые 10 000; всегда сверяйся со страницей цен CloudWatch.

Логи: группы, потоки и ловушка retention

CloudWatch Logs организует данные как лог-потоки (одна последовательность событий на источник — напр. один контейнер), сгруппированные в лог-группы (всё, что разделяет одни и те же настройки retention, доступа и мониторинга). Retention выставляется на лог-группу, и вот ловушка, прямо названная в документации: по умолчанию данные логов хранятся бессрочно — консоль показывает это как Never Expire. Ingest тарифицируется один раз за GB (около $0.50/GB в us-east-1, иллюстративно); storage тарифицируется каждый месяц (около $0.03/GB/месяц). Never-expire плюс высокообъёмные DEBUG-логи означает, что строка storage растёт без предела. Выставляй retention осознанно — 7, 14, 30 или 90 дней для большинства логов приложений — и убирай шумное debug-логирование в проде.

Чтобы превратить логи в сигнал, есть два инструмента. Logs Insights — ad-hoc запросы для расследования: пишешь запрос, сканируешь диапазон времени, получаешь результаты. Metric filter — долговечная версия: он матчит паттерн во входящих лог-событиях и выпускает метрику CloudWatch, которую можно рисовать и алармить — например, считая строки ERROR, чтобы всплеск кого-то поднял.

# Выставляем retention осознанно — эта одна команда — весь фикс ловушки never-expire
aws logs put-retention-policy --log-group-name /myapp/checkout --retention-in-days 14

-- Logs Insights: топ-20 самых медленных запросов checkout за последний час, для ad-hoc разбора
fields @timestamp, requestId, durationMs
| filter service = "checkout" and durationMs > 1000
| sort durationMs desc
| limit 20

// Metric filter: превращаем каждую строку ERROR в метрику-счётчик, по которой можно алармить
{
  "filterName": "checkout-errors",
  "filterPattern": "ERROR",
  "logGroupName": "/myapp/checkout",
  "metricTransformations": [
    { "metricNamespace": "MyApp/Checkout", "metricName": "ErrorCount", "metricValue": "1", "defaultValue": 0 }
  ]
}

Алармы: состояния, окна оценки и за чем следить

Аларм следит за одной метрикой (или выражением metric-math) и сравнивает её с порогом за период на протяжении некоторого числа периодов оценки. Он находится в одном из трёх состояний: OK, ALARM или INSUFFICIENT_DATA (недостаточно точек данных, чтобы решить — частое сразу после создания или когда метрика перестаёт отчитываться). Алармы запускают действия только при устойчивой смене состояния, а не просто из-за нахождения в состоянии — поэтому ты настраиваешь «N из M точек нарушают» для баланса чувствительности и дребезга. Действия идут в SNS-топик (пейджинг, ChatOps) или в политику Auto Scaling.

Два уточнения важны на сеньорском уровне. Композитные алармы комбинируют другие алармы булевым правилом — например (ALARM("CPUHigh") OR ALARM("DiskHigh")) AND OK("Deploying") — так ты получаешь один пейдж по реальному условию вместо десяти связанных пейджей от одной первопричины. Anomaly detection обучает полосу ожидаемых значений по истории и алармит, когда метрика выходит за полосу, что лучше статического порога для метрик с дневной или недельной сезонностью. И повторяющаяся ошибка: алармить по CPU, когда пользователи чувствуют латентность и error rate. Ставь аларм по p99-латентности и по метрике-счётчику ошибок, которую выдаёт твой metric filter, — из этого и сделан SLO.