Menu
- PNP4Nagios 0.6.x
- PNP4Nagios 0.4.x
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
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.
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.
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.
El modo que debe elegir dependerá del tamaño de su instalación de Nagios. Encontrará detalles en la documentació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 .
/usr/local/pnp4nagios
/pnp4nagios
debería reportar un directorio perfdata vacío/usr/local/pnp4nagios/etc/npcd.cfg
desde npcd.cfg-sample
/etc/init.d/npcd stop
make install-init
instalar el nuevo init script para npcd/etc/init.d/nagios stop
/usr/local/nagios/share/perfdata
a /usr/local/pnp4nagios/var/perfdata
. Atención: compruebe los permisos/etc/init.d/npcd start
/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
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 segundosservice_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 }
NOTA:
process_perfdata.pl
tardará más en realizar su tarea, por lo que debería comprobar el valor de TIMEOUT en etc/process_perfdata.cfg
y ajustarlo adecuadamente.
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 segundosservice_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.
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).
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:
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:
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.
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.
start | end | view | result |
---|---|---|---|
todas las vistas finalizan en el momento actual | |||
x | todas las vistas comienzan en la fecha definida | ||
x | todas las vistas terminan en la fecha definida | ||
x | x | una vista entre dos fechas | |
x | una vista que acaba en el momento actual | ||
x | x | una vista que comienza en una fecha definida | |
x | x | una vista que acaba en una fecha definida |
Ejemplos de diferentes especificaciones
formato | descripción |
---|---|
2009W04 | 4. semana de 2009 |
1.5.2009 | 1 May 2009 |
-1 day | un día atrás |
-3 weeks | 3 semanas atrás |
-1 year | un año atrás |
yesterday | ayer |
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} }
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.
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.
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:
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:
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
.
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
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.
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.
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:
Desventajas:
Nagios
(service_perfdata_file_processing_interval
)
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
log_type = file
this will be the logfile used<perfdata_file_run_cmd> <perfdata_file_run_cmd_args> <filename_from_perfdata_spool_dir>
use_load_threshold
se establece a 1 este límite de carga no será excedidocheck_procs es un ejemplo de plugin que no devuelve datos de rendimiento:
./check_procs -a ndo2db -w 1: -c 0: PROCS OK: 2 processes with args 'ndo2db'
Esto se puede cambiar con la ayuda del siguiente wrapper script
check_procs.sh
#!/bin/bash LINE=`/usr/local/nagios/libexec/check_procs $*` RC=$? COUNT=`echo $LINE | awk '{print $3}'` PROCS=`expr $COUNT - 1` LINE=`echo $LINE | sed "s/: $COUNT /: $PROCS /"` echo $LINE \| procs=$PROCS exit $RC
Ahora obtendrá el número junto con la etiqueta requerida
./check_procs.sh -a ndo2db -w 1: -c 0: PROCS OK: 2 processes with args 'ndo2db'| procs=2
2.6. Datos de rendimiento
Los datos de rendimiento son definidos por Nagios como “cualquier cosa después de | en los valores de salida del plugin” - refiérase a la documentaación de Nagios para información sobre la captura de estos datos a ficheros log. De cualquier forma, es responsabilidad del escritor del plugin, asegurar que los datos de rendimiento están en el formato esperado. Este es el formato esperado:
'etiqueta'=valor[UOM];[warn];[crit];[min];[max]
Notas:
Corresponde a los programas de terceros convertir los datos de rendimiento de los plugins de Nagios en gráficos.
Origen: https://www.monitoring-plugins.org/doc/guidelines.html#AEN200