У меня есть приложение, работающее на AWS. Как настроить Amazon CloudWatch для уведомления о сбое экземпляра EC2 или о том, что он больше не отвечает?
Я просмотрел экраны CloudWatch, и оказалось, что вы можете отслеживать определенную статистику, например, загрузку процессора или диска, но я не видел способа отслеживать событие типа "экземпляр получил запрос http и занял более X секунд, чтобы реагировать."
Чтобы отслеживать событие в 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.
Amazon Route 53 Health Check - правильный инструмент для работы.
Маршрут 53 может контролировать работоспособность вашего приложения, а также ваши веб-серверы и другие ресурсы.
Вы можете настроить проверки ресурсов HTTP в Route 53, которые будут вызывать уведомление по электронной почте, если сервер не работает или отвечает с ошибкой.
http://eladnava.com/monitoring-http-health-email-alerts-aws/
Мониторинг CloudWatch аналогичен тому, как вы это обнаружили. Вы сможете сделать вывод о том, что один из ваших экземпляров заморожен, взглянув на метрики, но CloudWatch не будет, например. отправьте вам электронное письмо, если ваше приложение работает слишком медленно, например.
Если вы ищете какое-то уведомление, когда ваше приложение или экземпляр не работает, я предлагаю вам использовать службу мониторинга. Pingdom - хороший вариант. Вы также можете настроить новый экземпляр на AWS и установить средство мониторинга, например Nagios, что было бы моим предпочтительным вариантом.
Хорошая практика, которая всегда стоит на долгой дороге: используя балансировку нагрузки (Amazon ELB), более одного экземпляра приложения, Автомасштабирование (когда экземпляр отключен, Amazon автоматически запустит новый и сохранит ваш SLA) и пользовательский мониторинг.
Моя команда долгое время использовала пользовательский мониторинг script, и мы всегда знали о сбоях, как только они произошли. В принципе, если у нас было два узла, на которых запущено наше приложение, node 1 отправил HTTP-запросы на node 2 и node 2 на 1. Если какой-либо запрос занял больше, чем ожидалось, или возвратил неожиданный статус HTTP или тело ответа, script отправил электронное письмо системным администраторам. В настоящее время мы полагаемся на более надежные подходы, такие как Nagios, которые могут даже контролировать содержимое операционной системы (потоки и т.д.), Серверы приложений (здоровье пулов соединений и т.д.) И т.д. Это стоит того, чтобы каждый цент инвестировал в настройку.
Недавно CloudWatch добавила метрики статуса, которые ответят на один из ваших вопросов о том, включен ли экземпляр или нет. Он не будет запрашивать ваш веб-сервер, а проверять систему. Как следует из предыдущего ответа, используйте ELB для проверки работоспособности HTTP.
У вас всегда может быть другой экземпляр для инструментов/тестирования, этот экземпляр будет пытаться использовать http-запрос на основе расписания и измерять время отклика, тогда вы можете опубликовать это время ответа с помощью CloudWatch и установить будильник, когда он пройдет определенное пороговое значение.
Вы даже можете сделать это из самого экземпляра.
Как упоминал выше Kurst Ursan, использование показателей "Проверка статуса" - это путь. В некоторых случаях вы не сможете просмотреть эти показатели (например, если вы используете AWS OpsWorks), поэтому вам придется сообщать об этом индивидуальном показателе. Тем не менее, вы можете настроить будильник, построенный на метрике, которая всегда соответствует (в состоянии "ОК" ) и имеет триггер тревоги, когда состояние переходит в состояние "НЕДОСТАТОЧНЫЕ ДАННЫЕ", это технически означает, что CloudWatch не может определить, нормально ли состояние или ALARM, потому что он не может достичь вашего экземпляра, AKA ваш экземпляр отключен.
Существует множество способов получить информацию о здоровье экземпляра. Вот пара.
Наблюдайте за проверками состояния экземпляра и событиями EC2 (запланированное время простоя) в API EC2. Вы можете опросить их и отправить в Cloudwatch, чтобы создать будильник.
Создайте на сервере простой демон, который каждую секунду пишет в DynamoDB (имеет лучшую детализацию, чем Cloudwatch). Второй процесс запрашивает сердцебиение и предупреждает об отсутствии.
Поместите все экземпляры в балансировщик нагрузки с открытым фиктивным портом, который дает ответ TCP. Настройте проверки работоспособности TCP на ELB и оповещайте о нездоровых экземплярах.
Если вы не используете такой продукт, как Blue Matador (автоматически уведомляет вас о производственных проблемах), на самом деле довольно ужасно устанавливать что-то подобное, не говоря уже о том, чтобы поддерживать его. Тем не менее, если вы идете по дороге и вам нужна помощь по началу работы с Cloudwatch (терминология, оповещения, журналы и т.д.), Начните с этого блога: " Как контролировать Amazon EC2 с CloudWatch".