Является ли Nagios «мониторингом» WAN-идеала?

Я только начинал в новой компании, и одно из моих первых заданий - искать альтернативы их внутренней системе мониторинга.

Их текущее решение - это приложение .Net, которое проверяет различные устройства в глобальной сети (поскольку они являются консалтинговой фирмой, предоставляющей круглосуточную поддержку / «обслуживание»). Устройства варьируются от маршрутизаторов / коммутаторов / принтеров до серверов и услуг MS.

После прочтения бесчисленных постов на сайте и интенсивного поиска в гугле кажется, что все согласны с тем, что какой-то микс Nagios / Munin - это то, что нужно.

Что подводит меня к моему вопросу (ам):

А) Можно ли иметь локальный сервер Nagios, работающий в компании, и контролировать различные внешние сайты по глобальной сети? (Им не нужен локальный сервер Nagios на каждом сайте, так как большинство сайтов относительно небольшие (10-25 хостов), а количество сайтов довольно велико (75-100)).

Б) Если да, то как агенты свяжутся с бэкэндом Nagios? Через SSH? HTTP?

C) Помимо того, что это может быть восприимчиво к сбоям WAN-соединения, какими будут непосредственные недостатки такого решения?

Любая обратная связь приветствуется, и я заранее прошу прощения за любые заблуждения, поскольку я довольно новичок в отрасли.

Мониторинг через WAN возможен, но, как правило, не идеален. Это связано с тем, что, если канал WAN отключается или мигает, все проверки не пройдены, и вы не видите того, что происходит в удаленном местоположении. Вы также увеличили задержку, сделав ее менее полезной для измерений производительности LAN View. Тем не менее, если вы идете таким образом, вы, вероятно, захотите установить зависимости, чтобы вы не были переполнены предупреждениями, когда возникли проблемы с каналом WAN.

Наиболее распространенный способ, которым я видел связь между системой мониторинга и ее отслеживаемыми службами, - это создание VPN-туннеля между сайтами. Тогда общение ничем не отличается от локальной сети. Кроме того, Nagios часто основан на Pull (хотя это не обязательно). Таким образом, Nagios связывается со службами и серверами, которые он контролирует, а не наоборот.

Наконец, более идеальным решением является использование настройки распределенного мониторинга, при этом один из вариантов Nagios описан в http://nagios.sourceforge.net/docs/3_0/distributed.html .

Это отчасти зависит от того, что вы собираетесь контролировать по вину. По большей части, если вы выполняете только проверки пинга, проверки служб, проверки диска и т. Д. И придерживаетесь установленного по умолчанию nagios 5-минутного времени проверки, я не вижу, что это вызывает у вас проблему.

Опять же, в зависимости от того, что вы проверяете, зависит от того, что он собирается обсудить. Если вы проверяете хосты Windows, вы можете просто использовать запросы WMI и даже не нуждаться в агенте, работающем на коробке.

Это, безусловно, возможно, с помощью нескольких различных методов.

Если о «распределенной настройке» не может быть и речи, вам необходимо выполнить хотя бы одно из следующих действий:

1. Каждый ящик на удаленном сайте отправляет результаты проверки в Nagios (см. NSCA )
2. Ткни дыры в брандмауэрах, чтобы Nagios мог добраться до каждого ящика на каждом удаленном сайте
3. Назначьте одну ячейку на каждом сайте как своего рода «прокси-сервер Nagios»

Я бы предложил # 3, потому что это требует наименьшего количества дырок в брандмауэре, а также упрощает настройку. Это своего рода упрощенная версия распределенной установки, так как она не требует полного экземпляра Nagios на каждом сайте.

Для этого вы можете настроить NRPE (или использовать check_by_ssh ) и заставить этот «прокси» запускать все остальные проверки по отношению к другим хостам в сети. Это дает дополнительное преимущество данных о производительности, которые вы получаете обратно относительно прокси-сервера, поэтому не будет зависеть от задержки глобальной сети.

Кроме того, вы можете затем использовать родительские / дочерние настройки, чтобы сделать каждый хост на удаленном сайте дочерним по отношению к прокси-серверу, чтобы уменьшить количество ложноположительных уведомлений. Вы также можете сделать все сервисы зависимыми от сервиса прокси check_nrpe (или check_ssh). См. Документацию о доступности сети для получения дополнительной информации.

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