Я только начал работать в новой компании, и одно из моих первых заданий - поиск альтернатив их внутренней системе мониторинга.
Их текущее решение - это приложение .Net, которое проверяет различные устройства через глобальную сеть (поскольку это консалтинговая компания, предоставляющая круглосуточную поддержку / «обслуживание»). Диапазон устройств - от маршрутизаторов / коммутаторов / принтеров до серверов и служб MS.
После прочтения бесчисленного количества сообщений на сайте и обширного поиска в Google кажется, что единодушное мнение заключается в том, что какой-то микс Nagios / Munin - это правильный путь.
Это подводит меня к моему вопросу (ам):
A) Можно ли иметь сервер Nagios, работающий локально в компании, и контролировать различные внешние сайты через WAN? (Им не нужен локальный сервер 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 .
Это отчасти зависит от того, что вы собираетесь отслеживать через WAN. По большей части, если вы выполняете только проверки ping, проверки служб, дисков и т. Д. И придерживаетесь 5-минутного времени проверки nagios по умолчанию, я не вижу, что это вызывает у вас проблему.
Опять же, в зависимости от того, что вы проверяете, зависит от того, о чем будет говорить. Если вы проверяете хосты Windows, вы можете просто использовать запросы WMI и даже не нуждаться в запущенном на поле агенте.
Это, безусловно, возможно с помощью нескольких различных методов.
Если о «распределенной настройке» не может быть и речи, то вам необходимо выполнить хотя бы одно из следующего:
Я бы предложил №3, потому что он требует наименьшего количества дырок в брандмауэре, а также упрощает настройку. Это своего рода упрощенная версия распределенной установки, в которой не требуется полный экземпляр Nagios на каждом сайте.
Для этого вы можете настроить NRPE (или используйте check_by_ssh) и пусть этот «прокси» выполняет все другие проверки других хостов в сети. Это дает дополнительное преимущество в том, что данные о производительности, которые вы возвращаете, относятся к прокси-серверу, поэтому на них не влияет задержка WAN.
Кроме того, вы можете затем использовать родительские / дочерние настройки, чтобы сделать каждый хост на удаленном сайте дочерним по отношению к его прокси-серверу, чтобы уменьшить количество ложноположительных уведомлений. Вы также можете сделать все службы зависимыми от службы check_nrpe (или check_ssh) прокси. Увидеть доступность сети документы для получения дополнительной информации.
Независимо от того, какой метод вы используете, очень важно, чтобы вы настроить таймауты по умолчанию соответственно, чтобы учесть добавленную задержку при переходе по каналам WAN.