Mejores prácticas del servidor Nagios?

Ejecuto un servidor mediano de Nagios. Monitorea aproximadamente 40 servidores con 180 servicios actualmente y solo crece día a día.

Migré de una antigua configuración de Nagios que se configuró de una manera muy esotérica, lo que me obligó a reconfigurar todo desde cero.

Ahora que el servidor se está ejecutando y funciona para la mayoría de lo que necesitamos , estoy buscando hacerlo un poco más escalable; actualmente cada host tiene su propio archivo /etc/nagios/hosts/y cada host tiene todos sus servicios en el mismo archivo. Obviamente, esto no es óptimo, pero tampoco ofusca toda mi configuración en cientos de archivos diferentes.

Entonces mi pregunta es esta: para cualquier administrador experimentado de Nagios, ¿cuál es la mejor manera de hacer uso de grupos de servidores / grupos de servicios sin complicar demasiado la configuración?

Grupos de host y plantillas.

Las plantillas le permiten definir clases para sus hosts y servicios, por ejemplo, "servicio normal", "servicio crítico", "host de baja prioridad". También sirven como una forma útil de dividir las responsabilidades si tiene varios equipos con diferentes responsabilidades, por lo que puede tener una plantilla de "host de Linux" y una plantilla de "host de Windows", donde cada uno define la información de contacto adecuada.

Puede usar varias plantillas en un solo recurso, por lo que puede componer plantillas ortogonales apropiadas. Por ejemplo, puedes tener

host foo {
    use windows-host,normal-priority-host
    ...
}

que extraería la información de contacto (y las escaladas) para el equipo de Windows y las tasas de votación y los umbrales para un host "normal".

Los grupos de host le permiten agrupar todas las comprobaciones de un subconjunto de sus hosts. Tenga cosas como "baseline-linux-hosts" que verifican la carga, el espacio en disco, la sshcapacidad y cualquier otra cosa que deba estar en cada host que supervise. Agregue grupos como "servidores https" con comprobaciones de conectividad HTTP, conectividad HTTPS y fechas de vencimiento de certificados SSL; "servidores de archivos" con comprobaciones de accesibilidad NFS y SMB y quizás comprobaciones de disco más agresivas; o "máquinas virtuales" con comprobaciones de si las herramientas de accesibilidad de VM se están ejecutando correctamente.

Coloque cada host y grupo de hosts en su propio archivo. Ese archivo debe contener primero la definición de host o grupo de hosts, seguida de las definiciones de los servicios que se le aplican.

Si usa la cfg_dirdirectiva en su nagios.cfgarchivo, Nagios buscará recursivamente a través de ese directorio. Haz uso de eso. Para una configuración de cfg_dir=/etc/nagios/conf.d, puede tener un árbol de directorios como el siguiente:

• /etc/nagios/conf.d/
  • comandos.d /
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

Tiendo a crear un directorio para cada tipo de recurso (comandos, grupos de contacto, contactos, escalamientos, grupos de hosts, hosts, grupos de servicios, períodos de tiempo), excepto los servicios, que se agrupan con los hosts o grupos de hosts que los usan.

La estructura precisa puede variar según las necesidades de su organización. En un trabajo anterior, utilicé subdirectorios hosts.dpara cada sitio diferente. En mi trabajo actual, la mayoría de las definiciones de host de Nagios están gestionadas por Puppet, por lo que hay un directorio para hosts gestionados por Puppet y otro por separado para hosts gestionados a mano.

Tenga en cuenta que lo anterior también divide los comandos en varios archivos, generalmente por protocolo. De este modo, la nrpe.cfgimagen tendrá los comandos check_nrpey check_nrpe_1arg, si bien http.cfgpodría tener check_http, check_http_port, check_https, check_https_port, y check_https_cert. ¹

Por lo general, no tengo una gran cantidad de plantillas, por lo que generalmente solo tengo un hosts.d/templates.cfgarchivo y un services.d/templates.cfgarchivo. Si los usa más, pueden ir a archivos con el nombre apropiado en un templates.ddirectorio.

¹ Me gusta tener también un check_http_blindlycomando, que es básicamente check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; devuelve OK incluso si obtiene un código de respuesta 403.

Haga un uso extensivo del servicio y los grupos de hosts, y cree plantillas. Cree grupos de host y asigne servicios a los grupos de host. Use grupos de servicio para dependencias, escalamientos y agrupación lógica en la interfaz de usuario web.

Si tiene grupos para todo, agregar un nuevo host es solo de 3 o 4 líneas: nombre, dirección, plantilla (s) y (opcionalmente) grupos de host. Todo puede ser tentado.

Asegúrese de leer los documentos sobre herencia , y también la página de trucos para ahorrar tiempo . La herencia múltiple puede ser complicada, pero cuando se usa correctamente es un gran ahorro de tiempo.

Estaba acostumbrado a configurar mis servidores nagios (antes de cambiar a Icinga) de esta manera, y no faltan actuaciones hasta que llegue a más de 500 servicios al menos con un servidor de 512 MB de memoria / 1 CPU. Los grupos de host y los grupos de servicio se pueden tratar completamente por separado, y recomendaría este enfoque ya que permite tener un archivo por servidor (servicios para este servidor definidos en este archivo) y luego, en el archivo por grupo de host / grupos de servicio. Esto es solo más comprensible / claro.

Si se encuentra con problemas de escalabilidad, es posible que desee echar un vistazo a nagios-nrpe-server, que realiza verificaciones en el lado del cliente y todo lo que hace su servidor de nagios es pedir resultados solamente; que ahorran el recurso del cheque. (Nagios inicia check_nrpe, se solicita al cliente, realiza comprobaciones localmente y responde a nagios). Teniendo en cuenta que todas las comprobaciones no se pueden tratar de esta manera (SNMP, por ejemplo).

Para terminar, e incluso si parece fuera de alcance con respecto a su pregunta, sugeriría cambiar a Icinga, que es mucho más escalable, sostenido por una comunidad más fuerte que realmente se preocupa por las implementaciones de nuevas funciones y el soporte al usuario. La configuración es la misma (mismos archivos de configuración, misma sintaxis).

Estoy usando este esquema:

• Hospedadores,
• grupos de host,
• servicios remotos,
• Servicios locales.

Cada entidad tiene su propio archivo. Además con las plantillas, siempre puede hacer que su configuración sea más fácil de leer. Por ejemplo, puede tener un promedio de carga, espacio en disco, memoria en cada host. Por lo tanto, es bastante fácil y práctico crear una plantilla genérica y usarla.

No puede complicar la configuración haciendo grupos. Como dice asciiphil, crea un archivo o puede definir los mismos grupos en algunos de los archivos existentes como (hosts.cfg o lo que sea), y crea este archivo o le dice a nagios que este archivo está activo (esto es si crea un nuevo campo, si no está activo), y esto está en el archivo nagios.cfg donde coloca la ruta del archivo recién creado. "cfg_file = / usr / local / nagios / etc / objects / NEW_FILE.cfg"

La otra cosa es simplemente hacer grupos dependiendo de su infraestructura. Si, por ejemplo, tengo Linux y Windows Server, haré dos grupos diferentes, uno para Linux y otro para Windows. Es lo mismo con los servicios. Dependiendo de cómo le gustaría configurar y ver cuándo monitorea en el monitor, cómo le gustaría verlos como grupos.

Y para el archivo o la parte cómo hacer un grupo es simple.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

Y en la configuración del host / o si usa una plantilla o si ya ha definido una plantilla o servicio de host y usa el uso, puede decirle automáticamente a todos los hosts / ventanas o hosts de Linux que sean miembros de un grupo de hosts definido que creó.