При работе в облаке и автоматическом масштабировании боксов возникают определенные проблемы с мониторингом. Иногда мы можем контролировать 10 коробок, а иногда 100. Машины будут масштабироваться вверх и вниз в зависимости от спроса.
Сейчас я думаю, что лучшим решением для этого будет выбор решения для мониторинга, которое будет создавать экземпляры целей через вызовы API. Но действительно ли это лучшее? Мне нравится идея динамического обнаружения, но это также проблема в облаке, поскольку не все цели находятся в одной подсети.
Какие решения для мониторинга позволяют создавать подобную масштабируемую среду? Zabbix в настоящее время имеет черновик API но мне не удалось профинансировать аналогичный API для Nagios. Есть ли аналогичный API для Nagios?
У кого-нибудь есть альтернативные предложения, кроме Nagios и Zabbix?
Используйте Zabbix. В их предстоящем выпуске 2.0 есть много новых функций для подобных вещей. Текущая версия 1.8 имеет авторегистрацию.
В документе «Новые возможности» говорится об этой функции:
4.2.2 Автоматическая регистрация активных агентов
Совершенно новая в Zabbix 1.8 возможность разрешить активную авторегистрацию Zabbix агента, после чего сервер может начать их мониторинг. Это позволяет добавлять новые хосты для мониторинга без какой-либо ручной настройки сервера для каждого отдельного хоста.
Эта функция может быть очень удобна для автоматического мониторинга новых облачных узлов. Как только у вас появится новый узел в облаке, Zabbix автоматически начнет сбор данных о производительности и доступности узла.
Фермерская вилла, который утверждает, что добавляет сотни серверов в неделю, использует Кукольный, Nagios, и Мунин управлять своей масштабируемой системой мониторинга. Они, вероятно, используют факты Puppet для заполнения файлов конфигурации Nagios или для настройки NRPE. С таким количеством серверов инструмент управления конфигурацией, такой как Puppet, практически необходим.
Пара примеров, найденных с помощью поиска "марионеточные нагио":
http://blog.gurski.org/index.php/2010/01/28/automatic-monitoring-with-puppet-and-nagios/
http://projects.puppetlabs.com/projects/puppet/wiki/Nagios_Patterns
для zabbix api есть инструмент командной строки zabcon (http://trac.red-tux.net/wiki/zbx_api/interactive). он еще не полностью функционален, но должен поддерживать некоторые базовые операции с хостом и элементами - возможно, вы сможете работать с этим.
Если вы настроили nagios для загрузки каталогов файлов конфигурации с помощью "cfg_dir", вы можете просто добавить или удалить cfg-файл при добавлении или удалении узла и перезапустить nagios. Нет реальной необходимости в API, его можно настроить с помощью нескольких небольших сценариев оболочки и SSH с ключевыми файлами.
У меня нет опыта работы с Zabbix, но я могу порекомендовать Nagios, так как его довольно легко настраивать, запускать и настраивать.
Никаких предложений, но ваша логика верна: в динамических средах, подобных той, которую вы описываете, когда появляется хост, он должен зарегистрироваться во всем, что нужно знать о его существовании (например, в системе мониторинга), а когда он выключается, ему нужно чтобы отменить регистрацию с вещами, о которых нужно знать, что это уходит.
Вопрос, который я хотел бы задать: нужно ли вам контролировать свои «рабочие лошадки»? Если это вычислительные узлы или аналогичные, и вы знаете, что их конфигурация стабильна и будет "просто работать", когда они будут развернуты, мониторинг самого облака (сколько запущенных экземпляров) может быть таким же хорошим, как отслеживание отдельных машин, если вы облачный провайдер позволяет легко получить доступ к такой статистике.
Хотя у меня нет опыта работы с Zabbix, я почти уверен, что Nagios не сможет сделать это за вас без вмешательства администратора, не говоря уже о том, что из коробки. Проблема в том, что когда вы создаете файл конфигурации (для добавления хоста) или редактируете / удаляете его, вам необходимо перезапустить Nagios. После перезапуска потребуется пара минут (в зависимости от настроек), чтобы выполнить первую проверку служб на этих хостах (проверка того, включен ли сам хост, должна занять всего пару секунд). Если эти машины будут добавляться или удаляться несколько раз в день, я предвижу, что это будет ваша первая проблема.
Вы можете использовать систему, которая сделает это за вас. Я считаю, что у Nagios есть плагины, которые делают это, но я обнаружил, что файлы cfg, созданные машиной, никогда не так хороши, как создание их вручную. Фактически, большинство этих автоматических конфигураций хранятся в одном или, возможно, в нескольких файлах. Что делает его PITA для управления ...
Однако, поскольку Nagios имеет открытый исходный код и все такое, я уверен, что если у вас есть необходимые знания, вы можете написать код и реализовать собственную систему. Я подозреваю, что машины, которые появляются (или отключаются), являются виртуальными машинами, и что на них уже есть предустановленный NSClient или любой другой агент, который вы решите использовать. Это означает, что если вы можете запустить сценарий всякий раз, когда машина включается или выключается, вы можете создать или удалить файл конфигурации с именем .cfg или .cfg, а затем перезагрузить Nagios. Получите сценарий для редактирования имени хоста и IP-адреса рассматриваемого хоста, и все готово! Это, конечно, если первое, что я сделал, для вас не имеет значения ...
Удачи
Я давно не играл с Зенос, но я думаю, это может быть то, что вы ищете.