¿Es ideal Nagios "monitorizando" sobre WAN?

Recién comencé en una nueva compañía y una de mis primeras tareas es buscar alternativas a su sistema de monitoreo interno.

Su solución actual es una aplicación .Net que verifica varios dispositivos a través de la WAN (ya que son una empresa de consultoría de TI que brinda soporte / "mantenimiento" las 24 horas, los 7 días de la semana). Los dispositivos van desde enrutadores / conmutadores / impresoras hasta servidores y servicios de MS.

Después de leer innumerables publicaciones en el sitio y buscar en Google extensamente, parece que el consenso es que algún tipo de mezcla de Nagios / Munin es el camino a seguir.

Lo que me lleva a mi pregunta (s):

A) ¿Es posible tener un servidor Nagios ejecutándose localmente en la empresa y monitorear varios sitios externos a través de WAN? (No quieren un servidor Nagios local en cada sitio ya que la mayoría de los sitios son relativamente pequeños (10-25 hosts) y el número de sitios es bastante grande (75-100)).

B) Si es así, ¿cómo contactarían los agentes con el backend de Nagios? ¿A través de SSH? HTTP?

C) Aparte del hecho de que sería susceptible a fallas en el enlace WAN, ¿cuáles serían los inconvenientes inmediatos de tal solución?

Cualquier comentario es apreciado, y me disculpo de antemano por cualquier concepto erróneo, ya que soy bastante nuevo en la industria.

El monitoreo a través de una WAN es posible, pero generalmente no es ideal. Esto se debe a que si el enlace WAN se cae o falla, todas las comprobaciones fallarán y usted no podrá ver lo que sucede en la ubicación remota. También ha aumentado la latencia, lo que lo hace menos útil para las mediciones de rendimiento de LAN View. Dicho esto, si va por este camino, probablemente desee configurar dependencias para que no se inunde de alertas cuando el enlace WAN tiene problemas.

La forma más común en que he visto la comunicación entre un sistema de monitoreo y sus servicios monitoreados es tener un túnel VPN de sitio a sitio. Entonces la comunicación no es diferente de la red local. Además, Nagios a menudo se basa en Pull (aunque no tiene que serlo). Entonces Nagios contacta los servicios y servidores que monitorea, no al revés.

Por último, una solución más ideal es usar una configuración de monitoreo distribuido, con Nagios una opción se describe en http://nagios.sourceforge.net/docs/3_0/distributed.html .

Depende de lo que va a monitorear a través del wan. En su mayor parte, si solo está haciendo comprobaciones de ping, comprobaciones de servicios, comprobaciones de disco, etc. y se apega al tiempo de comprobación predeterminado de 5 minutos de nagios, no puedo ver que le cause un problema.

Nuevamente, dependiendo de lo que esté verificando dependerá de lo que va a hablar. Si está revisando los hosts de Windows, puede usar consultas WMI y ni siquiera necesita un agente ejecutándose en la caja.

Esto es ciertamente posible, a través de varios métodos diferentes.

Si la "configuración distribuida" está fuera de discusión, entonces debe hacer al menos uno de los siguientes:

1. Haga que cada cuadro en el sitio remoto envíe los resultados de la verificación a Nagios (consulte NSCA )
2. Haga agujeros en el cortafuegos para que Nagios pueda alcanzar cada caja en cada sitio remoto
3. Designe una sola casilla en cada sitio para que sea una especie de "proxy de Nagios"

Sugeriría el n. ° 3, porque requiere la menor perforación de firewall y también simplifica la configuración. Es una especie de versión reducida de la configuración distribuida, ya que no requiere una instancia completa de Nagios en cada sitio.

Para hacer esto, puede configurar NRPE (o usar check_by_ssh ) y hacer que este "proxy" ejecute todas las otras comprobaciones contra los otros hosts en la red. Esto tiene el beneficio adicional de que los datos de rendimiento que obtiene son relativos al proxy, por lo que no se verá afectado por el retraso de WAN.

Además, puede usar las configuraciones padre / hijo para hacer que cada host en el sitio remoto sea hijo de su proxy, para reducir las notificaciones de falsos positivos. También es posible que desee que todos los servicios dependan de un servicio check_nrpe (o check_ssh) del proxy. Consulte los documentos de accesibilidad de la red para obtener más información.

Independientemente del método que utilice, es muy importante que ajuste los tiempos de espera predeterminados de manera adecuada para tener en cuenta el retraso adicional de cruzar los enlaces WAN.