Мы создаем стек программного обеспечения для обработки медицинских изображений, который в настоящее время размещен на различных ресурсах AWS. В рамках этого приложения у нас есть несколько долго работающих серверов (база данных, балансировщики нагрузки, веб-приложение и т. Д.). Сбор данных о производительности на этих серверах довольно прост - мой рецепт Nagios (для мониторинга / уведомлений) и Munin (для сбора данных о производительности и отображения тенденций) будет работать нормально.
Однако в рамках этого приложения мы постоянно запускаем и завершаем вычислительные экземпляры на EC2. При типичном использовании эти вычислительные экземпляры запускаются, настраиваются, получают задание из очереди сообщений, а затем приступают к обработке этого задания, что занимает от 15 минут до более 8 часов. После завершения работы эти экземпляры прекращают работу, и о них больше никогда не слышно.
Какова эффективная стратегия сбора данных о производительности на этих недолговечных инстансах?
Мне не обязательно следить за ними - если они не работают по какой-либо причине, наше приложение обнаружит это и выполнит повторный запуск задания на другом экземпляре или поднимет флаг, чтобы администратор мог посмотреть на вещи. Однако все равно бы быть полезным для сбора такой информации, как ЦП (пользователь, бездействует, iowait и т. д.), использование памяти, сетевой трафик, данные чтения / записи на диск и т. д. В нашей внутренней базе данных мы отслеживаем идентификатор экземпляра машины, на которой выполняется каждое задание, и было бы весьма полезно иметь возможность искать данные о производительности для конкретного идентификатора экземпляра для устранения неполадок и профилирования.
Munin не кажется отличным кандидатом, так как для этого требуется поддерживать список узлов munin в текстовом файле - что далеко не идеально для среды с большим количеством оттока, и в течение короткого времени каждый узел будет работать, Я бы предпочел хранить данные в полном разрешении на неопределенный срок, чем заставлял бы RRD разбавлять данные с течением времени.
В конце концов, я предполагаю, что для этого потребуется механизм мониторинга, который:
Есть ли другие вещи, о которых я должен думать при оценке вариантов?
Возможно, я слишком много думаю об этом и просто должен бежать sar с интервалом в 1 минуту на этих недолговечных экземплярах и собирать файлы sar db до завершения.
В Zenoss есть плагин EC2Manager, который автоматически добавляет все ваши экземпляры EC2 (даже в версии с открытым исходным кодом) и отслеживает изменения в EC2. Однако Зеносс может быть более тяжеловесным, чем вы действительно хотите.
Zabbix здесь будет отличным выбором.
Его легко настроить, и вы можете настроить автоматическую регистрацию и обнаружение, собирать данные о производительности и очищать записи через X дней.
Если вы заботитесь о сборе данных о производительности, но не о мониторинге, и вам нужно что-то, что не требует настройки каждый раз при рождении или смерти экземпляра, собирать было бы отлично подходит.
Установите один экземпляр как сервер, то есть сеть плагин настроен на получение данных и RRDtool плагин настроен на запись данных. Настройте эфемерные экземпляры с помощью любые плагины вам необходимо собрать соответствующие данные о производительности и настроить сетевой плагин для отправки данных на сервер.
Так как эти экземпляры недолговечны, вы захотите изменить значение по умолчанию. RRATimespan. Если вы не хотите хранить данные в файлах RRD, collectd может отправлять их в другие хранилища данных, такие как graphite или mongodb.
Для эфемерных экземпляров Nagios не подходит, так как вам постоянно придется переписывать файлы конфигурации.
Я недавно исследовал, какие «хорошо известные / обслуживаемые» системы мониторинга подходят для подобных ситуаций.
Следующие системы мониторинга упрощают добавление / удаление хостов:
Я думаю, вам понадобится какая-то центральная CMDB, чтобы быть источником истины. Затем вы можете использовать CMDB в качестве источника данных для Puppet / Chef / и т. Д., Который может настроить отслеживаемые хосты и добавить их на сервер мониторинга.
Я думаю, что правильный подход к эфемерным экземплярам - использовать Amazon CloudWatch или CloudWatch API каким-то образом. Но это во многом зависит от того, что вам действительно нужно увидеть ...
Если вы используете качественное решение для балансировки нагрузки в Облако, что может быть почти более выгодным, чем мониторинг на уровне экземпляра, поскольку балансировщик нагрузки может принимать более обоснованные решения о маршрутизации на основе лучших условий в реальном времени (например, количество подключений, время отклика узла / задержка, географическое положение).
Однако мы стремимся сделать то же самое и потенциально интегрироваться с пакет коммерческого мониторинга мы используем. В противном случае, Зенос вроде есть баночный раствор.