CloudWatch: тревога CPU и остановка EC2

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

Введение

Amazon CloudWatch — сервис категории «Management & Governance» в AWS для мониторинга и управления ресурсами. Он собирает показатели производительности и состояния сервисов (CPU, RAM, NetworkIn, NetworkOut и т. д.) и позволяет запускать действия при достижении заданных условий.

Платежи: CloudWatch имеет бесплатный уровень (Free Tier) с базовой метрикой каждые 5 минут и платный уровень с метриками каждую 1 минуту. Это не единственное отличие — платные функции и дополнительные метрики влияют на счёт.

Ниже — пошаговое руководство по настройке тревоги, подписки и автоматической остановке EC2-инстанса при высоком CPU.

Ключевые термины

• Alarm — объект CloudWatch, сравнивающий метрику или выражение с порогом и меняющий состояние (OK, IN ALARM, INSUFFICIENT_DATA). Определяет действия при срабатывании.
• SNS Topic — логический канал уведомлений (Simple Notification Service). Подписчики получают уведомления по выбранному протоколу (email, SMS, Lambda и т. д.).
• EC2 Action — действие над инстансом EC2 (stop, terminate, reboot и т. п.), которое можно привязать к тревоге.

Что мы сделаем

1. Войдём в AWS Console.
2. Создадим SNS-topic и подпишем email.
3. Создадим Alarm по CPUUtilization для EC2.
4. Смоделируем нагрузку на инстансе и проверим срабатывание.

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

1. Аккаунт AWS.
2. Рабочий EC2-инстанс (Ubuntu 18.04 или аналогичный для теста).

Подготовка: вход в AWS

1. Перейдите на страницу входа AWS и авторизуйтесь.

После входа вы увидите главную консоль с перечислением сервисов.

Создание SNS Topic и подписки на email

1. В консоли нажмите «Services» и найдите Simple Notification Service (SNS).

2. Нажмите Create topic.

3. Дайте уникальное имя теме, например my-sns-topic. Display name — по желанию.

4. После создания темы создайте Subscription: выберите ARN темы, Protocol = Email и введите адрес для уведомлений. Нажмите Create subscription.

5. Откройте почту и подтвердите подписку по ссылке из письма AWS — пока подписка не подтверждена, уведомления идти не будут.

Важно: у вас должна быть возможность получать почту на указанный адрес. Без подтверждения подписки уведомления не доставляются.

Создание Alarm в CloudWatch

1. В консоли AWS найдите CloudWatch через Services.

2. В левой навигации выберите Alarms.

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

4. Нажмите Select metrics и выберите All metrics → EC2 → Per-Instance Metrics.

5. Выберите метрику CPUUtilization и нажмите Select metric.

6. Укажите InstanceId нужного инстанса. Для тестов выставьте Period = 1 minute (1 минута). Это ускорит тестирование тревоги.

7. Установите условие: Threshold значение = 10 (10%). То есть если CPUUtilization превысит 10% в течение 1 минуты — тревога сработает.

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

8. На шаге Notifications выберите SNS Topic, который вы создали (my-sns-topic), и назначьте его для состояния In Alarm.

9. Добавьте действие: в Actions выберите Stop для данного EC2-инстанса — при срабатывании тревоги инстанс будет остановлен. Затем Next.

10. Дайте Alarm уникальное имя и, при необходимости, описание — это попадёт в тему письма.

11. Просмотрите конфигурацию и нажмите Create alarm.

Через минуту CloudWatch начнёт мониторинг по созданной тревоге.

Тестирование: повышение нагрузки на EC2

Для имитации нагрузки установим пакет stress на Ubuntu 18.04. Выполните эти команды на EC2-инстансе под пользователем с sudo.

sudo apt-get update

sudo apt-get install stress

Затем запустим нагрузку: в примере мы подаем нагрузку на CPU до 50% в течение 120 секунд (2 минуты). Это должно превысить порог 10% и спровоцировать срабатывание тревоги и действие Stop.

stress --cpu  50 --timeout 120

Когда условие выполнится, вы получите email-уведомление, а действие Stop будет инициировано.

В интерфейсе CloudWatch вы увидите состояние тревоги In Alarm.

Как результат, EC2-инстанс будет остановлен (или завершён в зависимости от настроенного действия).

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

• Тревога создана и привязана к метрике CPUUtilization конкретного InstanceId.
• SNS-топик создан и подписка подтверждена по email.
• В CloudWatch для состояния In Alarm настроена рассылка на SNS-топик.
• Для состояния In Alarm назначено действие Stop над тем же EC2-инстансом.
• При генерации нагрузки (stress) приходит email, и инстанс останавливается.

Мини-методология для повторного использования

1. Создать и подтвердить SNS-топик и подписку.
2. В CloudWatch выбрать метрику и инстанс.
3. Установить период, порог и действие.
4. Протестировать нагрузкой и проверить логи/AWS Console.
5. При необходимости скорректировать порог и период.

Роль-based чек-лист (кто что делает)

• Администратор AWS:
  • Создаёт SNS-топик и управляет доступом (IAM-права).
  • Настраивает политики шифрования и доступности топика.
• DevOps-инженер:
  • Создаёт и тестирует Alarm в CloudWatch.
  • Настраивает действия (Stop/Terminate) и проверяет IAM-ролей для выполнения действий.
• Разработчик/Ответственный за сервис:
  • Тестирует поведение приложения при остановке инстанса.
  • Обеспечивает, чтобы автоскейлинг/резервирование компенсировали остановку, если нужно.

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

1. Нормальная нагрузка ниже порога — Alarm остаётся в состоянии OK, никаких уведомлений.
2. Нагрузка выше порога в течение заданного периода — Alarm переходит в In Alarm и отправляет уведомление; действие Stop выполняется.
3. Период данных отсутствует (Insufficient Data) — Alarm показывает состояние INSUFFICIENT_DATA; проверьте метрики и сбор данных.
4. Подписка SNS не подтверждена — уведомления не доставляются; в логах CloudWatch видно успешную публикацию, но почта не получает письмо.

Отладка: когда это не работает

• Нет уведомлений, хотя Alarm показал срабатывание: проверьте, подтверждена ли подписка SNS и не попало ли письмо в спам.
• Alarm остаётся в INSUFFICIENT_DATA: проверьте, собираются ли метрики с нужной частотой и выбран правильный Namespace/InstanceId.
• Действие STOP не выполняется: проверьте IAM-политику и роли, разрешающие CloudWatch/EC2 выполнять стоп-инстанса.
• Ложные срабатывания при кратковременных пиках: увеличьте период агрегации (например, 5 минут) или используйте статистики (Average/Maximum).

Безопасность и соответствие (GDPR и доступ)

• Email-подписки не являются приемлемым способом доставки конфиденциальных данных. Не включайте в шаблоны уведомлений чувствительную информацию.
• Для действий над инстансами используйте минимально необходимые IAM-права и роли. Ограничьте кто может создавать/редактировать Alarm и SNS-топики.
• Логи уведомлений и действий храните в зашифрованном виде (KMS) при необходимости соответствия.

Практические рекомендации и альтернативы

• Вместо Stop можно назначить запуск Lambda-функции, которая выполнит проверку состояния приложения и примет решение — более гибкий и безопасный подход.
• Для сложных условий используйте Metric Math и выражения в CloudWatch (например, комбинировать CPU и Network для более точных правил).
• Для масштабируемых систем рассмотрите интеграцию с Auto Scaling Groups: вместо остановки одного инстанса триггер может уменьшать/увеличивать группу.

Факто-бокс: ключевые числа и понятия

• Частота базовых метрик Free Tier: 5 минут.
• Частота платных метрик: 1 минута.
• Состояния Alarm: OK, IN ALARM, INSUFFICIENT_DATA.
• Примеры действий: Send notification (SNS), Stop, Terminate, Reboot, Recover.

Шаблон контроля и отката (Runbook)

1. Если Alarm сработала по ошибке и инстанс остановлен — зайдите в EC2 Console и запустите инстанс вручную (Start).
2. Проверьте: CloudWatch Metrics → график CPU; SNS Publish logs; CloudTrail события для действий EC2.
3. Если это системная ошибка (ложное срабатывание) — поправьте порог/период или отключите Alarm и создайте тестовую версию.
4. Для отката автоматизации удалите действие Stop из Alarm и замените на тестовую Lambda с логированием.

Краткие рекомендации по стоимости

• Использование частых (1 мин) метрик увеличивает расход CloudWatch; для тестов это оправдано, в продакшене оцените Cost VS Benefit.
• SNS-уведомления по email обычно не влияют на счёт, но дополнительные каналы (SMS) платные.

Резюме

• CloudWatch + SNS позволяют быстро и надёжно реагировать на метрики EC2.
• Для теста: создайте SNS-топик, подпишитесь, настройте Alarm по CPUUtilization с периодом 1 минута и действием Stop.
• В продакшне используйте более консервативные пороги и периоды, проверяйте IAM-права и шифрование.

Важно: тестовые остановки инстансов могут повлиять на доступность сервиса — заранее предупредите команду и выполните тест в контролируемом окружении.

Дополнительные ресурсы и чек-лист:

• Подтвердить SNS-подписку в почте.
• Проверить, что CloudWatch собирает метрики для нужного InstanceId.
• Убедиться в наличии IAM-прав для действий Stop/Start.
• Продумать поведение при реальных инцидентах: оповещения, аварийное восстановление, Runbook.