Мониторинг CloudWatch

Глаза и уши вашей инфраструктуры в облаке — это CloudWatch.

CloudWatch — сервис наблюдаемости AWS: собирает метрики (числовые показатели), логи (текстовые записи) и шлёт алармы (оповещения) при выходе за пороги.

Зачем нужна наблюдаемость

Нельзя управлять тем, чего не видишь. CloudWatch отвечает на вопросы «работает ли система», «не перегружена ли она», «не растёт ли число ошибок». Без него вы узнаёте о проблеме от пользователей, а с ним — заранее, от автоматического оповещения.

Три кита CloudWatch

Метрики

Числовые показатели во времени: загрузка CPU инстанса, число запросов к балансировщику, задержки Lambda, свободное место в базе. AWS собирает многие метрики автоматически, и их видно на графиках.

Логи

Текстовые записи от приложений и сервисов. Лог-группы хранят строки, по которым можно искать, фильтровать и строить метрики (например, считать число строк со словом ERROR).

Алармы

Правило: «если метрика выходит за порог — действуй». Алармы шлют уведомление (через SNS — на почту или в мессенджер) или запускают автоскейлинг.

aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

Вывод:

Alarm "high-cpu" created: state=INSUFFICIENT_DATA -> OK -> ALARM at CPU>80% (2 периода по 5 мин)

Как работает под капотом

Сервисы AWS непрерывно отправляют метрики в CloudWatch, где они хранятся как ряды точек во времени с заданным шагом (period). Аларм на каждом интервале сравнивает агрегированное значение метрики с порогом и считает, сколько периодов подряд условие нарушено (evaluation periods). Только когда нарушений набирается нужное число, аларм переходит в состояние ALARM и запускает действие — это защищает от ложных срабатываний на единичный всплеск. Состояние INSUFFICIENT_DATA означает, что данных пока недостаточно для вывода. Своё приложение тоже может слать кастомные метрики через API.

Частые ошибки

  • Не настроить алармы заранее. Метрики без алармов — это график, на который никто не смотрит до аварии.
  • Слишком чувствительный порог. Аларм на один период будет «кричать» от любого всплеска; используйте несколько evaluation periods.
  • Игнорировать логи. Лог-группы тоже занимают место и стоят денег; задавайте срок хранения (retention).

Итог

  • CloudWatch собирает метрики и логи и шлёт алармы при выходе за пороги.
  • Аларм срабатывает не на единичный всплеск, а после нескольких нарушений подряд (evaluation periods).
  • Настраивайте алармы и оповещения заранее и задавайте срок хранения логов.
Проверьте себя
1. Что из перечисленного НЕ относится к трём основным возможностям CloudWatch?
AМетрики
BЛоги
CАлармы
DСоздание виртуальных машин
2. Зачем у аларма параметр evaluation periods (число периодов)?
AЧтобы аларм срабатывал мгновенно на любой всплеск
BЧтобы аларм срабатывал только после нескольких нарушений подряд и не реагировал на единичный скачок
CЧтобы увеличить счёт
DОн ни на что не влияет