Hostgroups y plantillas.
Las plantillas le permiten definir clases para sus hosts y servicios, p. "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", cada una de las cuales 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, puede tener
host foo {
use windows-host,normal-priority-host
...
}
que obtendría la información de contacto (y escalaciones) para el equipo de Windows y las tasas de sondeo y los umbrales para un host "normal".
Los grupos de hosts le permiten agrupar todas las comprobaciones de un subconjunto de sus hosts. Tenga cosas como "baseline-linux-hosts" que verifiquen la carga, el espacio en disco, ssh capacidad y cualquier otra cosa que deba haber en cada host que supervise. Agregue grupos como "servidores https" con controles de conectividad HTTP, conectividad HTTPS y fechas de vencimiento del certificado SSL; "servidores de archivos" con controles de accesibilidad NFS y SMB y quizás controles de disco más agresivos; o "máquinas virtuales" con comprobaciones de si las herramientas de accesibilidad de la máquina virtual funcionan correctamente.
Coloque cada host y grupo de host en su propio archivo. Ese archivo debe contener primero la definición de host o grupo de host, seguida de las definiciones de los servicios que se aplican a él.
Si usa el cfg_dir directiva en su nagios.cfg archivo, 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/
- grupohost1.cfg
- grupohost2.cfg
- comandos.d/
Tiendo a crear un directorio para cada tipo de recurso (comandos, grupos de contacto, contactos, escaladas, grupos de host, hosts, grupos de servicio, períodos de tiempo) excepto para los servicios, que se agrupan con los hosts o grupos de host que los usan.
La estructura precisa puede variar según las necesidades de su organización. En un trabajo anterior, usé subdirectorios bajo hosts.d para cada sitio diferente. En mi trabajo actual, Puppet administra la mayoría de las definiciones de host de Nagios, por lo que hay un directorio para los hosts administrados por Puppet y otro separado para los hosts administrados manualmente.
Tenga en cuenta que lo anterior también divide los comandos en varios archivos, generalmente por protocolo. Así, el nrpe.cfg el archivo tendría los comandos check_nrpe y check_nrpe_1arg , mientras que http.cfg podría tener check_http , check_http_port , check_https , check_https_port y check_https_cert .
Normalmente no tengo una gran cantidad de plantillas, por lo que generalmente solo tengo un hosts.d/templates.cfg archivo y un services.d/templates.cfg expediente. Si los usa con mayor frecuencia, pueden ir a archivos con nombres apropiados en un templates.d directorio.
También me gusta tener un check_http_blindly comando, 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, los grupos de host y las plantillas. Cree grupos de host y asigne servicios a los grupos de host. Utilice grupos de servicios para dependencias, escaladas y agrupaciones lógicas en la interfaz de usuario web.
Si tiene grupos para todo, agregar un nuevo host es solo 3 o 4 líneas:nombre, dirección, plantilla (s) y (opcionalmente) grupos de host. Todo se puede modelar.
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, ahorra mucho tiempo.