Более подробно мониторинг инстансов EC2?

В настоящее время я использую AWS Cloudwatch для отслеживания основных показателей своих серверов EC2.

Но ему не хватает детального мониторинга, такого как используемое пространство раздела, свободная память и т. Д.

Стоит ли мне устанавливать и использовать Nagios или другие лучшие альтернативы?

(Я хочу максимально автоматизировать, разве я не предпочитаю Nagios ...)

У меня есть простой сценарий, который я написал и проверяет, достигает ли процессор или память порогового значения, которое я считаю высокой нагрузкой. Если это так, сценарий вызовет другой сценарий, который соберет для меня информацию для анализа причин высокой нагрузки и отправит ее на мой адрес электронной почты в виде вложения. Ниже приведен образец моего сценария, который вы, возможно, захотите улучшить и применить к своим потребностям.

#!/bin/bash

GATHER_INFO=<SCRIPT_NAME_HERE>
CPU_LOAD=$(uptime | cut -d"," -f4 | cut -d":" -f2 | cut -d" " -f2 | sed -e "s/\.//g")
CPU_THRESHOLD=<VALUE_HERE>
MEMORY_USAGE=$(free -m | grep -i "buffers/cache" | awk '{ print $3 }')
MEMORY_THRESHOLD=<VALUE_HERE>

if [ $CPU_LOAD -gt $CPU_THRESHOLD ] ; then
  $GATHER_INFO # I call another script here.
  <SEND_INFORMATION_GATHERED_BY_EMAIL_HERE> # I use nail/mailx here.
  exit 0
elif [ $MEMORY_USAGE -gt $MEMORY_THRESHOLD ] ; then
  $GATHER_INFO # I call another script here.
  <SEND_INFORMATION_GATHERED_BY_EMAIL_HERE> # I use nail/mailx here.
  exit 0
fi

exit 0

Обратите внимание, что внешний скрипт $ GATHER_INFO зависит от инструментов, которые уже установлены в вашей системе (например, sysstat).

Я ответил на аналогичную проблему и находится Вот для справки.

Я также использовал Мунин и его очень просто использовать, но проблема заключается в том, что дисковый ввод-вывод слишком велик на сервере Munin, что нецелесообразно, если вы размещаете его в одном из экземпляров EC2, если вы не отслеживаете только несколько экземпляров.

Cloudwatch по умолчанию предоставляет базовые метрики. Вы можете добавлять собственные и подробные метрики по своему желанию (хотя вы ограничены 10 дополнительными бесплатными метриками).

Для двух приведенных вами примеров (дисковое пространство и используемая память) очень легко настроить Cloudwatch. По сути, вам нужно: сценарий, запускаемый через cron, который будет собирать данные и записывать пользовательские метрики в cloudwatch (например, aws-missing-tools или это сообщение на форуме).

Кроме того, все сводится к тому, чем вы хотите заниматься. Если вышеперечисленное соответствует вашим потребностям, нет необходимости искать более сложные решения. Более того, в зависимости от того, что вы подразумеваете под «автоматизацией», облачные часы более интегрированы в остальную часть AWS, что во многих случаях позволит вам упростить управление (например, запуск новых экземпляров).

CopperEgg предоставляет более подробное представление о производительности и работе ваших серверов. Более подробно с точки зрения: - данных с более высоким разрешением ... то есть метрики сервера собираются, анализируются и отображаются до 10 раз в минуту, и - расширенного набора метрик ... например, видя основные процессы, запущенные на каждом экземпляре , в реальном времени и исторически

Что касается автоматизации, CopperEgg предоставляет веб-хуки, а также интеграцию с Puppet и Chef.

Полное раскрытие информации: меня зовут Скотт Джонсон, и я работаю в CopperEgg. Услуги CopperEgg размещены на Amazon EC2, и мы используем все наши инструменты для мониторинга собственных услуг.

Бест, Скотт

Cloudwatch не предназначен для обеспечения высокой гибкости и удовлетворения ВСЕХ ваших потребностей в мониторинге. он охватывает базовый и средний уровень мониторинга и не имеет многих функций, которые присутствуют в системе мониторинга Enterprise (поскольку он не предназначен для того, чтобы быть похожим на одну из них, его фокус другой).

Я бы лично рекомендовал вам использовать ZenOSS (простота использования) или Nagios (сложная ручная настройка)