El trabajo sobre la nueva version 0.6.x está en progreso.

A partir de esta versión 0.6.x hemos cambiado de subversion a GIT. El repositorio de código fuente está disponible en sourceforge.

Funciones ya implementadas

• Frontal Web basado en Kohana
• Frontal Web basado en jQuery Themes
• Funciones Javascript usandojQuery plugins
• process_perfdata.pl es capaz de usar una base de datos RRD por origen de datos
• instalador mejorado. Especificación de directorio de layouts usando --with-layout
• Los errores de RRDtool se muestran ahora como imágenes. No más errores de imágenes que no se muestran
• Las plantillas PNP ya no pueden sobreescribir variables internas
• Las plantillas PNP de la versión 0.4.x todavía se pueden usar
• Refactorización de las funciones de PDF
• Optimización de la plantilla default.php
• Exportación de bases de datos RRD a formatos XML, CSV y JSON usando la función “export” de RRDtool
• Refactorización de las funciones de Página
• Las páginas de error enlazan a las FAQ online
• Mouseover Popup en el frontal web de Nagios vía jQuery.clueTip plugin
• Soporte completo de rrdcached

volver a contenidos | requerimientos de sistema

PNP requiere de forma obligatoria datos de rendimiento válidos de los plugins de nagios.

¿Pero qué son estos datos de rendimiento?

La salida de los plugins hasta la versión 2.x de nagios estaba limitada a una línea. Cuando el plugin genera datos de rendimiento, estos son divididos en 2 partes. El símbolo de la tubería(“|”) se usa como delimitador.

Ejemplo de check_icmp :

 OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;

que devuelve el texto a la izquierda del símbolo de tubería

 OK - 127.0.0.1: rta 2.687ms, lost 0%

y los datos de rendimiento

  rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;

Los datos de rendimiento están diseñados para ser procesados automáticamente. El formato está especificado en lasGuías del Desarrollador (Se puede encontrar una excepción aquí) a continuación vemos un ejemplo:

  rta=2.687ms;3000.000;5000.000;0;
   |    |  |    |         |     | |
   |----|--|----|---------|-----|-|----- * label 
        |--|----|---------|-----|-|----- * current value
           |----|---------|-----|-|----- unit ( UOM = UNIT of Measurement ) 
                |---------|-----|-|----- warning threshold
                          |-----|-|----- critical threshold 
                                |-|----- minimum value 
                                  |----- maximum value
                                  

Los valores marcados con * son obligatorios. Todos los demás son opcionales.

Varias series de datos están separadas por espacios en blanco. Los datos no pueden contener espacios en blanco. Si la etiqueta contiene espacios en blanco, deben estar entre comillas simples.

• Perl >= 5.x sin módulos adicionales
• RRDtool >= 1.x, mejor 1.2 pero no obligatorio
  Atención: instalar RRDtool sin un gestor de paquetes puede causar errores con las fuentes dejavu. Si ve gráficos sin texto, esta podría ser la causa.
• PHP >= 5.1.6 para el frontal web basado en Kohana
• Nagios >= 2.x o Icinga
• Kohana necesita que el módulo de Apache “mod_rewrite” esté habilitado. Para más detalles, revise la documentación específica de su distribución sobre su servidor web.

PNP está licenciado bajo GPL 2

El desarrollo de PNP está organizado usando Sourceforge.Net. PNP está registrado bajo “PNP4nagios”.

La versión estable actual 0.4.x se puede encontrar en el área de descarga: Sourceforge Download

Si quiere estar al día, puede usar la última versión de desarrollo de la rama 0.4.x que se genera automáticamente sobre una base diaria desde el repositorio SVN.

A partir de la versión PNP 0.6.x el repositorio de código fuente ha cambiado de SVN a GIT.

La versión actual de desarrollo puede verse en cualquier momento en http://pnp4nagios.git.sourceforge.net/. Haciendo click en PNP Devel version descargará un archivo que contiene la última versión.

ANTES de realizar cuestiones de soporte asegúrese de que ha verificado los elements descritos en verificando su instalación.

Los desarrolladores y colaboradores están presentes en un foro aparte, que se encuentra en http://www.nagios-portal.org y permanecen informados sobre nuevas peticiones en la sección de PNP. Las cuestiones publicadas en inglés serán respondidas.
Después de registrarse como usuario, rellene el perfil correspodiente al sistema operativo y la versión de PNP que usa. Mencione también si está usando un paquete o si está compilando desde las fuentes. Marcar los hilos solucionados, añadiendo ”[solved]” al título, ayudará a otros usuarios a encontrar soluciones a sus problemas.

Puede usar las listas de correo de Sourceforge para solicitar soporte(están limitadas al inglés):

pnp4nagios-users: lista de usuarios para cuestiones generales sobre configuraciones. Detalle su sistema operativo y versión de PNP

pnp4nagios-devel: lista de desarrollo para sugerencias e informe de errores. Detalle su sistema operativo y versión de PNP

pnp4nagios-checkins: lista de checkin que automáticamente contiene los cambios en los repositorios

Los datos de rendimiento se almacenan en Round Robin Databases usando RRDtool. Esto quiere decir que después de algún tiempo, los datos más antiguos son descartados y reemplazados por los nuevos valores.

Diferentes intervalos proporcionan diferentes resoluciones. Usar los valores por defecto permite almacenar datos con una resolución de un minuto para los dos últimos días, una resolución de cinco minutos para diez días, una resolución de 30 minutos durante 90 días y 6 horas de resolución durante cuatro años. Incrementando el intervalo El incremento de los intervalos origina que la media de los datos genere valores máximos más pequeños, al disminuir la frecuencia de muestreo los datos tienden a “normalizarse”. Esto no es un error de PNP.

Usando este formato de almacenamiento el tamaño de los ficheros permanece estable en el tiempo. Necesitará aproximadamente unos 400 KB por fuente de datos.

• An error occurred while fetching this feed: http://sourceforge.net/export/rss2_projsummary.php?group_id=191615

volver a contenidos | modos de PNP

PNP soporta varios modos para procesar los datos de rendimiento . Los modos difieren en la complejidad y el rendimiento que se espere.

Nagios invoca un comando por cada equipo y cada servicio que tengan datos de rendimiento que deban ser procesados. Dependiendo del modo elegido, los datos son pasados a process_perfdata.pl o serán escritos en ficheros temporales y procesados más tarde. process_perfdata.pl escribe los datos en ficheros XML y los almacena en ficheros RRD usando using RRDtool.

Antes de elegir un modo, tómese un momento para leer la documentación y decidir qué forma es la mejor para su instalación.

El “Modo Síncrono” es el más simple y sencillo de configurar. Nagios llama al script de perl process_perfdata.pl para cada servicio y equipo, respectivamente, para procesar los datos. El modo síncrono escala bien hasta unos 1.000 servicios con un intervalo de 5 minutos.

En el modo masivo Nagios escribe los datos necesarios en un fichero temporal. Después de un intervalo de tiempo definido este fichero es procesado de golpe y borrado a continuación.

El número de llamadas a process_perfdata.pl se reduce al mínimo. Dependiendo del tiempo y la cantidad de datos recolectados hay muchas menos llamadas de sistema. En su lugar, la ejecución de process_perfdata.pl dura más tiempo.

Nota Al usar este modo debería vigilar el tiempo de ejecución de process_perfdata.pl. Durante su ejecución nagios no ejecuta ningún chequeo.

ejemplo de var/perfdata.log:

2007-10-18 12:05:01 [21138] 71 Lines processed
2007-10-18 12:05:01 [21138] .../spool/service-perfdata-1192701894-PID-21138 deleted
2007-10-18 12:05:01 [21138] PNP exiting (runtime 0.060969s) ...

71 líneas han sido procesadas en 0.06 segundos. Este corresponde a un volumen de datos de unos 2000 servicios y a un intervalo de procesado de 10 segundos. Lo que seignifica que se ha bloqueado a nagios durante 0.06 segundos exactamente.

Visto desde el punto de vista de Nagios, este es el mejor modo de procesado, puesto que Nagios no es bloquedado.

Nagios de nuevo, usa un fichero temporal para almacenar los datos y ejecuta un comando después de cierto tiempo predefinido. En lugar de procesar inmediatamente los datos mediante process_perfdata.pl, el fichero es movido a un directorio de spool. Debido a que únicamente estamos moviendo un fichero del mismo sistema de ficheros, esto no lleva prácticamente tiempo, por lo que nagioses capaz de ejecutar su trabajo de forma inmediata.

El demonio NPCD (Nagios Performance C Daemon) monitoriza el directorio en busca de nuevos ficheros y le pasa los nombres a process_perfdata.pl. El procesado de los datos esta desacoplado de Nagios. NPCD es capaz de lanzar múltiples hilos de ejecución para el procesado de datos.

Este escenario incluye npcdmod.o, un módulo NEB. Se reduce la configuración del “Modo Masivo con NPCD” a un par de líneas en nagios.cfg

Es similar al “Modo Masivo con NPCD” y tiene exactamente la misma funcionalidad y rendimiento.

TODO

El modo que debe elegir dependerá del tamaño de su instalación de Nagios. Encontrará detalles en la documentación.

volver a contenidos | instalación

Se ha reescrito completamente el frontal web, que ahora está basado en el framework PHP MVC Kohana. Por esto debemos comprobar las dependencias que han cambiado, antes de la instalación.

Si no se especifica ninguna opción en ./configure PNP 0.4.x se instalará en una instalación de Nagios existente en /usr/local/nagios.

Si no se especifica ninguna opción en ./configure PNP 0.6.x se instalará en un directorio independiente, en/usr/local/pnp4nagios, por lo que debería verse como una aplicación independiente.

Resumen de una instalación PNP 0.4.14

./configure
...
*** Configuration summary for pnp 0.4.14 05-02-2009 ***

  General Options:
  -------------------------         -------------------
  Nagios user/group:                nagios nagios
  Install directory:                /usr/local/nagios
  HTML Dir:                         /usr/local/nagios/share/pnp
  Config Dir:                       /usr/local/nagios/etc/pnp
  Location of rrdtool binary:       /usr/bin/rrdtool Version 1.3.1
  RRDs Perl Modules:                FOUND (Version 1.3001)
  RRD Files stored in:              /usr/local/nagios/share/perfdata
  process_perfdata.pl Logfile:      /usr/local/nagios/var/perfdata.log
  Perfdata files (NPCD) stored in:  /usr/local/nagios/var/spool/perfdata/

Resumen de una instalación PNP 0.6.0

./configure
...
*** Configuration summary for pnp4nagios-0.6.0 07-30-2009 ***

  General Options:
  -------------------------         -------------------
  Nagios user/group:                nagios nagios
  Install directory:                /usr/local/pnp4nagios
  HTML Dir:                         /usr/local/pnp4nagios/share
  Config Dir:                       /usr/local/pnp4nagios/etc
  Location of rrdtool binary:       /usr/bin/rrdtool Version 1.3.1
  RRDs Perl Modules:                FOUND (Version 1.3001)
  RRD Files stored in:              /usr/local/pnp4nagios/var/perfdata
  process_perfdata.pl Logfile:      /usr/local/pnp4nagios/var/perfdata.log
  Perfdata files (NPCD) stored in:  /usr/local/pnp4nagios/var/spool

  Web Interface Options:  -------------------------         -------------------
  HTML URL:                         http://localhost/pnp4nagios/
  Apache Config File:               /etc/apache2/conf.d/pnp4nagios.conf

Comparando estas líneas podemos ver los parámetos que cambian y adoptar una estragegia de actualización.

Las plantillas de de definición de action_url han cambiado. En lugar de ”/nagios/pnp” la URL debería ser ”/pnp4nagios” y en lugar de “index.php” ahora se usa “graph”.

define host {
  name       host-pnp
  register   0
  action_url /pnp4nagios/graph?host=$HOSTNAME$
}

define service {
  name       srv-pnp
  register   0
  action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
}

Las definiciones para las funciones de popup de las previsualizaciones son similares

define host {
   name       host-pnp
   action_url /pnp4nagios/graph?host=$HOSTNAME$' class='tips' rel='/pnp4nagios/popup?host=$HOSTNAME$
   register   0
}

define service {
   name       srv-pnp
   action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$' class='tips' rel='/pnp4nagios/popup?host=$HOSTNAME$&srv=$SERVICEDESC$
   register   0
}

Atención: No es un error que las cadenas que preceden y van depués de “class” contengan una sóla comilla.

Estas plantillas pueden ser usadas con Nagios 2.x y 3.x.

Las variables contenidas en los ficheros de la carpeta de plantillas deben inicializarse antes de ser usadas. Ejemplo

$lower = ""

Las constantes usadas en ficheros de plantillas ya no funcionan, por lo que deberán ser convertidas en variables.

define("_WARNRULE", '#FFFF00');

debe ser cambiado a

 $WARNRULE = '#FFFF00';

Por favor tenga en cuenta que todas deben ser cambiadas .

1. planificar la nueva instalación
2. ejecutar test de instalación con el nuevo sistema
3. realizar una copia de seguridad de la anterior instalación
4. instalar PNP 0.6.x en /usr/local/pnp4nagios
5. make install-config
6. make install-webconf
7. reiniciar Apache
8. comprobar Apache-config
   1. entrando en /pnp4nagios debería reportar un directorio perfdata vacío
9. crear /usr/local/pnp4nagios/etc/npcd.cfg desde npcd.cfg-sample
   1. comprobar las rutas y realizar las adaptaciones de los cambios desde 0.4.x si es necesario
10. ajustar las rutas en nagios.cfg a la nueva instalación de PNP
11. ajustar las rutas en las deficiones de comandos
12. parar npcd usando /etc/init.d/npcd stop
13. make install-init instalar el nuevo init script para npcd
14. /etc/init.d/nagios stop
15. copie /usr/local/nagios/share/perfdata a /usr/local/pnp4nagios/var/perfdata. Atención: compruebe los permisos
16. /etc/init.d/npcd start
17. /etc/init.d/nagios start

La instalación de PNP se describe aquí en más detalle. Se espera que nagios esté compilado desde las fuentes y se localice en /usr/local/nagios.
Atención: La descripción aplica a la versión de desarrollo de PNP 0.6.0.
Tenga en cuenta que PNP debe ser configurado después de la instalación.

La instalación de PNP se controla mediantemakefiles. el sistema se analiza después de la invocación de ./configure y los valores detectados se transfieren a los makefiles.

Descomprima PNP como usuario root:

tar -xvzf pnp4nagios-HEAD.tar.gz
cd pnp4nagios

./configure debe ser llamado desde el directorio pnp4nagios.

./configure

Se ven algunas líneas correr por la pantalla. La salida al final es importante.

*** Configuration summary for pnp4nagios-0.6.0 07-30-2009 ***

  General Options:
  -------------------------         -------------------
  Nagios user/group:                nagios nagios
  Install directory:                /usr/local/pnp4nagios
  HTML Dir:                         /usr/local/pnp4nagios/share
  Config Dir:                       /usr/local/pnp4nagios/etc
  Location of rrdtool binary:       /usr/bin/rrdtool Version 1.2.12
  RRDs Perl Modules:                FOUND (Version 1.2012)
  RRD Files stored in:              /usr/local/pnp4nagios/var/perfdata
  process_perfdata.pl Logfile:      /usr/local/pnp4nagios/var/perfdata.log
  Perfdata files (NPCD) stored in:  /usr/local/pnp4nagios/var/spool

  Web Interface Options:  -------------------------         -------------------
  HTML URL:                         http://localhost/pnp4nagios/
  Apache Config File:               /etc/apache2/conf.d/pnp4nagios.conf


  Review the options above for accuracy.  If they look okay,
  type 'make all' to compile.

Las rutas mostradas deben ser comprobadas. Si los valores mostrados no son los correctos, debería cambiarlos, ejecutando ./configure con los valores apropiados.
Atención: “Location of rrdtool binary” ¡quiere decir que la ruta debe incluir el nombre del binario! Si fuera necesario, se puede especificar usando la siguiente sintaxis:

 ./configure --with-rrdtool=/usr/local/rrdtool-1.2.xx/bin/rrdtool

 ./configure --help 

muestra las opciones soportadas.

Invocando

 make all

se compilan los componentes como NPCD que están escritos en C

 make install

copia todos los elementos a sus lugares correspondientes en el sistema de ficheros. Las rutas se han mostrado previamente durante la etapa de ./configure.

Se puede ejecutar

 make install-config

opcionalmente. De esta forma los ficheros de configuración para process_perfdata.pl y npcd se copian a etc/pnp.

Para instalar el init script de NPCD se debe ejecutar

 make install-init

Todos estos pasos están combinados en

 make fullinstall

volver a contenidos | configuración

Aquí describimos en más detalle la configuración de los modos mencionados modos de procesado de datos de rendimiento.

El modo síncrono es la forma más fácil de integrar en nagios el recolector de datos process_perfdata.pl. Cada evento dispara la ejecución de process-service-perfdata.

Inicialmente hemos debido habilitar el procesado de los datos de rendimiento en nagios.cfg. Tenga en cuenta que esta directiva ya estará presente en el fichero de configuración. El valor por defecto es “0”.

 process_performance_data=1

El procesado de los datos debe ser deshabilitado en la definición de cada equipo o servicio para los que los datos de rendimiento NO deban ser procesados.

define service {
   ...
   process_perf_data 0
   ...
}

Desde la versión Nagios 3.x es posible desactivar la exportación de las variables de entorno (como parte de la optimización del sistema para obtener el máximo rendimiento). Deafortunadamente esta directiva debe estar habilitada para usar el modo síncrono. Por ello debe usar los valores por defecto (export está habilitado) o definir la variable en nagios.cfg

enable_environment_macros=1

Además, el comando para procesar los datos de rendimiento debe especificarse en nagios.cfg

 service_perfdata_command=process-service-perfdata

A partir de Nagios 3.0 it puede ser útil habilitar el procesado de los datos de rendimiento de los equipos. Debido al cambio de lógica de las comprobaciones de los equipos en Nagios 3, ahora se ejecutan regularmente comprobaciones de equipos programadas.

 host_perfdata_command=process-host-perfdata

Nagios debe ser notificado sobre los comandos referenciados. Si ha usado las guías de instalación rápida para Nagios, puede modificar las definiciones en commands.cfg. Se puede observar que la llamada a process_perfdata.pl no requiere de ningún argumento, aparte de especificar la opción -d ( DATATYPE ) si quiere procesar los datos de rendimiento resultantes de las comprobaciones de los equipos.

define command {
       command_name    process-service-perfdata
       command_line    /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl
}

define command {
       command_name    process-host-perfdata
       command_line    /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA
}

Nota process_perfdata.pl no puede ejecutarse bajo el control de ePN ( embedded Perl Nagios ). El script debe ser explícitamente llamado usando /usr/bin/perl ( o donde quiera que esté localizado su binario de perl ). Si usa Nagios 3.x o no usa ePN no hay necesidad de especificar /usr/bin/perl.

El modo masivo es algo más complicado que el síncrono, pero reduce significativamente la carga en el servidor de nagios, debido a que el recolector de datos process_perfdata.pl no es invocada en cada chequeo de servicio/equipo.

En el modo masivo, Nagios escribe los datos a un fichero temporal en un formato predefinido. Este fichero se procesa mediante process_perfdata.pl a intervalos regulares. Nagios controla el arranque y ejecución periódica del recolector de datos.

Se debe habilitar el procesado de datos de rendimiento en nagios.cfg

 process_performance_data=1

Además, otras directivas son necesarias

#
# service performance data
#
service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file

#
# host performance data starting with Nagios 3.0
# 
host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file

Atención: ¡Tenga en cuenta que la definición de esta plantilla puede diferir de las suministradas en nagios.cfg!

Las directivas y su significado:

• service_perfdata_file ruta al fichero temporal que debería alojar los datos de rendimiento.
• service_perfdata_file_template formato del fichero temporal. Los datos se definen usando macros de Nagios.
• service_perfdata_file_mode opción “a” especifica los datos que se van a añadir al fichero.
• service_perfdata_file_processing_interval el intervalo es 15 segundos
• service_perfdata_file_processing_command el comando que se invocará en el intervalo.

Los comandos que se utilizan deben ser configurados en Nagios. Si ha usado las guías de instalación rápida de Nagios, puede modificar las definiciones en commands.cfg.

define command{
       command_name    process-service-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/service-perfdata
}

define command{
       command_name    process-host-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/host-perfdata
}

La configuración es idéntica al modo masivo, excepto por el comanado usado. Se debe habilitar el procesado de datos de rendimiento en nagios.cfg

 process_performance_data=1

Además, otras directivas son necesarias

#
# service performance data
#
service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file

#
# host performance data starting with Nagios 3.0
# 
host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file

Atención: ¡Tenga en cuenta que la definición de esta plantilla puede diferir de las suministradas en nagios.cfg!

Las directivas y su significado:

• service_perfdata_file ruta al fichero temporal que debería alojar los datos de rendimiento.
• service_perfdata_file_template formato del fichero temporal. Los datos se definen usando macros de Nagios.
• service_perfdata_file_mode opción “a” especifica los datos que se van a añadir al fichero.
• service_perfdata_file_processing_interval el intervalo es 15 segundos
• service_perfdata_file_processing_command el comando que se invocará en el intervalo.

Los comandos que se utilizan deben ser configurados en Nagios. Si ha usado las guías de instalación rápida de Nagios, puede modificar las definiciones en commands.cfg.

define command{
       command_name    process-service-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-perfdata.$TIMET$
}

define command{
       command_name    process-host-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-perfdata.$TIMET$
}

Al usar estos comandos, el fichero service-perfdata, es movido a var/spool/ depués del intervalo especificado en service_perfdata_file_processing_interval. La macro de Nagios $TIMET$ se añade al nombre del fichero para evitar la sobreescritura accidental de ficheros anteriores. La macro $TIMET$ contiene el timestamp actual en formaro time_t (segundos desde la época UNIX).

En el directorio /usr/local/pnp4nagios/var/spool/ los ficheros son recuperados y procesados por NPCD.

NPCD monitoriza el directorio spool y le pasa los nombres de fichero a process_perfdata.pl. De esta forma el procesado de los datos de rendimiento está totalmente desacoplado de Nagios.

Antes de iniciar NPCD debe comprobar las rutas al directorio de spool y a process_perfdata.pl en el fichero de configuración npcd.cfg. Lo único que queda es iniciar NPCD.

 /usr/local/pnp4nagios/bin/npcd -d -f /usr/local/pnp4nagios/etc/npcd.cfg

La opción -d inicia NPCD como un demonio en segundo plano.

volver a contenidos | comprobando la funcionalidad

Si todo ha ido bien hasta ahora, está listo para llamar a PNP desde su navegador. Cuando se realiza la instalación con los valores por defecto, PNP debería ser invocado usando http://<server name>/pnp4nagios/.

Cuando se le invoca sin argumentos, PNP busca los ficheros RRD y XML en var/perfdata y muestra todos los gráficos del primer equipo.

ATENCIÓN: Inmediatamente después de (re-)iniciar Nagios, después de haber habilitado el procesado de los datos de rendimiento obtendrá un error en su navegador, debido a que los datos han de ser recolectados y almacenados en ficheros RRD. En función del intervalo de chequeo que esté usando, tendrá que esperar algún tiempo antes de que pueda visualizar los gráficos.

Invocando make install-config durante la instalación crea un fichero ejemplo de configuración etc/process_perfdata.cfg-sample. Los valores de este fichero de ejemplo corresponden a los valores por defecto usados por process_perfdata.pl por lo que normalmente no debería tener un fichero llamado process_perfdata.cfg mientras ejecuta el procedimiento.
En cualquier caso, puede modificar la forma en la que process_perfdata.pl trabaja, cambiando las opciones que se especifican en process_perfdata.cfg.

Las opciones más importantes al lanzar PNP son LOG_LEVEL y LOG_FILE. Recomendamos establecer los valores para LOG_LEVEL a un valor de “2” de tal forma que pueda realizar un seguimiento de lo que hace process_perfdata.pl. Normalmente le preguntaremos sobre las excepciones encontradas en perfdata.log si abre una if you open a petición de soporte en las listas de correo, así como la salida del script verify_pnp_config, por lo que debería proporcionárnoslo .

En un funcionamiento normal, el nivel de debug debería establecerse a 0 para evitar incidencias en el rendimiento debido a un exceso de entradas innecesarias en el fichero de log.

Algunas configuraciones básicas deben ser comprobadas

1. ¿Se han creado ficheros RRD y XML? process_perfdata.pl crea un nuevo directorio en pnp/perfdata por cada equipo. En este directorio una base de datos RRD y un fichero XML se crean por cada servicio. Los datos del equipo se almacenan en _HOST_.xml y _HOST_.rrd respectivamente.
A veces se tienen que especificar opciones de información adicional para que los datos de rendimiento se produzcan. En algunos casos un wrapper script puede ayudar.
De cualquier forma, no todos los chequeos facilitan datos de rendimiento. Esto aplica - entre otros - a “check_ping” en contraste con “check_icmp” que sí que los provee, (a partir de la versión de plugins de Nagios 1.4.12 check_ping ya facilita esa información).
Al usar el interfaz web, la información detallada de equipos/servicios muestra un campo “Performance Data”. Si está vacío, no hay datos disponibles, por lo que no se escribirá ningún fichero en los directorios apropiados y ¡es por esto que PNP no le facilitará ningún tipo de gráfico!
La siguiente imagen muestra la información de un servicio “PING”. La salida del plugin está remarcada en azul, los datos de rendimiento en rojo.

2. ¿Se ha invocado desde Nagios a process_perfdata.pl? En el fichero de configuración de process_perfdata.pl (etc/process_perfdata.cfg) se puede incrementar el nivel de debug. El procesado de los datos será registrado en var/perfdata.log.

3. ¿Se muestran los gráficos sin texto alguno? Eche un vistazo a requerimientos.

4. Puede usar el script verify_pnp_config.pl en el directorio contrib de la carpeta de instalación, o en libexec después de la instalación, para comprobar su configuracióny si los datos de rendimiento están presentes y/o son válidos. La sintaxis es muy simple:

./verify_pnp_config.pl -m <mode>

donde <mode> puede ser “default”, “bulk” o “npcd” (sin las comillas).

volver a contenidos | verify_pnp_config.pl

PNP debería ser fácilmente accesible. Nagios permite que se llamen a URLs externas mediante las configuraciones de extended info. Se describen a continuación tanto para la versión 2.x como para la 3.x debido a los cambios entre las dos ramas de nagios.

Con Nagios 2.x la integración de URLs externas en el interfaz web se realiza mediante los Extended Info Objects para servicios. Para PNP usaremos la directiva action_url para invocar al frontal web de PNP con las opciones apropiadas.

define serviceextinfo {
   host_name             localhost
   service_description   load
   action_url            /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
}

Debe especificar una Extended Info Definition adicional para cada servicio.

Desde nagios 3.0 la directiva action_url se ha cambiado a equipo o definición de servicio. De esta forma se simplifica la definición de URLs al interfaz de PNP. Las definiciones serviceextinfo y hostextinfo son obsoletas ahora.

Primero definimos dos plantillas de nagios. Si ha usado lasguías de instalación rápida de Nagios puede añadir estas líneas a templates.cfg:

define host {
   name       host-pnp
   action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_
   register   0
}

define service {
   name       srv-pnp
   action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
   register   0
}

Estas dos plantillas pueden ser incluídas via “use srv-pnp” o “use host-pnp” para servicios y equipos respectivamente. Si ha seguido las guías rápidas de instalación, ahora puede por ejemplo editar el fichero localhost.cfg y añadir la plantilla para la definición de equipo o servicio de la forma siguiente:

define host{
        use                     linux-server,host-pnp     ; Nombre de la plantilla de equipo a usar
                                                         ; Esta definición de equipo heredará todas las variables
                                                         ; definidas en (o heredadas por) la definición
                                                         ; de plantilla.
        host_name               localhost
        alias                   localhost
        address                 127.0.0.1
        }

define service{
        use                     local-service,srv-pnp   ; Nombre de la plantilla de servicio a usar
        host_name               localhost
        service_description     PING
        check_command           check_ping!100.0,20%!500.0,60%
        }

Los enlaces a las URLs correctas se crean automáticamente.

Se puede integrar PNP en Nagios de una forma en la que se pueden visualizar los gráficos sin tener que hacer click en ningún icono. Esto puede hacerse usando CGI Includes que permiten incluir código JavaScript en la vista de detalle del estado ( status.cgi ).

Prerrequisitos:

• PNP instalado y funcionando
• el file status-header.ssi presente el directorio contrib/ssi/ del paquete PNP debe ser copiado a /usr/local/nagios/share/ssi/.
  Atención: Este fichero NO debe ser ejecutable. Si lo fuera ser trataría como un CGI lo que resultaría en un error.
  *Nota para los admins de Apache*: Apache ssi y Nagios ssi sólo tienen un nombre similar.
• La(s) definición(es) del servicio apropiado tiene que ser modificada. Tenga en cuenta que hasta la versión 2.x de Nagios debe modificar la definición de serviceextinfo (la cual es obsoleta a partir de Nagios 3).

Definición:

define host {
   name       host-pnp
   action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_' class='tips' rel='/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=_HOST_
   register   0
}

define service {
   name       srv-pnp
   action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$' class='tips' rel='/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=$SERVICEDESC$
   register   0
}

Después de reiniciar Nagios (después de modificar las definiciones) el resultado será similar a este:

volver a contenidos | opciones de configuración

El comportamiento del Frontal Web de PNP se controla a través de un fichero de configuración etc/config.php. Este fichero será sobreescrito en actualizaciones de PNP así como las rutas y opciones que sean detectadas en la etapa de ./configure.

Los ajustes personalizados deberían realizarse en etc/config_local.php. Si no existe este fichero, se usarán los valores de config.php.

A continuación se exponen los parámetros más importantes:

La ruta al binario RRDtool. Se detecta por ./configure

 $conf['rrdtool'] = "/usr/bin/rrdtool";

Altura y anchura de los gráficos de RRD

 $conf['graph_width'] = "500";
 $conf['graph_height'] = "100";

Los tamaños de las pantallas pueden variar, los de las páginas no. Las siguientes dos directivasle perimiten especificar diferentes tamaños para la creación de PDFs. Si no se especifican, se toman los valores de los gráficos.

 $conf['pdf_width'] = "675";
 $conf['pdf_height'] = "100";

Opciones adicionales pasadas con cada llamada de RRDTool, por ejemplo --slope-mode para suavizar los gráficos

 $conf['graph_opt'] = "";

La rutas a los ficheros RRD y XML creados por process_perfdata.pl

 $conf['rrdbase'] = "/usr/local/pnp4nagios/var/perfdata/";

La ruta al fichero de configuración para pages.

 $conf['page_dir'] = "/usr/local/pnp4nagios/etc/pages/";

Las páginas de PNP se refrescarán cada n segundos

 $conf['refresh'] = "90";

Max. de edad de los archivos RRD en segundos. Después de alcanzar este valor los enlaces a los gráficos serán marcados como inactivos

 $conf['max_age'] = 60*60*6;

URL base para los CGIs de Nagios

 $conf['nagios_base'] = "/nagios/cgi-bin";

Lista de usuarios permitidos para ver los enlaces a los servicios del equipo actual

 $conf['allowed_for_service_links'] = "EVERYONE";

Lista de usuarios que pueden ver/aceder al campo de búsqueda de equipos

 $conf['allowed_for_host_search'] = "EVERYONE";

Si PNP se llama con un sólo equipo ( index.php?host=<myserver> ), al usuario definido se le muestra una vista general de todos los servicios relacionados con el equipo

 $conf['allowed_for_host_overview'] = "EVERYONE";

Los periodos de tiempo en el que los gráficos RRD se muestran se determinan a través del array $views[]. El título y número de los gráficos pueden especificarse globalmente aquí

$views[0]["title"] = "4 Hours";
$views[0]["start"] = ( 60*60*4 );

$views[1]["title"] = "24 Hours";
$views[1]["start"] = ( 60*60*24 );

$views[2]["title"] = "One Week";
$views[2]["start"] = ( 60*60*24*7 );

$views[3]["title"] = "One Month";
$views[3]["start"] = ( 60*60*24*30 );

$views[4]["title"] = "One Year";
$views[4]["start"] = ( 60*60*24*365 );

Se pueden añadir más vistas ($views[5], …)pero tenga en cuenta que bajo circunstancias normales TODAS las vistas definidas se muestran.

volver a contenidos | intervalos de tiempo

En la vista general PNP muestra cinco intervalos de tiempo que pueden definirse en config.php.

Adicionalmente podemos variar los intervalos de tiempo a través de la URL. Esto puede ser útil para crear automáticamente documentos PDF. Los intervalos se definen usando las opciones “start” y “end”.

Ejemplo:

 pnp4nagios/graph?host=<hostname>&srv=<servicedesc>&start=-1week

El gráfico comenzará una semana antes de la fecha y hora actuales. Finalizará en el momento actual.

Ejemplos de diferentes especificaciones

volver a contenidos | páginas

Las “páginas” facilitan la organización de gráficos de diferentes equipos/servicios en una página. De esta forma - por ejemplo - se pueden mostrar los ratios de tráfico de todas las librerías de cintas. Se pueden usar expresiones regulares para que pueda realizar mucho trabajo con unas pocas definiciones - siempre que tengan los nombres apropiados. El directorio especificado en “$conf['page_dir']” contiene uno o más ficheros con las extensión ”.cfg”.

Los comentarios comienzan con el símbolo de almohadilla (#) y se admiten a mitad de las líneas. Cada fichero contiene una definición de página que especifica el nombre de la página, y determina and que determina si la definición del gráfico contiene expresiones regulares o no.
La descripción detrás de page_name aparecerá en la lista de páginas disponibles y se usará como título en la ventana del navegador. Atención: “host_name” y “service_desc” se refieren al nombre del fichero en el directorio de perfdata, no a la definición de Nagios. Espacios en blanco se sustituyen por guiones bajos (_).

define page {
       use_regex 1		# 0 = no usa expresiones regulares, 1 = usa  expresiones regulares
       page_name test-page	# descripción de página
}

Una o más definiciones de “gráficos” vienen a continuación:

define graph {
       host_name       host1,host2,host3
       service_desc    Current_Load
}

Atención: La lista de nombres de equipos sólo funciona si hemos establecido el valor regex 0!

define graph {
       host_name       host4
       service_desc    Current_Users
}

Y ahora algunas definiciones con expresiones regulares. Todos los nombres de equipos que comiencen por “Tape”:

define graph {
       host_name       ^Tape
       service_desc    Traffic
}

todos los equipos cuyos nombres acaben en “00”:

define graph {
       host_name       00$
       service_desc    Load
}

todos los servicios de localhost cuyos nombres contengan “a” u “o”, respectivamente:

define graph {
       host_name       localhost
       service_desc    a|o
}

todos los servicios cuyos nombres contengan un guión bajo seguido por (al menos) tres dígitos en todos los equipos que comiencen por “UX”:

define graph {
       host_name       ^UX
       service_desc    _\d{3}
}

volver a contenidos | exportar datos

PNP facilita el acceso a los datos RRD usando el controlador xport. El formato de salida se puede especificar. De momento los formatos xml, json y csv están soportados.

El controlador se invoca mediante la URL

/pnp4nagios/xport/<format>?host=<hostname>&srv=<servicedesc>

donde <format> debe ser reemplazado por el formato deseado.

volver a contenidos | plantillas

PNP usa plantillas para modificar la apariencia de los gráficos RRD.

El check_command seleccionado determina qué plantilla será usada para controlar el gráfico. A continuación se describe dónde se almacenan las plantillas y cómo se toma la decisión sobre la plantilla “correcta” que se va a usar.

Las plantillas se almacenan en dos sitios dentro del sistema de ficheros.

• share/templates.dist - para plantillas incluídas en el paquete de PNP
• share/templates - para plantillas personalizadas que no se deben cambiar en las actualizaciones

Si el gráfico para el servicio “http” en el equipo “localhost” debe mostrarse, PNP buscará un fichero XML perfdata/localhost/http.xml y ller sus contenidos. Los ficheros XML se crean automaicamentey contienen información sobre equipos y servicios particulares. La cabecera contiene información sobre el plugin y los datos de rendimiento. La etiqueta XML <TEMPLATE> identifica qué plantilla de PNP se usará para este gráfico.

/localhost/http.xml

<NAGIOS>
  <DATASOURCE>
    <TEMPLATE>check_http</TEMPLATE>
    <DS>1</DS>
    <NAME>time</NAME>
    <UNIT>s</UNIT>
    <ACT>0.006721</ACT>
    <WARN>1.000000</WARN>
    <CRIT>2.000000</CRIT>
    <MIN>0.000000</MIN>
    <MAX></MAX>
  </DATASOURCE>
  <DATASOURCE>
    <TEMPLATE>check_http</TEMPLATE>
    <DS>2</DS>
    <NAME>size</NAME>
    <UNIT>B</UNIT>
    <ACT>263</ACT>
    <WARN></WARN>
    <CRIT></CRIT>
    <MIN>0</MIN>
    <MAX></MAX>
  </DATASOURCE>
...
</NAGIOS>

PNP buscará la plantilla con el nombre check_http.php en el siguiente orden:

1. templates/check_http.php
2. templates.dist/check_http.php
3. templates/default.php
4. templates.dist/default.php

La plantilla default.php tiene una posición especial y se usa cuando no se encuentra ninguna otra opción.

Las plantillas PNP son ficheros PHP que se incluyen durante la ejecución de PNP usando la función PHP include(). Esto significa que cada código PHP en las plantillas será interpretado, por lo que la manipulación de todos los valores es posible.

Una plantilla PNP debe tener las siguientes características:

1. contener código PHP válido.
2. no producir ninguna salida.
3. los dos arrays $opt[] y $def[] debe ser rellenados

Estos dos arrays se usan para invocar 'rrdtool graph' por lo que se puede usar cada opción soportada por RRDtool. Todas las opciones de RRDtool se describen extensamente enRRDtool Homepage.

Si ambos arrays contienen más de un conjunto de datos, se crearán gráficos para cada conjunto de datos.

Dentro de las plantillas se pueden usar los datos relacionados de los ficheros XML.

Usando la relativamente sencilla plantilla response.php vamos a describir las opciones más importantes.

<?php
#
$opt[1] = "--title \"Response Time For $hostname / $servicedesc\" ";
#
$def[1] =  "DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE " ;
$def[1] .= "AREA:var1#00FF00:\"Response Times \" " ;
$def[1] .= "LINE1:var1#000000 " ;
$def[1] .= "GPRINT:var1:LAST:\"%3.4lg %s$UNIT[1] LAST \" ";
$def[1] .= "GPRINT:var1:MAX:\"%3.4lg %s$UNIT[1] MAX \" ";
$def[1] .= "GPRINT:var1:AVERAGE:\"%3.4lg %s$UNIT[1] AVERAGE \" ";
?>

Nota: como el número (1) y la letra “L” parecen iguales en este listado: el formato ”%3.4lg” contiene una pequeña letra.

$opt[1] = ”--title … establece las opciones de RRDtool para el primer conjunto de datos, aquí está el título tal y como se verá. Las comillas incluídas son enmascaradas mediante la barra invertida (\). Las variables $hostname y $servicedesc se determinaron en la llamada a PNP, y están disponibles para la plantilla.

$def[1] = “DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE ”; define qué datos se leerán desde el fichero RRD. $RRDFILE[1] contiene la ruta al fichero RRD para este servicio. $DS[1] hace referencia a la primera serie de datos del fichero RRD.

$def[1] .= “AREA:var1#00FF00:\”Response Times \” ”; el operador ”.=” añade más datos al array $def[1]. Se dibujará un área usando datos desde la variable var1. El color se define en notación HEX #00FF00 (rojo, verde, azul). La etiqueta es “Response Times”.

$def[1] .= “LINE1:var1#000000 ”; Para terminar, se dibuja una línea (LINE1) en negro(# 000000).

$def[1] .= “GPRINT:var1:LAST:\”%3.4lg %s$UNIT[1] LAST \” ”;
$def[1] .= “GPRINT:var1:MAX:\”%3.4lg %s$UNIT[1] MAX \” ”;
$def[1] .= “GPRINT:var1:AVERAGE:\”%3.4lg %s$UNIT[1] AVERAGE \” ”;

Las tres líneas GPRINT generan la leyenda para la gráfica. Los valores actuales se formatean usando la sintaxis de printf.

Al usar el recolector de datos process_perfdata.pl PNP almacena no sólo los datos de rendimiento, sino otros valores exportados por Nagios. Estos valores se almacenan en los ficheros XML asociados a los servicios apropiados.

En la primera parte del fichero XML los datos de rendimiento se almacenan en componentes separados.

<NAGIOS>
  <DATASOURCE>
    <TEMPLATE>check_http</TEMPLATE>
    <DS>1</DS>
    <NAME>time</NAME>
    <UNIT>s</UNIT>
    <ACT>0.006721</ACT>
    <WARN>1.000000</WARN>
    <CRIT>2.000000</CRIT>
    <MIN>0.000000</MIN>
    <MAX></MAX>
  </DATASOURCE>
....
</NAGIOS>

El campo <DS> designa las fuentes de datos y se usa para identificar las series de datos de los ficheros RRD, y además, es la clave de los siguientes arrays.

El array $UNIT[1] contiene la unidad de medida de la primera serie de datos.

El fichero XML contiene otra información. Cuando process_perfdata.pl se usa en el modo por defecto todas las macros disponibles tienen los valores actuales. En benficio de la legibilidad, las siguientes líneas son sólo un extracto.

<NAGIOS>
...
  <NAGIOS_SERVICENOTIFICATIONID>8418</NAGIOS_SERVICENOTIFICATIONID>
  <NAGIOS_SERVICENOTIFICATIONNUMBER>0</NAGIOS_SERVICENOTIFICATIONNUMBER>
  <NAGIOS_SERVICEOUTPUT>HTTP OK HTTP/1.1 200 OK - 10087 bytes in 0.125 seconds</NAGIOS_SERVICEOUTPUT>
  <NAGIOS_SERVICEPERCENTCHANGE>0.00</NAGIOS_SERVICEPERCENTCHANGE>
  <NAGIOS_SERVICEPERFDATA>time=0.124811s;;;0.000000 size=10087B;;;0</NAGIOS_SERVICEPERFDATA>
  <NAGIOS_SERVICEPERFDATAFILE></NAGIOS_SERVICEPERFDATAFILE>
  <NAGIOS_SERVICEPROBLEMID>0</NAGIOS_SERVICEPROBLEMID>
  <NAGIOS_SERVICESTATE>OK</NAGIOS_SERVICESTATE>
  <NAGIOS_SERVICESTATEID>0</NAGIOS_SERVICESTATEID>
  <NAGIOS_SERVICESTATETYPE>HARD</NAGIOS_SERVICESTATETYPE>
  <NAGIOS_SHORTDATETIME>27-12-2007 13:51:23</NAGIOS_SHORTDATETIME>
...
</NAGIOS>

Los diferentes campos XML se pueden usar como variables en las plantillas PNP. Cada campo está disponible como variable con el mismo nombre.

El valor del campo <NAGIOS_SERVICEOUTPUT> está disponible como la variable $NAGIOS_SERVICEOUTPUT.

volver a contenidos | plantillas personalizadas

Como ya se ha descrito en ”¿Qué son las plantillas?” la apariencia de los gráficos depende del comando de chequeo que se haya usado.

Hay situaciones en las que este comportamiento debe ser sobreescrito. Esto se hace cuando se definen comandos universales.

Ejemplo:

define command {
  command_name check_nrpe
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a "$ARG2$"
}

Esto haría que se inovocase la plantilla de check_nrpe.php incluso cuando el equipo monitorizado use un plugin completamente diferente que es llamado desde NRPE.

PNP, especialmente process_perfdata.pl, buscará un fichero de configuración (<check_command>.cfg) en el directorio etc/check_commands y lee sus contenidos (si están disponibles).

Como en nuestro ejemplo el comando se llama desde check_nrpe, se buscará etc/check_commands/check_nrpe.cfg.

En la instalación un fichero ejemplo de configuración con la extensión .cfg-sample se copia a etc/check_commands.

Dos opciones pueden establecerse en este fichero de configuración:

# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5
# ________0__________|       |       |
# ________1__________________|       |
# ________2__________________________|
#
CUSTOM_TEMPLATE = 1

CUSTOM_TEMPLATE = 1 asegura que sólo el contenido de $ARG1$ se usará como nombre de plantilla. Como $ARG1$ contiene “load” en este ejemplo el nombre de plantilla será “load.php”.

CUSTOM_TEMPLATE = 0,1 se convierte en → “check_nrpe_load.php”

CUSTOM_TEMPLATE = 1,0 se convierte en → “load_check_nrpe.php”

La opción “DATATYPE” controla el tipo de dato que se usa en la creación de la base de datos RRD. El valor por defecto es “GAUGE”. Para valores consecutivos, el tipo debería ser “COUNTER”. Los desarrolladores de Plugins deberían usar la unidad “c” para contadores, pero este no es siempre el caso.

Establecer todos los tipos de datos a COUNTER

DATATYPE = COUNTER

Establecer fuentes de datos a diferentes tipos

DATATYPE = GAUGE,GAUGE,COUNTER,COUNTER

Esta opción sólo tiene efecto durante la creación de la base de datos RRD.

Más tipos de datos son detallados en la documentación de RRDTool consultable en rrdcreate.

En unas pocas situaciones, puede ser necesario limitar los valores que son válidos para RRDTool.

Las bases de datos RRD pueden ser creadas con valores mínimos y máximos preestablecidos de forma fija. Más detalles en http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html.

Cuenta para el valor máximo tomado de los datos de rendimiento

USE_MAX_ON_CREATE = 1

Cuenta para el valor mínimo tomado de los datos de rendimiento

USE_MIN_ON_CREATE = 1

volver a contenidos | PNP en entornos distribuidos

Si Nagios se implementa como un sistema distribuido, tiene que decidir dónde se debería instalar PNP.

Desde un punto de vista técnico, esta cuestión no es relevante. PNP se puede instalar tanto en el servidor maestro como en el/los esclavo(s). ¿O sólo en el maestro?

Si PNP se ejecuta en el maestro, debe asegurarse de que los datos pasados a través de send_nsca desde el/los servidor(es) esclavo(s) contienen datos de rendimiento. A menudo otro check command se usa en el maestro.

Para ayudar a PNP a reconocer en el maestro, qué check command se ha usado en el esclavo para recolectar la información, process_perfdata.pl responde a un campo adicional al final de los datos de rendimiento.

OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;; [check_icmp]

Si PNP encuentra una cadena entre corchetes al final de los datos de rendimiento, este valor se usa como check command y como valor para la plantilla PNP.

La documentación de Nagios relativa a este tema se puede encontrar aquí. El comando usado en la documentación es fácilmente adaptable.

define command{
	command_name	submit_check_result
	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
	}

debería cambiarse a

define command{
	command_name	submit_check_result
	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$ | $SERVICEPERFDATA$ [$SERVICECHECKCOMMAND$]'
	}

El plugin check_multi es uno de los primeros plugins que usa las nuevas características de Nagios 3.x. Check_multi puede ejecutar múltiples plugins de Nagios, pero sólo devuelve los resultados como un único servicio. La salida de check_multi se compone de varias líneas para mostrar toda la información.

Esto pone en aprietos a PNP que tiene que extraer la información de datos de rendimiento de varios plugins. En colaboración con Matthias Flacke, desarrollador de check_multi, se ha encontrado una solución para asignar los datos a los plugins apropiados.

volver a contenido | soporte de rrdcached

En instalaciones grandes, más pronto o más tarde, se observará que el procesamiento de los datos de rendimiento se traduce en una carga relativamente alta de E/S. RRDtool necesita hacer cambios con frecuencia en los archivos de disco, pero no puede utilizar la caché de disco de una manera óptimas.

Se ha hecho una mejora en la recolección y clasificación de los datos. Es más efectivo escribir muchas actualizaciones a una base de datos RRD en un sólo bloque. La caché de disco puede ser así usada de forma más eficiente.

La herramienta RRDtool actual ( SVN trunk 1550+ ) contiene rrdcached que mejora esta situación de la manera descrita anteriormente.

En este punto me gustaría dar las gracias a Florian octo Forster, Kevin Brintnall y Tobi Oetiker. El desarrollo de este demonio ha sido coordinado de forma ejemplar en la lista de correo rrd-developers.

El demonio rrdcached trabaja en segundo plano y abre un socket UNIX o TCP esperando peticiones de rrdtool.

rrdcached procesa algunas opciones importantes pasadas en el inicio del mismo.

Opción -l define el socket en el que escuchará el demonio para peticiones de actualización. El puerto TCP por defecto es 42217.

-l unix:/path/to/rrdcached.sock
-l 127.0.0.1
-l 127.0.0.1:8888

Opción -L es un socket sin privilegios que sólo dispara el comando FLUSH para escribir a las bases de datos RRD mediante el demonio.

-L 127.0.0.1

Opción -w especifica el intervalo (en segundos) en la que los datos debe ser escritos a disco.

-w 1800

Opción -z define el máximo retraso que se usará para extender los ciclos de escritura sobre un cierto rango [0-delay] para evitar accesos de escritura en paralelo. El valor de -z no debe ser mayor que el de -w.

-z 1800

Opción -p define el fichero PID

-p /var/run/rrdcached.pid

Opción -j define la ruta a un directorio con journaling. Todas las peticiones serán grabadas, de tal forma que se puedan procesar en caso de reinicio por un fallo del demonio.

-j /var/cache/rrdcached

Estas opciones harían que llamásemos a rrdcached con los siguientes parámetros

 rrdcached -w 1800 -z 1800 -p /tmp/rrdcached.pid -j /tmp -l 127.0.0.1

RRDtool es informado del demonio mediante la opción --daemon=<socket>.

 rrdtool --daemon=127.0.0.1 update ...

¡Por supuesto esto debe corresponder con las opciones de rrdcached!

Debido a que dos componentes de PNP tieneN que ser preparados para el uso de rrdcached se tienen que realizar cambios en dos archivos de configuración.

1. Ajuste en process_perfdata.cfg para el recolector de datos process_perfdata.pl

# EXPERIMENTAL rrdcached Support
# Use only with rrdtool svn revision 1511+
#
RRD_DAEMON_OPTS = 127.0.0.1:8888

2. Ajustes de config_local.php (o config.php) para el interfaz web

#
# EXPERIMENTAL rrdcached Support
# Use only with rrdtool svn revision 1511+
#
# $conf['RRD_DAEMON_OPTS'] = 'unix:/tmp/rrdcached.sock';
$conf['RRD_DAEMON_OPTS'] = '127.0.0.1:8888';

Los ficheros de ejemplo contienen las opciones relevantes.

volver a contenidos | Detalles de NPCD

NPCD (Nagios-Perfdata-C-Daemon) ha sido escrito para facilitar un método asíncrono para el manejo de los datos de rendimiento con nagios.

En grandes instalaciones con nagios, la latencia media de los chequeos puede incrementarse hasta valores no aceptables. Esto quiere decir que Nagios deberá realizar un chequeo en un momento x pero realmente lo hace y segundos más tarde.

Si le decimos al core de Nagios que queremos procesar los datos de rendimiento después de cada chequeo, se soportará una cierta cantidad, pero más allá de estos límites empezaremos a tener problemas de latencia.

Para reducir el número de acciones por cada chequeo, podemos usar el Modo Masivo que obtiene datos durante algún tiempo y entonces le dice a Nagios que ejecute el <host|service>_perfdata_file_processing_command o podemos decirle a Nagios que mueva los perfdata_files a un directorio de spool.

Esta última acción es muy rápida, por lo que el tiempo de bloqueo de Nagios es mínimo, por lo que puede seguir haciendo lo que debería: ejecutar otros chequeos, envío de notificaciones, etc.

Como hemos mencionado anteriormente, el proceso de Nagios termina su trabajo al mover los ficheros de datos de rendimiento, pero con esto no hemos convertido estos datos en ficheros RRD.

Para esta tarea podemos ejecutar npcd que busca en el directorio de spool y ejecuta una acción por cada fichero que haya encontrado.

Después de que NPCD se ejecuta crea una lista de ficheros encontrados en perfdata_spool_dir y lanza nuevos hilos de ejecución por cada fichero, ejecutando el comando perfdata_file_run_cmd con el argumento opcional perfdata_file_run_cmd_arg.

Ya que los ficheros de perfdata que están en el directorio de spool están en el mismo formato que para el modo masivo, NPCD ejecutará process_perfdata.pl en Modo Masivo.

Ventajas:

• Mejora del rendimiento de Nagios
  • debido al desacoplamiento del core de Nagios respecto del procesado de datos de rendimiento.
• No se pierden datos de rendimiento
  • en el momento en que Nagios escribe los ficheros de perfdata en el spool, los datos no se pierden incluso en caso de fallo de NPCD, o si hemos “olvidado” arrancar NPCD después de un reinicio del sistema. NPCD arrancará la próxima vez con el primer fichero que encuentre (están ordenados por la macro $TIME_T$ en orden cronológico) y actualizará los ficheros RRD.

Desventajas:

• no se hace un procesado en tiempo real de los datos de rendimiento
  • debido al retraso existente en la escritura de los datos por Nagios (service_perfdata_file_processing_interval)
  • existe otro retraso debido a que NPCD espera hasta 10 seconds para re-escanar el directorio de spool

Para controlar NPCD, tiene un fichero de configuración propio del que se suministra un ejemplo, npcd.cfg-sample.

Renómbrelo a npcd.cfg para arrancar NPCD de esta forma:

/usr/local/pnp4nagios/bin/npcd -f /usr/local/pnp4nagios/etc/npcd.cfg

o

/usr/local/pnp4nagios/bin/npcd -d -f /usr/local/pnp4nagios/etc/npcd.cfg

para ejecutarlo como demonio (background).

Truco: Si no renombra el fichero de configuración, éste puede ser sobreescrito por futuras actualizaciones de PNP.

Estas son las directivas de configuración esenciales para NPCD:

# Privilege Options
user = nagios
group = nagios

# Logging Options
log_type = syslog
log_file = /usr/local/pnp4nagios/var/npcd.log
max_logfile_size = 10485760
log_level=0

# Processing Options
perfdata_spool_dir = /usr/local/pnp4nagios/var/spool/
perfdata_file_run_cmd = /usr/local/pnp4nagios/libexec/process_perfdata.pl
perfdata_file_run_cmd_args = -b

# Thread Options
npcd_max_threads=5

# greedy options
use_load_threshold = 0
load_threshold = 10.0

# Process Options
pid_file=/var/run/npcd.pid

• Opciones de Privilegios
  • user <username>
    • NPCD tries to drop 'root' privileges to switch to this user.
    • default: nagios
  • group <groupname>
    • NPCD tries to drop 'root' privileges to switch to this group.
    • Default: nagios
• Opciones de Log
  • log_type <syslog> or <file>
    • Log type that is uses by NPCD
    • Default: syslog
  • log_file </path/to/filename>
    • if log_type = file this will be the logfile used
    • Default: /usr/local/pnp4nagios/var/npcd.log
  • max_logfile_size <bytes>
    • NPCD will rotate the logfile if the filesize of the current log is above this limit
    • Default: 10485760 = 10 MByte
  • log_level <integer>
    • how much to log, possible values:
      • 0 = No Log - except errors
      • 1 = small Log - some more output
      • 2 = more Log (actual ALL log messages)
      • -1 = DEBUG Mode - ALL Logs and slower processing for debugging purposes
    • Default: 0
• Opciones de procesado
  • perfdata_spool_dir </path/to/spool/dir/>
    • The directory where the perfdata file should be found
    • Default: /usr/local/pnp4nagios/var/spool/
  • perfdata_file_run_cmd </path/to/bin/filename>
    • This is the script/binary that NPCD will execute
    • Default: /usr/local/pnp4nagios/libexec/process_perfdata.pl
  • perfdata_file_run_cmd_args <option>
    • El argumento que se añade a perfdata_file_run_cmd
    • Defecto: ”-b”
    • La linea de comando será como ésta:

      <perfdata_file_run_cmd> <perfdata_file_run_cmd_args> <filename_from_perfdata_spool_dir>

• Opciones de hilos de ejecución
  • npcd_max_threads <integer value>
    • Define cuántos hilos paralelos deberían ejecutarse
    • Defecto: 5
• Opciones de Greedy
  • use_load_threshold <0 or 1>
    • define si NPCD no debería arrancar nuevos hilos de ejecución si la carga del sistema es muy alta
      • 0 = disable
      • 1 = enable
    • Defecto: 0
  • load_threshold <float value>
    • si use_load_threshold se establece a 1 este límite de carga no será excedido
    • Defecto: 10.0
• Opciones de procesado
  • pid_file </path/to/pid.file>
    • la ruta al fichero PID
    • Defecto: /var/run/npcd.pid

volver a contenidos | wrapper script