Как настроить CloudWatch для обнаружения сбоя экземпляра EC2?

Question

У меня есть приложение, работающее на AWS. Как настроить Amazon CloudWatch , чтобы уведомлять меня о сбое экземпляра EC2 или о том, что он больше не отвечает?

Я прошел через экраны CloudWatch, и кажется, что вы можете отслеживать определенную статистику, например, загрузку ЦП или диска, но я не видел способа отслеживать событие типа «экземпляр получил запрос http и занял больше X секунд, чтобы ответить. "

Answer 1

Маршрут Amazon 53 Health Check - правильный инструмент для работы.

Route 53 может контролировать состояние и производительность вашего приложения, а также ваших веб-серверов и других ресурсов.

В маршруте 53 можно настроить проверки ресурсов HTTP, которые будут запускать уведомление по электронной почте, если сервер не работает или отвечает с ошибкой.

http://eladnava.com/monitoring-http-health-email-alerts-aws/

Answer 2

Для отслеживания события в CloudWatch вы создаете Тревога , которая отслеживает показатель по заданному порогу.

При создании будильника вы можете добавить «действие» для отправки уведомления. AWS обрабатывает уведомления через SNS (Simple Notification Service). Вы можете подписаться на тему уведомлений, и тогда вы получите электронное письмо для вашей тревоги.

Для показателей EC2, таких как загрузка ЦП или диска, это руководство из документации AWS: http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/US_AlarmAtThresholdEC2.html

Как уже было сказано, используйте ELB для мониторинга HTTP.

Это список доступных метрик для ELB: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_MonitoringLoadBalancerWithCW.html#available_metrics

Чтобы ответить на ваш конкретный вопрос, для отслеживания X секунд ответа HTTP вы должны настроить сигнализацию для контроля ELB «Задержка».

Answer 3

Мониторинг CloudWatch такой же, как вы обнаружили. Вы сможете сделать вывод, что один из ваших экземпляров заморожен, посмотрев на метрики, но CloudWatch не будет, например. например, отправлять вам электронные письма, когда ваше приложение не работает или работает слишком медленно.

Если вы ищете какое-то уведомление, когда ваше приложение или экземпляр не работает, я предлагаю вам использовать службу мониторинга. Pingdom - хороший вариант. Вы также можете настроить новый экземпляр в AWS и установить инструмент мониторинга, например Nagios , что будет моим предпочтительным вариантом.

Хорошие практики, которые всегда стоят того, на долгом пути: использование балансировки нагрузки ( Amazon ELB ), более одного экземпляра, на котором работает ваше приложение, Автоматическое масштабирование (когда экземпляр не работает, Amazon автоматически запускает новый и поддерживать ваш SLA), и пользовательский мониторинг.

Моя команда долгое время использовала собственный сценарий мониторинга, и мы всегда знали о сбоях, как только они возникали. По сути, если у нас было два узла, запускающих наше приложение, узел 1 отправлял HTTP-запросы на узел 2 и узел 2 на 1. Если какой-либо запрос принял больше, чем ожидалось, или вернул неожиданный статус HTTP или тело ответа, скрипт отправил электронное письмо системные администраторы. В настоящее время мы полагаемся на более надежные подходы, такие как Nagios, который может даже отслеживать компоненты операционной системы (потоки и т. Д.), Серверы приложений (состояние пулов соединений и т. Д.) И так далее. Это стоит каждого цента, вложенного в его установку.

Answer 4

CloudWatch недавно добавил метрики «проверки состояния», которые ответят на один из ваших вопросов о том, не работает ли экземпляр или нет. Он не будет выполнять запрос к вашему веб-серверу, а будет проверять систему. Как и в предыдущем ответе, используйте ELB для проверки работоспособности HTTP.

Answer 5

У вас всегда может быть другой экземпляр для инструментов / тестирования, который будет пытаться выполнить http-запрос на основе расписания и измерить время отклика, а затем вы можете опубликовать это время отклика с помощью CloudWatch и установить будильник, когда он превышает определенный порог.

Вы можете сделать это даже из самого экземпляра.

Answer 6

Как упоминалось выше, Курст Урсан, использование метрик «Проверка состояния» - это путь. В некоторых случаях вы не сможете просматривать эти метрики (т. Е. Если вы используете AWS OpsWorks), поэтому вам придется сообщать об этой собственной метрике самостоятельно. Однако вы можете настроить сигнализацию, построенную на метрике, которая всегда совпадает (в состоянии ОК) и иметь триггер тревоги, когда состояние меняется на состояние «НЕДОСТАТОЧНЫЕ ДАННЫЕ», это технически означает, что CloudWatch не может определить, в порядке ли состояние. или ALARM, потому что он не может достичь вашего экземпляра, AKA ваш экземпляр находится в автономном режиме.

Answer 7

Существует множество способов получить информацию о здоровье экземпляра. Вот пара.

1. Следите за проверками состояния экземпляров и событиями EC2 (запланированное время простоя) в API EC2. Вы можете опросить их и отправить в Cloudwatch, чтобы создать будильник.

2. Создайте на сервере простой демон, который каждую секунду пишет в DynamoDB (имеет лучшую гранулярность, чем Cloudwatch). Попросите второй процесс запросить сердцебиение и предупредить об отсутствии.

3. Поместите все экземпляры в балансировщик нагрузки с открытым фиктивным портом, который дает ответ TCP. Настройте проверки работоспособности TCP на ELB и оповещайте о нездоровых экземплярах.

Если вы не используете такой продукт, как Blue Matador (автоматически уведомляет вас о производственных проблемах), на самом деле довольно отвратительно устанавливать что-то подобное, не говоря уже о том, чтобы поддерживать его. Тем не менее, если вы идете по дороге и вам нужна помощь по началу работы с Cloudwatch (терминология, оповещения, журналы и т. Д.), Начните с этого блога: Как отслеживать Amazon EC2 с CloudWatch