Una de las características de formato de Nagios "objeto de configuración es que puede crear definiciones de objetos que heredan las propiedades de las definiciones de otro objeto. Una explicación de cómo funciona el objeto de sucesiones se puede encontrar aquí Sugiero fuertemente que se familiarice con sucesiones objeto una vez que lea la documentación presentada a continuación, ya que hará que el trabajo de creación y mantenimiento de definiciones de objetos mucho más fácil de lo que debería ser. Además, leer sobre los trucos de objetos que ofrecen accesos directos para tareas de configuración de otro modo tedioso.
Al crear y / o editar archivos de configuración, tenga en cuenta lo siguiente:
Las lineas que empiezan por el símbolo '#' son tomadas como comentarios y no son procesadas.
Las directivas son sensibles a las mayúsculas y minúsculas
Los caracteres que aparecen después de un punto y coma (;) en los archivos de configuración, son tratados como comentarios y no son procesados.
Notas de retención
Es importante señalar que varias directivas en los equipos, servicio, y las definiciones de contacto puede no ser recogido por Nagios cuando los cambia los archivos de configuración.
Las directivas de objeto que pueden presentar este comportamiento están marcadas con el símbolo (*). La razón de este comportamiento se debe al hecho de que Nagios elige para honrar a los valores almacenados en el archivo de estado de retención o state retention file sobre los archivos encontrados el archivos de configuración, asumiendo que tiene el estado de retención o state retention habilitado en la configuración (program-wide basis) y el valor de la directiva sea cambiada durante la ejecución mediante comando externo o external command.
Una forma de solucionar este problema es des-habilitar la retención de información no-estado usando la directiva de no_retención_de_la_información_de_estado (retain_nonstatus_information) en el equipo, servicios, o las definiciones de contacto. Des habilitando de la directiva hará que Nagios tome los valores iniciales de estas directivas de los archivos de configuración, lugar desde donde el cual el archivo de retención se reinicia.
Archivos de configuración
Nota: Los ejemplos de archivos de configuración están instalados en el directorio /usr/local/nagios/etc/ cuando usa la guía de instalación rápida.
Tipos de objetos
Definiciones de equipos
Definición de grupos de equipos
Definición de servicios
Definición de grupos de servicios
Definición de contactos
Definición de grupos de contactos
Definición de periodos de tiempo
Definición de comandos
Definición de dependencia de servicios
Definición de escalado de servicios
Definición de dependencia de objetos
Definición de escalado de objetos
Definición de información de objetos extendida
Definición de información de servicios extendida
Definición de equipos
Descripción:
Una definición de equipo se utiliza para definir un servidor físico, estación de trabajo, dispositivos, etc que se encuentra en la red.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define | ||
host_name | host_name | |
alias | alias | |
display_name | display_name | |
address | address | |
parents | host_names | |
hostgroups | hostgroup_names | |
check_command | command_name | |
initial_state | [o,d,u] | |
max_check_attempts | # | |
check_interval | # | |
retry_interval | # | |
active_checks_enabled | [0/1] | |
passive_checks_enabled | [0/1] | |
check_period | timeperiod_name | |
obsess_over_host | [0/1] | |
check_freshness | [0/1] | |
freshness_threshold | # | |
event_handler | command_name | |
event_handler_enabled | [0/1] | |
low_flap_threshold | # | |
high_flap_threshold | # | |
flap_detection_enabled | [0/1] | |
flap_detection_options | [o,d,u] | |
process_perf_data | [0/1] | |
retain_status_information | [0/1] | |
retain_nonstatus_information | [0/1] | |
contacts | contacts | |
contact_groups | contact_groups | |
notification_interval | # | |
first_notification_delay | # | |
notification_period | timeperiod_name | |
notification_options | [d,u,r,f,s] | |
notifications_enabled | [0/1] | |
stalking_options | [o,d,u] | |
notes | note_string | |
notes_url | url | |
action_url | url | |
icon_image | image_file | |
icon_image_alt | alt_string | |
vrml_image | image_file | |
statusmap_image | image_file | |
2d_coords | x_coord,y_coord | |
3d_coords | x_coord,y_coord,z_coord | |
| } | |
define host{
host_name bogus-router
alias Bogus Router #1
address 192.168.1.254
parents server-backbone
check_command check-host-alive
check_interval 5
retry_interval 1
max_check_attempts 5
check_period 24x7
process_perf_data 0
retain_nonstatus_information 0
contact_groups router-admins
notification_interval 30
notification_period 24x7
notification_options d,u,r
}
Descripción de las directivas:
host_name:
Esta directiva se utiliza para definir un nombre corto para identificar el host. Se utiliza en las definiciones de grupo de equipos y definiciones de servicio para hacer referencia a este servidor en particular. Los equipos pueden disponer de servicios múltiples (que son monitoreados) asociadas con ellos. Cuando se utiliza correctamente, la macro debe de contener este nombre corteo.
alias:
Esta directiva es usada para definir un nombre largo o una descripcion usada para definir el equipo. Esto es útil para poder identificar mas fácilmente un host en particular. Cuando use esta propiedad, la macro $HOSTALIAS$ conectara con este alias / descripcion.
address:
Esta directiva es usada para definir la dirección del equipo. Normalmente se trata de una dirección IP, aunque podría ser cualquier cosa que desee. (Siempre y cuando se puede utilizar para comprobar el estado del equipo ). Puede utilizar un nombre de dominio completo para identificar la máquina en lugar de una dirección IP, pero si los servicios DNS no están en esto podría causar problemas. Cuando se utiliza correctamente, la macro $HOSTADDRESS$ contactará con esta dirección.
Nota: Si no se especifica una directiva de direcciones en una definición de equipo, el nombre del host se utiliza como su dirección. Una palabra de advertencia acerca de hacer esto. Si el servicio de DNS falla, la mayoría de los controles de su servicio producirán un error porque los plugins no pueden resolver el nombre de equipo.
display_name:
Esta directiva se utiliza para definir un nombre alternativo que se debe mostrar en la interfaz web para este equipo. Si no se especifica, el valor predeterminado es el valor especificado para la directiva host_name. Nota: Las versiones actuales de CGI no utilizan esta opción, a pesar de las futuras versiones de la interfaz web si lo hacen.
parents:
Esta directiva se utiliza para definir una lista separada por comas de nombres cortos de los "padres" anfitriones para este equipo en particular. Los equipos padres suelen ser routers, switches, firewalls, etc que se encuentran entre el equipo de motorización y un host remoto.
El Router, Switch, etc, más cercano a la máquina remota se considera como el equipo "padre". Lea el "Estado de Determinación y la accesibilidad de los Ejércitos de red" el documento se encuentra aquí para más información. Si este sistema es en el mismo segmento de red que el equipo de motorización (sin routers intermedios, etc) el equipo se considerá de la misma red y no tendrá un host padre. Deja este valor en blanco si el anfitrión no tiene host padre (es decir, es en el mismo segmento que el equipo de motorización Nagios). El orden en que se especifican los equipos los padres no tiene efecto en cómo las cosas son motorizadas
hostgroups:
Esta directiva se utiliza para definir los nombres cortos o hosts name(s) de los grupos de equipos y de los equipos que pertenecen a él. Una lista de grupos deben de separarse con comas. Esta directiva puede ser usada como alternativa (o como adición) a la directiva de miembros (members directive) en las definiciones de grupos de equipos o hostgroup .
check_command:
Las directivas es usada para especificar nombres cortos o short name en el comando (command) o que puede ser chequeado para saber si el equipo esta activo o no.
Típicamente este comando intentaría un ping contra el equipo para saber si esta levantado "alive". El comando debe de devolver el estado de o Nagios asumirá que el equipo esta parado. Si usted deja el argumento en blando, el equipo no será chequeado activamente.
Por lo tanto, Nagios asumirá que el equipo esta levantado (que pueden aparecer como miembros de un "pendiente " en la interfaz web). Esto es útil si está supervisando impresoras u otros dispositivos que con frecuencia se apaga. La cantidad máxima de tiempo que el comando se puede ejecutar la notificación está controlado por la opción host_check_timeout .
initial_state:
De forma predeterminada Nagios asumirá que todos los hosts se encuentran en los estados arriba cuando se inicia. Se puede reemplazar el estado inicial de un host mediante la presente Directiva. Las opciones válidas son: o = UP, DOWN = d, y u = INALCANZABLE.
max_check_attempts:
Esta directiva se utiliza para definir el número de veces que Nagios volverá a intentar el comando de verificación de acogida si se devuelve cualquier estado que no sea un estado en Aceptar. Al establecer este valor en 1 hará que Nagios para generar una alerta, sin volver a intentar el control de acogida. Nota: Si no quieres comprobar el estado de la máquina, usted todavía debe establecer en un valor mínimo de 1. Para omitir la comprobación de acogida, acaba de salir de la opción check_command en blanco.
check_interval:
Esta directiva se utiliza para definir el número de "unidades de tiempo" entre los controles regulares del ejército. A menos que haya cambiado la directiva interval_length del valor predeterminado de 60, este número significa minutos. Más información sobre este valor se puede encontrar en la documentación en la programación de la verificación o check scheduling.
retry_interval:
Esta directiva se utiliza para definir el número de "unidades de tiempo" para esperar antes de programar una nueva visita de los equipos. Las máquinas son re programados en el intervalo de re intento cuando se han cambiado a un estado no-UP. Una vez que el equipo ha alcanzado el número máximo de intentos o max_check_attempts veces sin un cambio en su estado, volverá a ser programado en su "normal " según lo definido por el valor check_interval. A menos que haya cambiado la directiva interval_length interval_length del valor predeterminado de 60, este número significa minutos. Más información sobre este valor se puede encontrar en la programación de la verificación o check scheduling.
active_checks_enabled *:
Esta directiva se utiliza para determinar si los controles activos (ya sea regular o bajo demanda) de este servidor están habilitadas. Valores: 0 = desactivar los controles host activos, 1 = activar los controles activos de motorización (por defecto). .
passive_checks_enabled *:
Esta directiva se utiliza para determinar si los controles pasivos están habilitadas para este equipo. Valores: 0 = des-habilitar las comprobaciones de acogida pasiva, 1 = activar los controles pasivos de motorización (por defecto).
check_period:
Esta directiva se utiliza para especificar el nombre corto del periodo de tiempo o time period durante el cual los controles activos de esta máquina se pueden hacer.
obsess_over_host *:
Esta directiva determina si los chequeos se realizaran o no mientras el equipo esta en modo “obsesionado” (obsessed) usando el comando ochp_command.
check_freshness *:
Esta directiva determina si los chequeos se realizan o no si el refresco de chequeo o reshness checks está activado en este equipo. Valores: 0 = controles frescura desactivados, 1 = activar los controles frescura (por defecto).
freshness_threshold:
Esta directiva se utiliza para especificar el umbral de frescura (en segundos) para este equipo. Si se establece esta directiva por un valor de 0, Nagios determinará un umbral de frescura a usar automáticamente.
event_handler:
Esta directiva es usada para especificar el nombre corto de un command que puede correr cuando hay un cambio de estado en el equipo detectado (por ejemplo cuando un equipo esta in-disponible o se recupera.). Lea la documentación en el controlador de eventos o event handlers para mas detalles acerca como escribir procesos automáticos (scripts) para el controlador de eventos.
El tiempo máximo que un comando de monitorización de eventos puede ser ejecutado, viene definido en la opción tiempo de espera en control de eventos o event_handler_timeout
event_handler_enabled *:
Esta directiva se utiliza para determinar si el controlador de eventos para este equipo está activada. Valores: 0 = desactivar el controlador de eventos de acogida, 1 = activar controlador de anfitrión del evento.
low_flap_threshold:
Esta directiva se utiliza para especificar el umbral de cambio de estado de baja utilizada en la detección del “flapeo” (se cae y se levanta o viceversa) para este equipo. Más información sobre la detección de este flapeo se puede encontrar aquí. Si se establece esta directiva por un valor de 0, el valor de todo el programa especificado por la directiva se utilizará low_host_flap_threshold.
high_flap_threshold:
Esta directiva se utiliza para especificar el umbral de cambio de estado de alta utilizados en la detección de “flapeo” (se cae y se levanta o viceversa) para este equipo. Más información sobre la detección de este flapeo se puede encontrar aquí . Si se establece esta directiva por un valor de 0, el valor de todo el programa especificado por la directiva se utilizará high_host_flap_threshold.
flap_detection_enabled *:
Esta directiva se utiliza para determinar si la detección de un flapeo (se cae y se levanta o viceversa) está habilitada para esta máquina. Más información sobre la detección de este flapeo se puede encontrar aquí (here). Valores: 0 = deshabilita la detección de flapeo, 1 = habilitar la detección de flapeo.
flap_detection_options:
Esta directiva se utiliza para determinar si la detección de flapeo lógico está habilitada para esta máquina. Las opciones son la combinación de los siguientes valores. 0= Predicción de estado desactivado, 1 = estado parado la predicción de flapeo y u= estado inalcanzable.
process_perf_data *:
Esta directiva se utiliza para determinar si el tratamiento de los datos de rendimiento está habilitada para esta máquina. Valores: 0 = des-habilitar el rendimiento de procesamiento de datos, 1 = activar el rendimiento del procesamiento de datos.
retain_status_information:
Esta directiva se utiliza para determinar cuando si y cuando no la información relacionada con el estado sobre el host se mantiene en el programa cuando se reinicia. Esto sólo es útil si ha habilitado la retención de estado usando la directiva retención de la información de estado o retain_state_information. Valor: 0 = desactivar la retención de información de estado, 1 = habilitar la retención de la información de estado.
retain_nonstatus_information:
Esta directiva se utiliza para determinar si la información de estado sobre el equipo se mantiene después del reinicio el programa. Esto sólo es útil si ha habilitado la directiva de retención de estado o retain_state_information . El valor Value: 0 = des-habilitado la retención de información de estado,Value: 1 = habilitar la retención de la información de estado.
contacts:
Esta es una lista de los nombres cortos de los contactos que debe ser notificado cada vez que hay problemas (o recuperación) con esta máquina. Contactos múltiples deben estar separados por comas. Es útil si desea que las notificaciones se envíen a unas pocas personas y no desea configurar los contact groups . Debe especificar al menos un contacto o un grupo de contacto en cada definición de equipo.
contact_groups:
Esto es una lista de nombres cortos de los contact groups a los cuales se notificará en caso de incidentes o recuperaciones de un equipo. Usted debe de especificar al menos un contacto o grupo de contactos en cada definición de equipo.
notification_interval:
Esta directiva identifica cuantas “unidades de tiempo” o "time units" se debe de esperar para volver a notificar a los contactos acerca la caída de un dispositivo que aun no es alcanzable. A menos que usted haya cambiado la directiva de longitud del intervalo (interval_length) de su valor por defecto de 60, este numero se indica en minutos. Si cambia el valor a 0, Nagios no volverá a notificar este evento a los contactos y solo una única notificación será enviada a los contactos.
first_notification_delay:
Esta identifica nos permite definir las “unidades de tiempo” o "time units" de espera entre de enviar la notificación de un problema cuando un dispositivo esta no disponible. A menos que haya cambiado la directiva longitud del intervalo (interval_length) de su valor por defecto que es 60, expresado en minutos, Nagios enviará inmediatamente las notificaciones si su valor es 0.
notification_period:
Esta directiva es usada para especificar el nombre corto de un periodo de tiempo (time period) durante el cual las notificaciones o eventos de este equipo puede ser enviado a los contactos. Si el equipo pierde conexión o se para o es inalcanzable, y se recupera entre de que se acabe este tiempo definido, no se enviará ninguna notificación
notification_options:
Esta directiva se utiliza para determinar si las notificaciones para el equipo debe ser enviado. Las opciones válidas son una combinación de uno o más de los siguientes: d = enviar notificaciones sobre el estado Abajo, u = enviar notificaciones en un estado inalcanzable, r = enviar notificaciones sobre las recuperaciones (estado OK), f = enviar notificaciones cuando el equipo comienza y deja de flapear (flapping), y s = enviar notificaciones cuando se programa comienza y termina el tiempo de inactividad scheduled downtime . Si se especifica n (no) como una opción, ningún evento del equipo será enviada. Si no se especifica ninguna de las opciones de notificación, Nagios a suponer que usted desea que las notificaciones se enviarán a todos los estados posibles. Ejemplo: Si se especifica d, r en este campo, sólo las notificaciones serán enviadas cuando el host se cae y cuando se recupera de un estado ABAJO.
notifications_enabled *:
Esta directiva se utiliza para determinar si las notificaciones para este equipo están habilitadas. Valores: 0 = des-habilitar las notificaciones del equipo, 1 = habilitar las notificaciones del equipo.
stalking_options:
Esta directiva determina que estados del equipo "acecho o "stalking"" está habilitados. Las opciones válidas son una combinación de uno o más de los siguientes: o = stalk en estados UP , d = stalk a los estados caído, y u = tallo a los Estados inalcanzable. Más información sobre el estado de acecho ( stalking) se puede encontrar aquí here .
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el host. Si se especifica una nota aquí, podrás ver las que en la información ampliada información ampliada (extended information) CGI (cuando está viendo la información sobre el host).
notes_url:
Esta variable se utiliza para definir una dirección URL opcional que puede utilizarse para proporcionar más información acerca del host. Si se especifica una dirección URL, podrás ver un icono de carpeta roja en el CGI (cuando está viendo la información del host) que enlaza con la dirección que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será el mismo que lo que se utiliza para acceder a los CGIs (es decir, / cgi-bin/nagios /). Esto puede ser muy útil si quieres hacer que la información detallada en el host, los métodos de contacto de emergencia, etc a disposición del personal de apoyo.
action_url:
Esta directiva se utiliza para definir una dirección URL opcional que se puede utilizar para ofrecer más acciones a realizar en el host. Si se especifica una dirección URL, podrás ver un rojo "símbolo de" icono de la CGI (cuando está viendo la información del host) que enlaza con la dirección que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será el mismo que lo que se utiliza para acceder a los CGIs (es decir, / cgi-bin/nagios /).
icon_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG o JPG que deben estar asociados con este equipo. Esta imagen se mostrará en los diferentes lugares en el CGI. La imagen se verá mejor si se trata de 40x40 píxeles de tamaño. Imágenes de los ejércitos se supone que en los logos / subdirectorio en su directorio de imágenes de HTML (es decir, /usr/local/nagios/share/images/logos).
icon_image_alt:
Esta variable se utiliza para definir una cadena opcional que se utiliza en la etiqueta ALT de la imagen especificada por el argumento
vrml_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG o JPG que deben estar asociados con este dispositivo. Esta imagen se utiliza como mapa de textura para el host especificado en el CGI statuswrl. A diferencia de la imagen se utiliza para la variable
statusmap_image:
Esta variable se utiliza para definir el nombre de una imagen que debe estar asociado con esta máquina en el CGI statusmap. Puede especificar una imagen JPEG, PNG y GIF si quieres, aunque me gustaría sugerir fuertemente con una imagen en formato GD2, como otros formatos de imagen resultará en una gran cantidad de tiempo de CPU desperdiciado cuando la imagen statusmap se genera. GD2 imágenes pueden crearse a partir de imágenes PNG con la utilidad pngtogd2 suministrado con la biblioteca gd library de Thomas Boutell. Las imágenes GD2 se debe crear en formato sin comprimir con el fin de minimizar la carga de la CPU cuando el statusmap CGI está generando el mapa de red. La imagen se verá mejor si se trata de 40x40 píxeles de tamaño. Puede dejar estas opciones en blanco si no está utilizando el CGI statusmap. Las imágenes de los equipos se supone que esta en el subdirectorio logos/ de imágenes HTML (es decir, /usr/local/nagios/share/images/logos).
2d_coords:
Esta variable se utiliza para definir las coordenadas a utilizar al dibujar los equipos en el CGI de mapa de estado (statusmap) . Las coordenadas se dan en números enteros positivos, ya que corresponden a los píxeles de física en la imagen generada. El origen de dibujo (0,0) se encuentra en la esquina superior izquierda de la imagen y se extiende en la dirección positiva x (a la derecha) en la parte superior de la imagen y en la dirección y positiva (hacia abajo) a lo largo de la mano izquierda lado de la imagen. Como referencia, el tamaño de los iconos elaborado suele ser de unos 40x40 píxeles (el texto toma un poco más de espacio). Las coordenadas que especifique aquí son para la esquina superior izquierda del icono de equipo que se dibuja. Nota: No te preocupes por lo que el máximo de coordenadas X e Y que se pueden utilizar . El CGI calculará automáticamente las dimensiones máximas de la imagen se crea sobre la base de la mayor coordenadas x e y que especifique.
3d_coords:
Esta variable se utiliza para definir las coordenadas a utilizar en la elaboración de acogida en el CGI statuswrl . Las coordenadas pueden ser números reales positivos o negativos. El origen de dibujo (0.0,0.0,0.0). Como referencia, el tamaño de los cubos de acogida establecido es de 0,5 unidades en cada lado (el texto toma un poco más de espacio). Las coordenadas que especifique aquí se utilizan como el centro del cubo del equipo.
Definición de grupos de equipos
Descripción:
Una definición de la grupo de equipos se utiliza para agrupar una o más hosts juntos para simplificar la configuración con trucos de objetos (object tricks) o propósitos de la exhibición en el CGIs.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define hostgroup{
hostgroup_name
hostgroup_name
alias
alias
members
hosts
hostgroup_members
hostgroups
notes
note_string
notes_url
url
action_url
url
}
Definición de ejemplo:
define hostgroup{
hostgroup_name novell-servers
alias Novell Servers
members netware1,netware2,netware3,netware4
}
Descripción de las directivas:
hostgroup_name:
Esta directiva se utiliza para definir un nombre corto para identificar el grupo de equipos.
alias:
Esta directiva se utiliza para definir un nombre más largo o una descripción para identificar el grupo de equipos. Se proporciona a fin de permitir a identificar más fácilmente a un grupo determinado de equipos.
members:
Esta es una lista de los nombres cortos de los equipos (hosts) que se deben incluir en este grupo. Varios nombres de equipo deben separarse con comas. Esta directiva puede ser usada como una alternativa (o además) a la directiva hostgroups en las definiciones de equipos (host definitions).
hostgroup_members:
Esta directiva opcional puede ser usada para incluir a los equipos de otros sub grupos de en este grupo de equipos. Especificar una lista de los nombres cortos de los grupos de equipos , cuyos miembros deben ser incluidos en este grupo, separados por comas.
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el host. Si se especifica una nota aquí, podrás ver el que en la información ampliada (extended information) del CGI (cuando está viendo la información sobre el equipo).
notes_url:
Esta variable se utiliza para definir una URL opcional que se puede utilizar para proporcionar más información sobre el grupo de acogida. Si se especifica una dirección URL, usted verá un icono de carpeta roja en el CGI (cuando está viendo la información hostgroup) que enlaza con la URL que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios/). Esto puede ser muy útil si desea hacer que la información detallada sobre el grupo de equipos, los métodos de contacto de emergencia, etc a disposición del personal de apoyo.
action_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para ofrecer más acciones a realizar en el grupo de acogida. Si se especifica una dirección URL, se vea una luz roja "splat" icono de la CGI (cuando está viendo la información hostgroup) que enlaza con la URL que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios/).
Definición del Servicio
Descripción:
Una definición de servicio se utiliza para identificar un "servicio" que se ejecuta en un equipo. El término "servicio" se utiliza de manera muy informal. Puede significar un servicio real que se ejecuta en el host (POP, SMTP, HTTP, etc) o algún otro tipo de métrica asociada con el huésped (respuesta a un ping, el número de usuarios conectados, espacio libre en disco, etc) . Los diferentes argumentos para una definición de servicio se describen a continuación.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define service{
host_name
host_name
hostgroup_name
hostgroup_name
service_description
service_description
display_name
display_name
servicegroups
servicegroup_names
is_volatile
[0/1]
check_command
command_name
initial_state
[o,w,u,c]
max_check_attempts
#
check_interval
#
retry_interval
#
active_checks_enabled
[0/1]
passive_checks_enabled
[0/1]
check_period
timeperiod_name
obsess_over_service
[0/1]
check_freshness
[0/1]
freshness_threshold
#
event_handler
command_name
event_handler_enabled
[0/1]
low_flap_threshold
#
high_flap_threshold
#
flap_detection_enabled
[0/1]
flap_detection_options
[o,w,c,u]
process_perf_data
[0/1]
retain_status_information
[0/1]
retain_nonstatus_information
[0/1]
notification_interval
#
first_notification_delay
#
notification_period
timeperiod_name
notification_options
[w,u,c,r,f,s]
notifications_enabled
[0/1]
contacts
contacts
contact_groups
contact_groups
stalking_options
[o,w,u,c]
notes
note_string
notes_url
url
action_url
url
icon_image
image_file
icon_image_alt
alt_string
}
Definición de ejemplo:
define service{
host_name linux-server
service_description check-disk-sda1
check_command check-disk!/dev/sda1
max_check_attempts 5
check_interval 5
retry_interval 3
check_period 24x7
notification_interval 30
notification_period 24x7
notification_options w,c,r
contact_groups linux-admins
}
Descripción de las directivas:
host_name:
Esta directiva es usada para especificar el nombre corto del equipo (host(s)) en el cual “corre” o está asociado el servicio. Se pueden crear varios equipos, separandolos con comas.
hostgroup_name:
Esta directiva se utiliza para especificar el nombre(s) corto(s) del nombre de grupo (hostgroup(s)) sobre el cual el servicio "funciona" o está asociado. Múltiples grupos deben estar separados por comas. El hostgroup_name se puede utilizar en lugar de, o además de, la directiva host_name.
service_description;:
Esta directiva se utiliza para definir la descripción del servicio, que puede contener espacios, guiones y dos puntos (puntos y comas, apostrofes, comillas y se debe evitar). Dos servicios relacionados con la misma máquina no pueden tener la misma descripción. Los servicios se identifican con sus host_name y directivas service_description.
display_name:
Esta directiva se utiliza para definir un nombre alternativo que se debe mostrar en la interfaz web de este servicio. Si no se especifica, el valor especificado por defecto viene especificado en la directiva service_description. Nota: Los CGIs actuales no utilizan esta opción, a pesar de las futuras versiones de la interfaz web.
servicegroups:
Esta directiva se utiliza para identificar el nombre(s) corto(s) (short name(s)) del grupo de servicio (servicegroup(s)) al cual pertenece. Múltiples grupos de servicio deben estar separados por comas. Esta directiva puede ser usada como una alternativa al uso de los miembros en las definiciones de la directiva de grupos de servicios o (servicegroup) .
is_volatile:
Esta directiva se utiliza para indicar si el servicio es "volátil". Los servicios normalmente no son volátiles. Más información sobre el servicio volátil y en qué se diferencian de los servicios normales se puede encontrar aquí. Valor: 0 = servicio no es volátil, un servicio = es volátil.
check_command:
Esta directiva se utiliza para especificar el nombre abreviado o short name del comando que Nagios ejecutará para comprobar el estado del servicio. La cantidad máxima de tiempo que el comando de servicio de comprobación puede se controlado por la opción service_check_timeout
initial_state:
De forma predeterminada Nagios asumirá que todos los servicios se encuentran en estado correcto o OK cuando se inicia. Se puede reemplazar el estado inicial de un servicio mediante el uso de esta directiva. Las opciones válidas son: o = OK, w = ADVERTENCIA, u = DESCONOCIDO, y c = CRÍTICO.
max_check_attempts:
Esta directiva se utiliza para definir el número de veces que Nagios volverá a intentar el comando de verificación de servicios si se devuelve cualquier estado que no sea un estado correcto o levantado. Al establecer este valor en 1 hará que Nagios genere una alerta, sin volver a intentar el chequeo de servicio de nuevo.
check_interval:
Esta directiva se utiliza para definir el número de "unidades de tiempo" para esperar antes de programar la próxima verificación del servicio "regular ". Los chequeos "Regular" son los que se producen cuando el servicio se encuentra en un estado bien o cuando el servicio se encuentra en un estado no bien, pero ya se ha alcanzado de nuevo el numero de re-intentos o max_check_attempts . A menos que haya cambiado la directiva interval_length del valor predeterminado de 60, este número significa minutos. Más información sobre este valor se puede encontrar en la documentación de la programación de verificación o check scheduling.
retry_interval:
Esta directiva se utiliza para definir el número de "unidades de tiempo" para esperar antes de programar una nueva revisión del servicio. Los servicios son re programados en el intervalo de re intento cuando se han cambiado a un estado no-OK. Una vez que el servicio ha sido revisado max_check_attempts veces sin un cambio en su estado, volverá a ser programado en su "normal " según lo definido por el valor check_interval. A menos que haya cambiado la directiva interval_length del valor predeterminado de 60, este número significa minutos. Más información sobre este valor se puede encontrar en la documentación de la programación de verificación (check scheduling).
active_checks_enabled *:
Esta directiva se utiliza para determinar si los controles activos de este servicio están habilitadas. Valores: 0 = des-habilitar las comprobaciones de servicio activo, 1 = activar los controles de servicio activo (por defecto). .
passive_checks_enabled *:
Esta directiva se utiliza para determinar si los controles pasivos de este servicio están habilitadas. Valores: 0 = des-habilitar las comprobaciones de servicio pasivo, 1 = activar los controles pasivos de servicios (por defecto).
check_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo o time period durante el cual los controles activos de este servicio se puede hacer.
obsess_over_service *:
Esta directiva determina si los controles para el servicio será "obsesionado" con respecto al uso de la ocsp_command. .
check_freshness *:
Esta directiva se utiliza para determinar si los controles frescura o freshness checks están habilitadas para este servicio. Valores: 0 = controles frescura desactivar, 1 = activar los controles frescura (por defecto).
freshness_threshold:
Esta directiva se utiliza para especificar el umbral de frescura (en segundos) para este servicio. Si se establece esta directiva por un valor de 0, Nagios determinará un umbral de frescura a usar automáticamente.
event_handler:
Esta directiva se utiliza para especificar el nombre abreviado o short name del comando que debe ejecutarse cada vez que un cambio en el estado (flapeo) del servicio se detecta (es decir, cada vez que se cae o se recupera). Lea la documentación sobre los controladores de eventos (event handlers) para obtener una explicación más detallada de cómo escribir guiones para la gestión de eventos. La cantidad máxima de tiempo que el comando de controlador de eventos se puede ejecutar es controlado por la opción event_handler_timeout.
event_handler_enabled *:
Esta directiva se utiliza para determinar si el controlador de eventos para este servicio está habilitado. Valores: 0 = desactivar el controlador de evento de servicio, 1 = activar controlador de servicio de sucesos.
low_flap_threshold:
Esta directiva se utiliza para especificar el umbral de cambio de estado de servicio. Más información sobre la detección de la aleta se puede encontrar aquí. Si se establece esta directiva por un valor de 0, el valor de todo el programa especificado por la directiva ow_service_flap_threshold se utilizará.
high_flap_threshold:
Esta directiva se utiliza para especificar el umbral de cambio de estado de alta utilizados en la detección de la cambio de este servicio. Más información sobre la detección cambio se puede encontrar aquí. Si se establece esta directiva a un valor de 0, el valor de todo el programa especificado por la directiva high_service_flap_threshold se utilizará.
flap_detection_enabled *:
Esta directiva se utiliza para determinar si la detección del cambio está habilitado para este servicio. Más información sobre la detección del cambio se puede encontrar aquí. Valores: 0 = des-habilitar la detección del cambio de servicio(flapeo), 1 = habilitar la detección de servicio de la flapping.
flap_detection_options:
Esta directiva se utiliza para determinar qué estados de servicio en la lógica de detección de alternancia de servicio (flapeo) o flap detection logic se utiliza para este servicio. Las opciones válidas son una combinación de uno o más de los siguientes: o = estados bien, w = ADVERTENCIA estados, c = estados críticos, u = estados DESCONOCIDO.
process_perf_data *:
Esta directiva se utiliza para determinar si el tratamiento de los datos de rendimiento está habilitado para este servicio. Valores: 0 = des-habilitar el rendimiento de procesamiento de datos, 1 = activar el rendimiento del procesamiento de datos.
retain_status_information:
Esta directiva se utiliza para determinar la información o no relacionados con el estado sobre el servicio se mantiene a través del programa cuando este se reinicia. Esto sólo es útil si ha habilitado la retención de estado usando la directiva retain_state_information. Valor: 0 = desactivar la retención de información de estado, 1 = habilitar la retención de la información de estado.
retain_nonstatus_information:
Esta directiva se utiliza para determinar si la información de estado sobre el servicio se mantiene cuando el programa se reinicia. Esto sólo es útil si ha habilitado la retención de estado usando la directiva retain_state_information. Valor: 0 = desactivar la retención de información no-estado, 1 = habilitar la retención no la información de estado.
notification_interval:
Esta directiva se utiliza para definir el número de "unidades de tiempo" para esperar antes de volver a notificar a un contacto que este servicio se encuentra todavía en un estado no-OK. A menos que haya cambiado la directiva interval_length del valor predeterminado de 60, este número significa minutos. Si establece este valor a 0, Nagios no volverá a notificar a los contactos sobre los problemas de este servicio - sólo un a notificación del problema será enviado.
first_notification_delay:
Esta directiva se utiliza para definir el número de "unidades de tiempo" para esperar antes de enviar la notificación primer problema cuando este servicio entra en un estado no-OK. A menos que haya cambiado la directiva interval_length , el valor predeterminado de 60, este número significa minutos. Si establece este valor a 0, Nagios comenzará a enviar las notificaciones de inmediato
notification_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo o time period durante el cual las notificaciones de eventos para este servicio se pueden enviar a los contactos. Ninguna notificación de servicio se enviarán durante el tiempo que no está cubierto por este valor de periodo.
notification_options:
Esta directiva se utiliza para determinar si las notificaciones por el servicio debe ser enviado. Las opciones válidas son una combinación de uno o más de los siguientes: w = enviar notificaciones en un estado de advertencia, u = enviar notificaciones en un estado desconocido, c = enviar notificaciones en un estado crítico, r = enviar notificaciones sobre las recuperaciones (estado OK) , f = enviar notificaciones cuando se inicia el servicio y deja de batir, y s = enviar notificaciones cuando se programa comienza y termina el tiempo de inactividad (scheduled downtime). Si se especifica n (no) como una opción, ninguna notificación se enviará. Si no se especifica ninguna de las opciones de notificación, Nagios a suponer que usted desea que las notificaciones se enviarán a todos los estados posibles. Ejemplo: Si se especifica w, r en este campo, las notificaciones sólo se enviarán cuando el servicio entra en un estado de advertencia y cuando se recupera de un estado de advertencia.
notifications_enabled *:
Esta directiva se utiliza para determinar si las notificaciones para este servicio están habilitados. Valores: 0 = desactivar el servicio de notificaciones, 1 = activar las notificaciones de servicio.
contacts:
Esta es una lista de los nombres cortos de los contactos que debe ser notificados cada vez que hay problemas (o recuperación) con este servicio. Varios contactos deben estar separadas por comas. Útil si desea que las notificaciones se dirige sólo a unas cuantas personas y no desea configurar grupos de contacto. Debe especificar al menos un contacto o un grupo de contacto en cada definición de servicio.
contact_groups:
Esta es una lista de los nombres cortos de los grupos de contacto o contact groups que debe ser notificado cada vez que hay problemas (o recuperación) con este servicio. Varios grupos de contacto en caso de estar separados por comas. Debe especificar al menos un contacto o un grupo de contacto en cada definición de servicio.
stalking_options:
Esta directiva determina que servicios están en estado "stalking" están habilitado. Las opciones válidas son una combinación de uno o más de los siguientes: o = stalking en estados bien, w = stalking a los Estados ADVERTENCIA, u = stalking a los Estados DESCONOCIDO, y c = stalking en estados críticos. Más información sobre el stalking oso del Estado se puede encontrar aquí.
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el servicio. Si se especifica una nota aquí, podrás ver el que en el CGI la información ampliada o extended information (cuando está viendo la información sobre el servicio especificado).
notes_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para proporcionar más información sobre el servicio. Si se especifica una dirección URL, usted verá un icono de carpeta roja en el CGI (si es que ves la información de servicio) que enlaza con la URL que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios/). Esto puede ser muy útil si desea hacer que la información detallada sobre el servicio, los métodos de contacto de emergencia, etc a disposición del personal de apoyo.
action_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para ofrecer más acciones a realizar en el servicio. Si se especifica una dirección URL, se vea una luz roja "splat" icono de la CGI (si es que ves la información de servicio) que enlaza con la URL que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir /cgi-bin/nagios/).
icon_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG, JPG o que deben ser asociados con este servicio. Esta imagen se mostrará en el estado (status) y el CGIs con información extendida o extended information. La imagen se verá mejor si es de 40x40 píxeles. Imágenes de los servicios se supone que están en los logotipos / subdirectorio en el directorio de imágenes en HTML (es decir, //usr/local/nagios/share/images/logos).
icon_image_alt:
Esta variable se utiliza para definir una cadena opcional que se utiliza en la etiqueta ALT de la imagen especificada por el argumento
Service Group Definition
Descripción:
El grupo de servicio se utiliza para agrupar una o más servicios en conjunto para simplificar la configuración con trucos objeto o object tricks o propósitos de la exhibición en el CGIs.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define servicegroup{
servicegroup_name
servicegroup_name
alias
alias
members
services
servicegroup_members
servicegroups
notes
note_string
notes_url
url
action_url
url
}
Definición de ejemplo:
define servicegroup{
servicegroup_name dbservices
alias Database Services
members ms1,SQL Server,ms1,SQL Server Agent,ms1,SQL DTC
}
Descripción de las directivas:
servicegroup_name:
Esta directiva es usada para definir el nombre de un grupo de servicios.
alias:
Esta directiva se utiliza para definir un nombre más largo o una descripción para identificar el grupo de servicio. Se proporciona a fin de permitir a identificar más fácilmente a un grupo determinado servicio.
members:
Esta es una lista de las descripciones de los servicios (y los nombres de sus equipos correspondiente) que deben incluirse en este grupo. Los nombres de host y el servicio deben estar separadas por comas. Esta directiva se puede utilizar como una alternativa a la directiva servicegroups en las definiciones de servicio (service definitions ). El formato de la Directiva miembro es el siguiente (tenga en cuenta que un nombre de host debe preceder a un nombre de servicio en la descripción):
members=
servicegroup_members:
Esta directiva opcional puede ser usado para incluir los servicios de otros “sub” grupos de servicio a este grupo de servicio. Especifica una lista delimitada por comas de nombres cortos de los grupos de servicio de otros, cuyos miembros deben ser incluidos en este grupo.
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el grupo de servicio. Si se especifica una nota aquí, podrás ver las que en la información ampliada extended information CGI (cuando está viendo la información sobre el grupo de servicio especificado).
notes_url:
Esta directiva se utiliza para definir una dirección URL opcional que puede utilizarse para proporcionar más información sobre el grupo de servicio. Si se especifica una dirección URL, podrás ver un icono de carpeta roja en el CGI (cuando está viendo la información de servicio del grupo) que se vincula a la dirección que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será el mismo que lo que se utiliza para acceder a los CGIs (es decir, /cgi-bin/nagios/). Esto puede ser muy útil si quieres hacer que la información detallada sobre el grupo de servicio, los métodos de contacto de emergencia, etc a disposición del personal de apoyo.
action_url:
Esta directiva se utiliza para definir una dirección URL opcional que se puede utilizar para ofrecer más acciones a realizar en el grupo de servicio. Si se especifica una dirección URL, podrás ver un rojo "símbolo de" icono de la CGI (cuando está viendo la información de servicio del grupo) que se vincula a la dirección que especifique aquí. Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será el mismo que lo que se utiliza para acceder a los CGIs (es decir, /cgi-bin/nagios/).
Definición de contacto
Descripción:
Una definición de contacto se utiliza para identificar a alguien a quien se debe contactar en caso de un problema en la red. Los diferentes argumentos para una definición de contacto se describe a continuación.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define contact{
contact_name
contact_name
alias
alias
contactgroups
contactgroup_names
host_notifications_enabled
[0/1]
service_notifications_enabled
[0/1]
host_notification_period
timeperiod_name
service_notification_period
timeperiod_name
host_notification_options
[d,u,r,f,s,n]
service_notification_options
[w,u,c,r,f,s,n]
host_notification_commands
command_name
service_notification_commands
command_name
email_address
pager
pager_number or pager_email_gateway
addressx
additional_contact_address
can_submit_commands
[0/1]
retain_status_information
[0/1]
retain_nonstatus_information
[0/1]
}
Definición de ejemplo:
define contact{
contact_name jdoe
alias John Doe
host_notifications_enabled 1
service_notifications_enabled 1
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email jdoe@localhost.localdomain
pager 555-5555@pagergateway.localhost.localdomain
address1 xxxxx.xyyy@icq.com
address2 555-555-5555
can_submit_commands 1
}
Descripción de las directivas:
contact_name:
Esta directiva se utiliza para definir un nombre corto para identificar el contacto. Se hace referencia en las definiciones de grupo de contacto contact group . Bajo las circunstancias adecuadas, la macro $CONTACTNAME$ contendrá este valor.
alias:
Esta directiva se utiliza para definir un nombre más largo o la descripción del contacto. En estas circunstancias los derechos, la macro $CONTACTALIAS$ contendrá este valor. Si no se especifica, el contact_name se utilizará como alias
contactgroups:
Esta directiva se utiliza para identificar el nombre corto (s) del grupo de contacto al cual el contacto pertenece. Múltiples grupos de contacto deben estar separados por comas. Esta directiva se puede utilizar como una alternativa a (o además) a los miembros de la directiva en las definiciones de grupo de contacto o contactgroup
host_notifications_enabled:
Esta directiva se utiliza para determinar si el contacto recibirá las notificaciones acerca de los problemas y recuperaciones Valores: 0 = no enviar notificaciones, 1 = enviar notificaciones.
service_notifications_enabled:
Esta directiva se utiliza para determinar si el contacto recibirá las notificaciones sobre los problemas de servicio y las recuperaciones. Valores: 0 = no enviar notificaciones, 1 = enviar notificaciones.
host_notification_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo o time period durante el cual puede ser el contacto notificado acerca de los problemas de caída o recuperación. Usted puede pensar en esto como una llamada de las notificaciones a los contactos. Lea la documentación relativa a los plazos de tiempo o time periods para obtener más información sobre cómo funciona esto y los problemas potenciales que pueden derivarse de un uso inadecuado.
service_notification_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo time period durante el cual puede ser el contacto notificado acerca de los problemas de servicio o recuperaciones. Usted puede pensar en esto como una llamada de las notificaciones de servicios para el contacto. Lea la documentación relativa a los plazos de tiempo time periods para obtener más información sobre cómo funciona esto y los problemas potenciales que pueden derivarse de un uso inadecuado.
host_notification_commands:
Esta directiva se utiliza para definir una lista de los nombres cortos de los comandos o commands utilizados para notificar al contacto de un problema de caída o recuperación. Varios comandos notificación debe ser separado por comas. Todos los comandos de la notificación se ejecutan cuando el contacto tiene que ser notificada. La cantidad máxima de tiempo que un comando se puede ejecutar la notificación está controlado por la opción tiempo de espera de la notificación o notification_timeout.
host_notification_options:
Esta directiva se utiliza para definir los estados de los equipos para que las notificaciones se pueden enviar a este contacto. Las opciones válidas son una combinación de uno o más de los siguientes: d = Notificar por los estados de equipos caídos, u = notificará a los Estados de equipo inalcanzable, r = notificar acerca de la recepción de equipos de sistemas UP estados, f = notifique cuando la máquina arranca y “flapea” o “bate” flapping , y s = enviar notificaciones cuando el tiempo de inactividad del equipo o scheduled downtime o servicio regular comienza y termina. Si se especifica n (no) como una opción, el contacto no recibirá ningún tipo de notificaciones de acogida.
service_notification_options:
Esta directiva se utiliza para definir los estados de servicio para que las notificaciones se pueden enviar a este contacto. Las opciones válidas son una combinación de uno o más de los siguientes: w = notificar a ADVERTENCIA o WARNING de estados de servicio, u = notificar a los estados de servicio DESCONOCIDO o UNKNOWN, c = notificará a los Estados servicio crítico o CRITICAL, r = notificar acerca de la recuperación de servicio (estados OK), y f = notificará cuando el servicio se inicia y se detiene aleteo o flapping . Si se especifica n (no) como una opción, el contacto no recibirá ningún tipo de notificaciones de servicio.
service_notification_commands:
Esta directiva se utiliza para definir una lista de los nombres cortos de los comandos utilizados para notificar a los contactos de un problema de servicio o de recuperación. Varios comandos de notificación deben estar separadas por comas. Todos los comandos de la notificación se ejecutan cuando el contacto debe ser notificado. La cantidad máxima de tiempo que un comando de notificación puede ejecutar es controlado por la opción notification_timeout.
email:
Esta directiva se utiliza para definir una dirección de correo electrónico para el contacto. Dependiendo de cómo configurar los comandos de notificación, que puede ser utilizado para enviar un correo electrónico de alerta para el contacto. En las circunstancias adecuadas, la macro $CONTACTEMAIL contendrá este valor.
pager:
Esta directiva se utiliza para definir un número de localizador para el contacto. También puede ser una dirección de correo electrónico a una pasarela de buscapersonas (es decir, pagejoe@pagenet.com). Dependiendo de cómo configurar los comandos de notificación, que puede ser utilizado para enviar una página de alerta para el contacto. En las circunstancias adecuadas, la macro $ CONTACTPAGER contendrá este valor.
addressx:
Directivas de direcciones se utilizan para definir adicionales "direcciones" para el contacto. Estas direcciones pueden ser cualquier cosa - números de teléfonos celulares, direcciones de mensajería instantánea, etc Dependiendo de cómo configurar los comandos de notificación, que se puede utilizar para enviar una alerta al contacto. Hasta seis direcciones se pueden definir utilizando estas directivas (address1 través address6). La macro $CONTACTADDRESSx contendrá este valor.
can_submit_commands:
Esta directiva se utiliza para determinar si el contacto puede enviar comandos externos para Nagios desde el CGI. Valores: 0 = no permiten el contacto para enviar comandos, 1 = permitir el contacto para enviar comandos.
retain_status_information:
Esta directiva se utiliza para determinar si procede o no el estatuto de la información relacionada sobre el contacto se mantiene a través de reinicia el programa. Esto sólo es útil si se ha habilitado la retención de estado o retain_state_information usando la directiva retain_state_information. Valor: 0 = desactivar la retención de información de estado, 1 = estado de permitir la retención de información.
retain_nonstatus_information:
Esta directiva se utiliza para determinar cuando la información de estado sobre el contacto se mantiene mientras se reinicia el programa. Esto sólo es útil si se ha habilitado la retención de estado usando la directiva retain_state_information. Valor: 0 = desactivar sin estatus de retención de información, 1 = activar sin estatus de retención de información.
Definición del Grupo de Contacto
Descripción:
Una definición de grupo de contacto se utiliza para agrupar uno o más contactos en conjunto con el propósito de enviar las notificaciones de las alertas / recuperaciones.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define contactgroup{
contactgroup_name
contactgroup_name
alias
alias
members
contacts
contactgroup_members
contactgroups
}
Definición de ejemplo:
define contactgroup{
contactgroup_name novell-admins
alias Novell Administrators
members jdoe,rtobert,tzach
}
Descripción de las directivas:
contactgroup_name:
Esta directiva es un nombre corto que se utiliza para identificar el grupo de contacto.
alias:
Esta directiva se utiliza para definir un nombre más largo o una descripción para identificar el grupo de contacto.
members:
Esta directiva opcional se utiliza para definir una lista de los nombres cortos de contactos que se deben incluir en este grupo. Varios nombres de contacto en caso de estar separados por comas. Esta directiva puede ser usada como una alternativa a (o además) con la directiva contactgroups en las definiciones de contacto
contactgroup_members:
Esta directiva opcional puede ser usado para incluir contactos de otros grupos "sub" en contacto con este grupo de contacto. Especificar una lista delimitada por comas de los nombres cortos de otros grupos de contacto, cuyos miembros deben ser incluidos en este grupo.
Definición de Período de tiempo
Descripción:
Un período de tiempo es una lista de tiempos durante varios días que se consideran "válida" los tiempos para las notificaciones y cheques de servicio. Se compone de intervalos de tiempo para cada día de la semana que "rotan" una vez que la semana ha llegado a su fin. Los diferentes tipos de excepciones a la jornada semanal normal son soportados, incluyendo: lunes a viernes específicas, los días de los meses genéricos, los días de los meses concretos y fechas del calendario.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define timeperiod{
timeperiod_name
timeperiod_name
alias
alias
[weekday]
timeranges
[exception]
timeranges
exclude
[timeperiod1,timeperiod2,...,timeperiodn]
}
Ejemplo de definiciones:
define timeperiod{
timeperiod_name nonworkhours
alias Non-Work Hours
sunday 00:00-24:00 ; Every Sunday of every week
monday 00:00-09:00,17:00-24:00 ; Every Monday of every week
tuesday 00:00-09:00,17:00-24:00 ; Every Tuesday of every week
wednesday 00:00-09:00,17:00-24:00 ; Every Wednesday of every week
thursday 00:00-09:00,17:00-24:00 ; Every Thursday of every week
friday 00:00-09:00,17:00-24:00 ; Every Friday of every week
saturday 00:00-24:00 ; Every Saturday of every week
}
define timeperiod{
timeperiod_name misc-single-days
alias Misc Single Days
1999-01-28 00:00-24:00 ; January 28th, 1999
monday 3 00:00-24:00 ; 3rd Monday of every month
day 2 00:00-24:00 ; 2nd day of every month
february 10 00:00-24:00 ; February 10th of every year
february -1 00:00-24:00 ; Last day in February of every year
friday -2 00:00-24:00 ; 2nd to last Friday of every month
thursday -1 november 00:00-24:00 ; Last Thursday in November of every year
}
define timeperiod{
timeperiod_name misc-date-ranges
alias Misc Date Ranges
2007-01-01 - 2008-02-01 00:00-24:00 ; January 1st, 2007 to February 1st, 2008
monday 3 - thursday 4 00:00-24:00 ; 3rd Monday to 4th Thursday of every month
day 1 - 15 00:00-24:00 ; 1st to 15th day of every month
day 20 - -1 00:00-24:00 ; 20th to the last day of every month
july 10 - 15 00:00-24:00 ; July 10th to July 15th of every year
april 10 - may 15 00:00-24:00 ; April 10th to May 15th of every year
tuesday 1 april - friday 2 may 00:00-24:00 ; 1st Tuesday in April to 2nd Friday in May of every year
}
define timeperiod{
timeperiod_name misc-skip-ranges
alias Misc Skip Ranges
2007-01-01 - 2008-02-01 / 3 00:00-24:00 ; Every 3 days from January 1st, 2007 to February 1st, 2008
2008-04-01 / 7 00:00-24:00 ; Every 7 days from April 1st, 2008 (continuing forever)
monday 3 - thursday 4 / 2 00:00-24:00 ; Every other day from 3rd Monday to 4th Thursday of every month
day 1 - 15 / 5 00:00-24:00 ; Every 5 days from the 1st to the 15th day of every month
july 10 - 15 / 2 00:00-24:00 ; Every other day from July 10th to July 15th of every year
tuesday 1 april - friday 2 may / 6 00:00-24:00 ; Every 6 days from the 1st Tuesday in April to the 2nd Friday in May of every year
}
Descripción de las directivas:
timeperiod_name:
Este directivas es el nombre corto que se utiliza para identificar el período de tiempo.
alias:
Esta directiva es un nombre más largo o una descripción para identificar el período de tiempo.
[weekday]:
Las directivas de los días de semana ("Domingo" a través de "Sábado") están delimitados por comas listas de rangos de tiempo que son "válidos" los tiempos para un día determinado de la semana. Tenga en cuenta que hay siete días diferentes para las que se pueden definir rangos de tiempo (de domingo a sábado). Cada intervalo de tiempo es en la forma de HH:MM-HH:MM, donde se especifican horas en un reloj de 24 horas. Por ejemplo, 00:15-24:00 significa las 12:15a.m. en la mañana de este día hasta las 12:00 am la medianoche (23 horas, 45 minutos de tiempo es el rango total). Si usted desea excluir a un día entero de la TimePeriod, simplemente no lo incluya en la definición de período de tiempo.
[exception]:
Puede especificar varios tipos de excepciones al horario laborable estándar de rotación. Las excepciones pueden tomar una serie de formas diferentes, incluyendo un solo día de un mes específico o genérico, los días de semana solo en un mes, o las fechas de calendario único. También se puede especificar un rango de días / fechas e incluso especificar intervalos a saltar para obtener la funcionalidad descrita por "cada 3 días entre estas fechas". En lugar de una lista de todos los formatos posibles para las cadenas excepción, voy a dejar que nos fijemos en las definiciones de ejemplo TimePeriod de arriba para ver lo que es posible :-) . Durante la semana y diferentes tipos de excepciones todos tienen diferentes niveles de prioridad, lo que es importante para comprender cómo pueden afectar a los demás. Más información sobre esto se puede encontrar en la documentación sobre timeperiods.
exclude:
Esta directiva se utiliza para especificar los nombres cortos de otras definiciones de TimePeriod cuyos rangos de tiempo deben ser excluidos de este período de tiempo. Varios nombres TimePeriod deben ser separados con una coma.
Definición de Comando
Descripción:
Una definición de orden es sólo eso. Se define un comando. Los comandos que se pueden definir son los chequeos de servicios, notificaciones de servicio, los manipuladores de servicios de eventos, los controles de host, las notificaciones de host y los controladores de eventos del equipo. Definiciones de los comandos pueden contener macros, pero debe asegurarse de que incluya sólo las macros que son "válidas" en las circunstancias cuando el comando se utilizará. Más información sobre las macros están disponibles y cuando son "válidas" se puede encontrar aquí. Los diferentes argumentos para una definición de comandos se describen a continuación.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define command{
command_name
command_name
command_line
command_line
}
Definición de ejemplo:
define command{
command_name check_pop
command_line /usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$
}
Descripción de las directivas:
command_name:
Esta directiva es el nombre corto que se utiliza para identificar el comando. Se hace referencia en las definiciones de contacto, de equipo, y de servicio (en la notificación, consulta, y las directivas de controlador de eventos), entre otros sitios.
command_line:
Esta directiva se utiliza para definir lo que realmente se ejecuta Nagios, cuando el comando se utiliza para el control de servicios o de equipos, las notificaciones, o controladores de eventos. Antes de la línea de comandos se ejecuta, todas las macros válidas son sustituidas por sus respectivos valores. Consulte la documentación de macros para determinar cuándo se pueden utilizar diferentes macros. Tenga en cuenta que la línea de comandos no está rodeado de comillas. Además, si usted desea pasar un signo de dólar ($) en la línea de comandos, usted tiene que finalizar esa linea con otro signo de dólar($).
NOTA: Usted debe no incluir un punto y coma (;) en la directiva command_line, porque después de todo lo que se tendrá en cuenta como un comentario fichero de configuración. Puede evitar esta limitación mediante el establecimiento de una de las macros $USER en el archivo de recursos o resource file a un punto y coma y luego hacer referencia a la macro adecuada $ USER $ en la directiva command_line en lugar del punto y coma.
Si usted desea pasar argumentos a los comandos en tiempo de ejecución, puede utilizar $ARGn$ macros en la directiva command_line de la definición del comando y luego se separan los argumentos individuales del nombre del comando (y el uno del otro) con signo de admiración (!) Los caracteres del objeto definición de directiva (ver comando del host, el servicio de mandatos de controlador de eventos, etc) que hace referencia el comando. Más información sobre cómo los argumentos en las definiciones de comandos se procesan en tiempo de ejecución se pueden encontrar en la documentación sobre las macros.
Definición de servicios de dependencia
Descripción:
Dependencias de los servicios son una característica avanzada de Nagios que permiten eliminar las notificaciones y cheques de activos de servicios basados en el estado de uno o más servicios. Dependencias de los servicios son opcionales y están dirigidos principalmente a usuarios avanzados que han complicado las configuraciones de control. Más información sobre el funcionamiento de las dependencias de servicio (lea esto!) Se puede encontrar aquí.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define servicedependency{
dependent_host_name
host_name
dependent_hostgroup_name
hostgroup_name
dependent_service_description
service_description
host_name
host_name
hostgroup_name
hostgroup_name
service_description
service_description
inherits_parent
[0/1]
execution_failure_criteria
[o,w,u,c,p,n]
notification_failure_criteria
[o,w,u,c,p,n]
dependency_period
timeperiod_name
}
Definición de ejemplo:
define servicedependency{
host_name WWW1
service_description Apache Web Server
dependent_host_name WWW1
dependent_service_description Main Web Site
execution_failure_criteria n
notification_failure_criteria w,u,c
}
Descripción de las directivas:
dependent_host_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la máquina (s) o hots(s) que el servicio depende de "corre" en o está asociado. Varios hosts deben estar separadas por comas. Dejando en blanco esta directiva se puede utilizar para crear las dependencias con "el mismo host".
dependent_hostgroup_name:
Esta directiva se utiliza para especificar el nombre corto (s) de la grupo de equipos o hostgroup (s) sobre el cual el servicio el cual depende “corre" o está asociado. Múltiples grupos de equipos (Hostgroups) deben estar separados por comas. El dependent_hostgroup se puede utilizar en lugar de, o además de, la directiva dependent_host.
dependent_service_Descripción:
Esta directiva se utiliza para identificar la descripción de los servicios dependientes.
host_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la máquina (s) (host) del cual depende el servicio (también conocida como la maestra de servicio) o el servicio está asociado. Varios hosts deben estar separadas por comas.
hostgroup_name:
Esta directiva se utiliza para identificar el nombre corto (s) del hostgroup (s) en el cual el servicio esta asociado. (también conocida como la maestra de servicio). Hostgroups múltiples deben estar separados por comas. El hostgroup_name se puede utilizar en lugar de, o además de, la directiva host_name.
service_Descripción:
Esta directiva se utiliza para identificar la descripción del servicio del cual se depende (también conocida como la maestra de servicio).
inherits_parent:
Esta directiva indica si la dependencia hereda las dependencias del servicio de las cuales dependía (también conocida como la maestra de servicio). En otras palabras, si el servicio principal depende de otros servicios y cualquiera de las dependencias falle, en esta dependencia también se producirá un error.
execution_failure_criteria:
Esta directiva se utiliza para especificar los criterios que determinan cuando el servicio dependiente no se debe comprobar. Si el servicio principal se encuentra en estado de error ,el servicio dependiente no se activa .
Las opciones válidas son una combinación de uno o más de los siguientes (opciones múltiples se separan con comas): o = fallo en un estado OK, w = error en un estado de advertencia, u = no en un estado desconocido, c = un error en un estado crítico, y p = no en un estado pendiente (por ejemplo, el servicio aún no ha sido comprobado). Si se especifica n (no) como una opción, la dependencia de la ejecución no se producirá un error y control del servicio depende siempre de forma activa seleccionada (si las condiciones lo permiten otros para que sea). Ejemplo: Si se especifica o, c, u en este campo, el servicio dependiente no se comprobará si el servicio de maestro, esta en un estado OK, CRITICAL o UNKNOWN.
notification_failure_criteria:
Esta directiva se utiliza para definir los criterios que determinan cuándo las notificaciones para el servicio dependiente no debe ser enviado. Si el servicio principal se encuentra en uno estado NO OK, las notificaciones para el servicio dependiente no se enviará a los contactos. Las opciones válidas son una combinación de uno o más de los siguientes: o = no en un estado bien, w = error en un estado de advertencia, u = no en un estado desconocido, c = no en un estado crítico, y p = a un estado pendiente (por ejemplo, el servicio aún no ha sido comprobado). Si se especifica n (no) como una opción, la dependencia de la notificación nunca fallan y las notificaciones para el servicio dependiente siempre será enviado. Ejemplo: Si se especifica w en este campo, las notificaciones para el servicio dependiente no se enviará si el servicio principal se encuentra en un estado de advertencia.
dependency_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo durante el cual esta dependencia es válido. Si esta directiva no se especifica, la dependencia se considera que es válido durante todo el tiempo.
Definición de escalado del Servicio
Descripción:
Escaladas de servicios son opcionales y se utilizan para escalar las notificaciones para un servicio particular. Más información sobre la forma de notificación de trabajo escaladas se puede encontrar aquí.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define serviceescalation{
host_name
host_name
hostgroup_name
hostgroup_name
service_description
service_description
contacts
contacts
contact_groups
contactgroup_name
first_notification
#
last_notification
#
notification_interval
#
escalation_period
timeperiod_name
escalation_options
[w,u,c,r]
}
Definición de ejemplo:
define serviceescalation{
host_name nt-3
service_description Processor Load
first_notification 4
last_notification 0
notification_interval 30
contact_groups all-nt-admins,themanagers
}
Descripción de las directivas:
host_name:
Esta directiva se utiliza para identificar el nombre corto (s) del equipo o host (s) que la escalada de servicios debe aplicarse o está asociado.
hostgroup_name:
Esta directiva se utiliza para especificar el nombre corto (s) del hostgroup (s) por el cual el escalado de servicios debe aplicarse o está asociado. Múltiples hostgroups deben estar separados por comas. El hostgroup_name se puede utilizar en lugar de, o además de, la directiva host_name.
service_Descripción:
Esta directiva se utiliza para identificar la descripción de los servicios de escalado que se debe de aplicar.
first_notification:
Esta directiva es un número que identifica a la primera notificación de que esta escalada es eficaz. Por ejemplo, si establece este valor a 3, este aumento sólo se utilizará si el servicio está en un estado no-OK tiempo suficiente para que una tercera notificación.
last_notification:
Esta directiva es un número que identifica a la última notificación por la que esta escalada es eficaz. Por ejemplo, si establece este valor a 5, esta escalada no se utilizará si hay más de cinco notificaciones se envían por el servicio. Al establecer este valor a 0 significa seguir usando esta entrada escalada de siempre (no importa cómo muchas notificaciones deben de salir).
contacts:
Esta es una lista de los nombres cortos de los contactos que debe ser notificado cada vez que hay problemas (o recuperación) con este servicio. Varios contactos deben estar separadas por comas. Útil si desea que las notificaciones se dirige sólo a unas cuantas personas y no desea configurar grupos de contacto o contact groups. Debe especificar al menos un contacto o un grupo en cada definición de la escalada de servicio.
contact_groups:
Esta directiva se utiliza para identificar el nombre abreviado del grupo de contacto o contact group que debe ser notificado cuando el servicio de notificación se debe de escalar. Varios grupos de contacto en caso de estar separados por comas. Debe especificar al menos un contacto o un grupo en cada definición de la escalado de servicio.
notification_interval:
Esta directiva se utiliza para determinar el intervalo en el que las notificaciones deben hacerse al mismo tiempo esta escalada es válido. Si se especifica un valor de 0 en el intervalo, Nagios envía las notificaciones por primera vez cuando esta definición es válida la escalada, pero evitará que más notificaciones del problema sea enviado desde el equipo. Las notificaciones no se envían de nuevo hasta que el anfitrión se recupere. Esto es útil si desea dejar de tener las notificaciones enviadas después de una cierta cantidad de tiempo. Nota: Si una gran cantidad de entradas escalada se superponen en uno o más rangos de notificación, el intervalo más pequeño de la notificación de todas las entradas de la escalada es el que se utiliza.
escalation_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo durante el cual esta escalada es válido. Si esta directiva no se especifica, la escalada es considerado como válido durante todo el tiempo.
escalation_options:
Esta directiva se utiliza para definir los criterios que determinan si esta escalada se usa el servicio. La escalada se utiliza sólo si el servicio se encuentra en uno de los estados en la presente Directiva. Si esta directiva no se especifica en una escalada de servicios, la escalada es considerada como válida en todos los estados de servicio. Las opciones válidas son una combinación de uno o más de los siguientes: r = escalar sobre un OK (recuperación) del estado, w = escalar en un estado de advertencia o WARNING, u = escalar en un estado desconocido o UNKNOWN, y c = escalar en un estado CRITICAL. Ejemplo: Si se especifica w en este campo, la escalada sólo se utilizará si el servicio se encuentra en un estado de advertencia.
Definición de dependencia del equipo
Descripción:
Dependencias del equipo son una característica avanzada de Nagios que permiten eliminar las notificaciones de hosts basados en el estado de uno o más hosts. Dependencias de equipo son opcionales y están dirigidos principalmente a usuarios avanzados que han complicado las configuraciones de control. Más información sobre cómo trabajar las dependencias de acogida (leer esto!) Se puede encontrar aquí.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define hostdependency{
dependent_host_name
host_name
dependent_hostgroup_name
hostgroup_name
host_name
host_name
hostgroup_name
hostgroup_name
inherits_parent
[0/1]
execution_failure_criteria
[o,d,u,p,n]
notification_failure_criteria
[o,d,u,p,n]
dependency_period
timeperiod_name
}
Definición de ejemplo:
define hostdependency{
host_name WWW1
dependent_host_name DBASE1
notification_failure_criteria d,u
}
Descripción de las directivas:
dependent_host_name:
Esta directiva se utiliza para identificar el nombre corto (s) del equipo o host a cargo (s). Varios hosts deben estar separadas por comas.
dependent_hostgroup_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la hostgroup dependiente (s). Múltiples Hostgroups deben estar separados por comas. El dependent_hostgroup_name se puede utilizar en lugar de, o además de, la directiva dependent_host_name.
host_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la máquina (s) o host del cual depende (también conocida como la sede principal). Varios hosts deben estar separadas por comas.
hostgroup_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la hostgroup (s) del cual depende (también conocida como la sede principal). Hostgroups múltiples deben estar separados por comas. El hostgroup_name se puede utilizar en lugar de, o además de, la directiva host_name.
inherits_parent:
Esta directiva indica si la dependencia hereda las dependencias del equipo del cual depende (también conocida como la sede principal). En otras palabras, si el equipo maestro depende de otros equipos, y cualquiera de las dependencias falla, esta dependencia también se producirá un error.
execution_failure_criteria:
Esta directiva se utiliza para especificar los criterios que determinan cuando el equipo dependiente no se debe comprobar. Si la máquina principal se encuentra en uno de los estados de error, el chequeo del anfitrión dependiente seleccionado no se activa . Las opciones válidas son una combinación de uno o más de los siguientes (opciones múltiples se separan con comas): o = no en un estado UP, d = no en un estado inactivo, u = no en un estado inalcanzable, y p = no en un estado pendiente (por ejemplo, la máquina aún no ha sido comprobado). Si se especifica n (no) como una opción, la dependencia de la ejecución no se producirá un error y el anfitrión depende siempre de forma activa seleccionada (si las condiciones lo permiten otros para que sea). Ejemplo: Si se especifica u, d en este campo, el anfitrión dependiente no se activa comprobar si el host maestro, ya sea en un estado inalcanzable (UNREACHABLE ) o caído (DOWN)
notification_failure_criteria:
Esta directiva se utiliza para definir los criterios que determinan cuándo las notificaciones para el anfitrión dependiente no debe ser enviado. Si la máquina principal se encuentra en uno de los fracaso de los estados se especifica, las notificaciones para el anfitrión dependientes no se enviará a los contactos. Las opciones válidas son una combinación de uno o más de los siguientes: o = no en un estado UP, d = no en un estado inactivo, u = no en un estado inalcanzable, y p = error en un estado pendiente (por ejemplo, la acogida ha aún no se ha comprobado). Si se especifica n (no) como una opción, la dependencia de la notificación nunca fallan y las notificaciones para el anfitrión depende siempre será enviado. Ejemplo: Si se especifica d en este campo, las notificaciones para el anfitrión dependiente no se enviará si la máquina principal se encuentra en estado DOWN.
dependency_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo durante el cual esta dependencia es válido. Si esta directiva no se especifica, la dependencia se considera que es válido durante todo el tiempo.
Definición de escalado de equipo
Descripción:
Escalados de equipo son opcionales y se utilizan para escalar las notificaciones para un host en particular. Más información sobre la forma de notificación de trabajo escaladas se puede encontrar aquí.
Definición del formato:
Nota: Las Directivas en rojo son obligatorios, mientras que los de negro son opcionales.
define hostescalation{
host_name
host_name
hostgroup_name
hostgroup_name
contacts
contacts
contact_groups
contactgroup_name
first_notification
#
last_notification
#
notification_interval
#
escalation_period
timeperiod_name
escalation_options
[d,u,r]
}
Definición de ejemplo:
define hostescalation{
host_name router-34
first_notification 5
last_notification 8
notification_interval 60
contact_groups all-router-admins
}
Descripción de las directivas:
host_name:
Esta directiva se utiliza para identificar el nombre corto del equipo al cual se debe de escalar.
hostgroup_name:
Esta directiva se utiliza para identificar el nombre corto (s) de la hostgroup (s) del grupo al cual el escalado se debe de aplicar. Varios grupos de equipos deben estar separados por comas. Si se utiliza, el escalado se aplicará a todos los hosts que son miembros de la hostgroup especificada (s).
first_notification:
Esta directiva es un número que identifica la primera notificación el cual este escalado es eficaz. Por ejemplo, si establece este valor a 3, este aumento sólo se utilizará si el ordenador está inactivo o inaccesible el tiempo suficiente para una tercera notificación para salir
last_notification:
Esta directiva es un número que identifica a la última notificación por el cual el escalado es eficaz. Por ejemplo, si establece este valor a 5, esta escalada no se utilizará si hay más de cinco notificaciones se envían para el equipo. Al establecer este valor a 0 significa seguir usando esta entrada escalada de siempre (no importa cómo muchas notificaciones de salir).
contacts:
Esta es una lista de los nombres cortos de los contactos al cual debe ser notificado cada vez que hay problemas (o recuperación) con esta máquina. Varios contactos deben estar separadas por comas. Útil si desea que las notificaciones se dirige sólo a unas cuantas personas y no desea configurar grupos de contacto. Debe especificar al menos un contacto o un grupo en cada definición de la escalada de acogida.
contact_groups:
Esta directiva se utiliza para identificar el nombre abreviado del grupo de contacto que debe ser notificado cuando la notificación del equipo requiere de una notificación de escalado. Varios grupos de contacto en caso de estar separados por comas. Debe especificar al menos un contacto o un grupo en cada definición de la escalada del equipo.
notification_interval:
Esta directiva se utiliza para determinar el intervalo en el que las notificaciones deben hacerse al mismo tiempo esta escalada es válido. Si se especifica un valor de 0 en el intervalo, Nagios envíe las notificaciones por primera vez cuando esta definición es válida la escalada, pero evitará que más notificaciones problema de ser enviado para el anfitrión. Las notificaciones se envían de nuevo hasta que el anfitrión se recupere. Esto es útil si desea dejar de tener las notificaciones enviadas después de una cierta cantidad de tiempo. Nota: Si varias entradas escalada de una gran cantidad de superposición de uno o más rangos de la notificación, el intervalo más pequeño de la notificación de todas las entradas de la escalada se utiliza. .
escalation_period:
Esta directiva se utiliza para especificar el nombre corto del período de tiempo durante el cual este escalado es válido. Si esta directiva no se especifica, la escalada es considerado como válido durante todo el tiempo.
escalation_options:
Esta directiva se utiliza para definir los criterios que determinan cuándo este escalado de host se utiliza. El escalado se utiliza sólo si el host se encuentra en uno de los estados en la presente Directiva. Si esta directiva no se especifica en una escalada del equipo, el escalado es considerado como válida en todos los países de acogida. Las opciones válidas son una combinación de uno o más de los siguientes: r = escalar en una UP (recuperación) del estado, d = escalar en un estado inactivo, y u = escalar en un estado inalcanzable. Ejemplo: Si se especifica d en este campo, la escalada sólo se utilizará si el ordenador está en un estado hacia abajo.
Definición de información extendida de equipo
Descripción:
Información extendida de información de equipos se utilizan básicamente para hacer la salida del estado, mapa de estado o statusmap, statuswrl, y CGIs extinfo parecen bastante. No tienen ningún efecto sobre la vigilancia y son completamente opcionales.
Consejo: A partir de Nagios 3.x, todas las directivas contenidas en la información ampliada definiciones de equipos también están disponibles en las definiciones de equipo. Por lo tanto, usted puede elegir para definir las directrices a continuación en las definiciones de su equipo si le parece una configuración más simple. Las informaciones de definiciones extendidas continúan contando con el apoyo para las versiones anteriores
Definición del formato:
Nota: Las variables en rojo son obligatorios, mientras que los de negro son opcionales. Sin embargo, es necesario proporcionar al menos una variable opcional en cada definición para que pueda ser de mucha utilidad.
define hostextinfo{
host_name
host_name
notes
note_string
notes_url
url
action_url
url
icon_image
image_file
icon_image_alt
alt_string
vrml_image
image_file
statusmap_image
image_file
2d_coords
x_coord,y_coord
3d_coords
x_coord,y_coord,z_coord
}
Definición de ejemplo:
define hostextinfo{
host_name netware1
notes This is the primary Netware file server
notes_url http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
icon_image novell40.png
icon_image_alt IntranetWare 4.11
vrml_image novell40.png
statusmap_image novell40.gd2
2d_coords 100,250
3d_coords 100.0,50.0,75.0
}
Descripción de las variables:
host_name:
Esta variable se utiliza para identificar el nombre corto del host que está asociado con los datos.
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el host. Si se especifica una nota aquí, podrás ver el que en el CGI información ampliada (cuando está viendo la información sobre el host)
notes_url:
Esta variable se utiliza para definir una URL opcional que se puede utilizar para proporcionar más información acerca del host. Si se especifica una dirección URL, verás un enlace que dice "Notas Host Extra" en el CGI información ampliada (cuando está viendo la información sobre el host). Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios/). Esto puede ser muy útil si desea hacer que la información detallada en el host, los métodos de contacto de emergencia, etc a disposición del personal de apoyo.
action_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para ofrecer más acciones a realizar en el host. Si se especifica una dirección URL, verás un enlace que dice "Las acciones Host Extra" en el CGI información ampliada (cuando está viendo la información sobre el host). Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios//).
icon_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG, JPG o que deben estar asociados con esta máquina. Esta imagen se mostrará en el estado y CGIs información extendida. La imagen se verá mejor si es de 40x40 píxeles. Imágenes para los anfitriones se supone que esta en el el subdirectorio /logos en el directorio de imágenes en HTML (es decir, /usr/local/nagios/share/images/logos)
icon_image_alt:
Esta variable se utiliza para definir una cadena opcional que se utiliza en la etiqueta ALT de la imagen especificada por el argumento
vrml_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG, JPG o que deben estar asociados con esta máquina. Esta imagen se utilizará como el mapa de textura para el host especificado en el CGI statuswrl. A diferencia de la imagen que el uso de la variable
statusmap_image:
Esta variable se utiliza para definir el nombre de una imagen que debe estar asociado con esta máquina en el CGI statusmap. Puede especificar una imagen JPEG, PNG, GIF y si quieres, aunque me gustaría sugerir fuertemente con una imagen en formato GD2, como otros formatos de imagen resultará en una gran cantidad de tiempo de CPU pierde cuando la imagen se genera statusmap. GD2 se pueden crear imágenes a partir de imágenes PNG con la utilidad pngtogd2 suministrado con la biblioteca de Thomas Boutell de Di-s. El GD2 imágenes deben ser creados en formato sin comprimir con el fin de minimizar la carga de la CPU cuando el CGI statusmap está generando la imagen del mapa de la red. La imagen se verá mejor si es de 40x40 píxeles. Puede dejar estos opción en blanco si no está utilizando el CGI statusmap. Imágenes para los anfitriones se supone que en el logos / subdirectorio en el directorio de imágenes en HTML (es decir, /usr/local/nagios/share/images/logos).
2d_coords:
Esta variable se utiliza para definir las coordenadas a utilizar en la elaboración de la acogida en el CGI statusmap. Coordenadas deben ser dados por números enteros positivos, ya que corresponden a los píxeles de física en la imagen generada. El origen de la elaboración (0,0) se encuentra en la esquina superior izquierda de la imagen y se extiende en la dirección positiva (a la derecha) en la parte superior de la imagen y en la dirección positiva (hacia abajo) a lo largo de la mano izquierda lado de la imagen. Para referencia, el tamaño de los iconos elaborados suele ser de unos 40x40 píxeles (el texto toma un poco más de espacio). Las coordenadas que especifique aquí son de la esquina superior izquierda del icono de host que se dibuja. Nota: No se preocupe por lo que las coordenadas x e y máximo que puede utilizar son. El CGI calculará automáticamente las dimensiones máximas de la imagen se crea sobre la base de la más grande de coordenadas X e Y que usted especifique.
3d_coords:
Esta variable se utiliza para definir las coordenadas a utilizar en la elaboración de la acogida en el CGI statuswrl. Las coordenadas pueden ser números reales positivos o negativos. El origen de dibujo (0.0,0.0,0.0). Como referencia, el tamaño de los cubos de acogida elaborado es de 0,5 unidades en cada lado (texto tiene un poco más espacio). Las coordenadas que especifique aquí se utilizan como el centro del cubo de acogida
Información ampliación de la Definición de Servicio
Descripción:
Información extendida de entradas de servicio se utilizan básicamente para hacer la salida de la situación y CGIs extinfo parecen bastante. No tienen ningún efecto sobre la vigilancia y son completamente opcionales.
Consejo: A partir de Nagios 3.x, todas las directivas contenidas en las informaciones de definiciones de servicio extendido también están disponibles en las definiciones de servicio. Por lo tanto, usted puede elegir para definir las directrices a continuación en las definiciones de servicio si se hace la configuración más simple. Las definiciones extendidas de servicios seguirán siendo compatible en las versiones anteriores.
Definición del formato:
Nota: Las variables en rojo son obligatorios, mientras que los de negro son opcionales. Sin embargo, es necesario proporcionar al menos una variable opcional en cada definición para que pueda ser de mucha utilidad.
define serviceextinfo{
host_name
host_name
service_description
service_description
notes
note_string
notes_url
url
action_url
url
icon_image
image_file
icon_image_alt
alt_string
}
Definición de ejemplo:
define serviceextinfo{
host_name linux2
service_description Log Anomalies
notes Security-related log anomalies on secondary Linux server
notes_url http://webserver.localhost.localdomain/serviceinfo.pl?host=linux2&service=Log+Anomalies
icon_image security.png
icon_image_alt Security-Related Alerts
}
Descripción de las variables:
host_name:
Esta directiva se utiliza para identificar el nombre corto del host que el servicio está asociado.
service_Descripción:
Esta directiva es la descripción del servicio que se asocia con los datos.
notes:
Esta directiva se utiliza para definir una cadena opcional de notas relacionadas con el servicio. Si se especifica una nota aquí, podrás ver el que en el CGI información ampliada (cuando está viendo la información sobre el servicio especificado).
notes_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para proporcionar más información sobre el servicio. Si se especifica una dirección URL, verás un enlace que dice "Notas de servicio adicional" en el CGI información ampliada (cuando está viendo la información sobre el servicio especificado). Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, /cgi-bin/nagios/). Esto puede ser muy útil si desea hacer que la información detallada sobre el servicio, los métodos de contacto de emergencia, etc a disposición del personal de apoyo
action_url:
Esta directiva se utiliza para definir una URL opcional que se puede utilizar para ofrecer más acciones a realizar en el servicio. Si se especifica una dirección URL, verás un enlace que dice "Acciones de servicio adicional" en el CGI información ampliada (cuando está viendo la información sobre el servicio especificado). Cualquier URL válida se puede utilizar. Si usted planea usar rutas relativas, la ruta de la base será la misma como lo que se utiliza para acceder a la CGI (es decir, / cgi-bin/nagios /).
icon_image:
Esta variable se utiliza para definir el nombre de una imagen GIF, PNG, JPG o que deben estar asociados con esta máquina. Esta imagen se mostrará en el estado y CGIs información extendida. La imagen se verá mejor si es de 40x40 píxeles. Imágenes para los anfitriones se supone que en el logos / subdirectorio en el directorio de imágenes en HTML (es decir, /usr/local/nagios/share/images/logos)..
icon_image_alt:
Esta variable se utiliza para definir una cadena opcional que se utiliza en la etiqueta ALT de la imagen especificada por el argumento
