Оповещения CloudWatch и составные оповещения

CloudWatch alarm отслеживает одну метрику или результат выражения математического вычисления метрик в течение указанного Вами периода. Когда метрика пересекает заданный Вами порог, alarm меняет состояние и может автоматически запустить действие, например отправить уведомление SNS, изменить размер Auto Scaling group, остановить экземпляр EC2 или выполнить элемент OpsItem в Systems Manager. Сигналы — основной механизм автоматического реагирования на операционные события в AWS.

CloudWatch alarm всегда находится в одном из трёх состояний: OK — метрика находится в пределах заданного порога; ALARM — метрика пересекла порог в течение необходимого числа периодов оценки; INSUFFICIENT_DATA — alarm только что создан, метрика недоступна или пока собрано недостаточно данных. Переходы между состояниями запускают действия, настроенные для соответствующего изменения состояния: для состояний OK, ALARM и INSUFFICIENT_DATA можно указать разные темы SNS.

При создании alarm указываются: метрика и пространство имён, статистика (Average, Sum, Maximum и т. д.), период (как часто метрика оценивается, в секундах), периоды оценки (сколько последовательных периодов должны пересечь порог), значение порога и оператор сравнения. alarm срабатывает, когда метрика пересекает порог в течение указанного числа последовательных периодов оценки.

Действия alarm могут быть направлены в несколько мест: темы Amazon SNS (для отправки электронной почты, SMS или запуска Lambda), политики Auto Scaling (для уменьшения или увеличения ASG) и действия EC2 (для остановки, завершения работы, перезагрузки или восстановления экземпляра EC2). Для каждого состояния (OK, ALARM, INSUFFICIENT_DATA) можно указать отдельный набор действий: например, уведомлять команду при ALARM, сообщать о восстановлении при OK и отправлять предупреждение при INSUFFICIENT_DATA, чтобы обнаруживать пробелы в мониторинге.

Когда CloudWatch оценивает alarm, а некоторые точки данных отсутствуют, необходимо решить, как их обрабатывать. Доступны следующие варианты: notBreaching (считать отсутствующие данные находящимися в пределах порога — alarm остаётся в состоянии OK, если остальные данные соответствуют норме), breaching (считать отсутствующие данные превышающими порог — alarm переходит в ALARM), ignore (состояние alarm не изменяется) и missing (alarm переходит в INSUFFICIENT_DATA). Неправильный выбор приводит к ложным срабатываниям или незаметным сбоям — это важный нюанс экзамена SAA-C03.

Разрешение alarm — это произведение периода на количество периодов оценки. Например, период в 60 секунд и 5 периодов оценки означают, что alarm анализирует 5 последовательных точек данных с интервалом в 1 минуту. По умолчанию alarm переходит в ALARM только тогда, когда все пять периодов пересекают порог. С помощью параметра datapoints-to-alarm можно потребовать, чтобы порог был пересечён только в M из N периодов, например в 3 из 5, что уменьшает число ложных срабатываний из-за кратковременных скачков.

Составной сигнал оценивает состояние нескольких других сигналов с помощью булевой логики (AND, OR, NOT). Он переходит в состояние ALARM только тогда, когда выражение его правила даёт значение true. Составные сигналы используются, чтобы уменьшить количество лишних уведомлений: например, отправлять уведомление только при одновременном срабатывании сигналов высокой загрузки CPU и высокой задержки, поскольку одна лишь высокая загрузка CPU может быть допустима во время пакетной обработки. Составные сигналы также можно использовать для подавления дочерних сигналов на время обслуживания.

Составные сигналы поддерживают действия по подавлению сигналов: составной сигнал можно настроить так, чтобы он подавлял дочерние сигналы во время планового обслуживания. Например, на время развёртывания можно настроить составной сигнал, объединяющий сигнал 'MaintenanceMode' с помощью логики OR и подавляющий все уведомления дочерних сигналов, пока активно обслуживание. Это предотвращает лавину уведомлений, когда Вы намеренно отключаете сервисы для обновления.

Группы Auto Scaling используют сигналы CloudWatch как триггеры для политик пошагового масштабирования и простого масштабирования. Когда сигнал переходит в состояние ALARM, выполняется политика масштабирования. Для пошагового масштабирования задаются разные изменения размера для различных диапазонов порогов: например, добавить 1 экземпляр при загрузке CPU 70–80%, 3 — при 80–90% и 5 — при загрузке выше 90%. Сигнал запускает первый подходящий шаг на основе уровня превышения порога в момент оценки.

В CloudWatch можно создать платёжные сигналы, чтобы получать уведомления, когда расчётные расходы AWS превышают заданный порог. Платёжные метрики публикуются только в регионе us-east-1, независимо от того, где работают Ваши ресурсы, и обновляются примерно каждые 6 часов. Чтобы включить платёжные сигналы, сначала необходимо активировать Billing Alerts в консоли AWS Billing. Более точным инструментом является AWS Budgets, однако платёжные сигналы CloudWatch по-прежнему представляют собой допустимый вариант, проверяемый на экзамене.

Вы можете вручную задать состояние alarm с помощью команды set-alarm-state, чтобы проверить действия alarm, не дожидаясь фактического пересечения порога. Это полезно для проверки того, что темы SNS, политики Auto Scaling и функции Lambda реагируют правильно. Всегда тестируйте действия alarm в среде, не предназначенной для эксплуатации, и убедитесь, что для темы SNS подтверждены правильные подписки электронной почты, прежде чем полагаться на сигналы при уведомлении о событиях в рабочей среде.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что сигналы имеют три состояния (OK, ALARM, INSUFFICIENT_DATA) и могут запускать действия SNS, Auto Scaling и EC2; параметр datapoints-to-alarm позволяет выполнять оценку по схеме M из N, уменьшая число ложных срабатываний; а составные сигналы используют булеву логику для объединения нескольких сигналов и подавления лишних уведомлений. Далее мы рассмотрим CloudWatch Logs и Log Insights для централизованного управления журналами.