Menue
- PNP4Nagios 0.4.x
- PNP4Nagios 0.6.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 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.
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.
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.
Aquí describimos en más detalle la configuración de los modos mencionados modos de procesado de datos de rendimiento.
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.
En caso de problemas hay un script que se llama verify_pnp_config.pl ubicado en el directorio de scripts. Este script le permite comprobar los valores de configuración, así como los datos de rendimiento de equipos o servicios. Puede usarse antes y durante la ejecución de PNP.
* Nota *: La información que aplica a verify_pnp_config v0.1.16 está disponible en la versión actual de desarrollo (comenzando con la Rev. 644 de SVN) descargable via http://www.pnp4nagios.org/pnp/dwnld.
Versiones anteriores pueden tener menos opciones por lo que en la descripción de las opciones encontrará indicios de las versiones de PNP.
* Nota *: Las opciones “long” siempre comienzan con dos ”-” lo que no es claramente visible en el texto.
La comprobación de las configuraciones puede hacerse ejecutando
./verify_pnp_config.pl -m <mode>
sustituyendo <mode> por default, bulk o NPCD. Tenga en cuenta que default corresponde al modo síncrono, bulk al masivo, y NPCD al NPCD.
Especificando la opción -h o –-help muestra respectivamente las siguientes líneas:
-h, --help print these lines
-b, --basedir=s Nagios Base directory (default: /usr/local/nagios)
-B, --binary=s Nagios binary (default: nagios)
-c, --config=s Nagios main config file (default: /usr/local/nagios/etc/nagios.cfg)
-m, --mode=s PNP mode ("default", "bulk", "NPCD")
-l, --logfile=s check configure log file
-N, --npcdcfg=s PNP config file for NPCD mode (default: /usr/local/pnp4nagios/etc/pnp/npcd.cfg)
-P, --ppcfg=s process_perfdata config file (default: /usr/local/pnp4nagios/etc/pnp/process_perfdata.cfg)
-C, --cpcfg=s PNP config file (config.php)
-p, --precheck use config files instead of objects cache
-r, --rrdtool=s specify the location of the RRDtool binary
-R, --RRDpath=s specify the perfdata directory (default: /usr/local/pnp4nagios/var/perfdata) or "no" for no check
-U, --resource=s location of the resource config file (default: /usr/local/nagios/etc/resource.cfg)
-M, --monitor=s specify the monitoring product (default: nagios; may be "icinga")
-L, --layout=s specify a layout (Nagios2, Nagios3, SuSE, Fedora)
-T, --template=s specify the path to the templates directory (default /usr/local/pnp4nagios/share/templates.dist)
-u, --user=s user of the perfdata directory
-g, --group=s group of the perfdata directory
-q, --quiet quiet mode, non-zero return code will indicate errors
-o, --object=s Nagios object (host name, service description)
-n, --native show messages in native language (so far "es" or "de")
-e, --english show english messages/links
-d, --debug some debugging output
El programa de Nagios y el acceso al archivo de configuración principal son siempre necesarios. Si tiene rutas no estándar debido a que ha instalado un paquete precompilado de Nagios, puede intentar usar una de las configuraciones predefinidas mediante la opción -L. “suse” y “fedora” deberían funcionar en las distribuciones apropiadas, mientras que “nagios2” y “nagios3” deberían hacerlo en el resto dependiendo de la versión de Nagios que haya instalado. Si ninguno de los métodos mencionados funciona, aún puede usar tres opciones (-b, -B and -c) para especificar el directorio base de nagios, el nombre del binario y el lugar del fichero de configuración principal. Si el nombre del programa ocmienza con una ”/” entonces este valor se toma como una ruta absoluta no modificable a posteriori. Si no comienza con ”/” entonces la ubicación es relativa, componiéndose del directorio base, la cadena “bin” y el binario. Usando -U se puede especificar la ubicación del fichero de configuración de recursos.
Si no se han especificado opciones, se muestra la página de ayuda, de tal forma que tenga información para especificar el modo u objeto.
Usando la opción -m (–mode) se especifica uno de los modos de PNP para comprobar esos valores. La opción -l <filename> (–logfile=<filename>) permite comprobar la configuración necesaria durante la instalación de PNP. Tiene que ejecutar ./configure (con las opciones adicionales necesarias) antes de que se cree el ficheroconfig.log. Este nombre se debe pasar como parámetro. El script comprueba si los requerimientos de software son correctos y si algunos valores de configuración han sido especificados correctamente. Esto incluye una invoación al binario de RRDtool por lo que se debería usar la opción -r <location> (–rrdtool <location>) si el binario no se encuentra en /usr/bin/rrdtool.
El script comprueba si el propietario y el grupo de los directorios y ficheros que están por debajo del directorio de perfdata corresponden a los valores presentes en nagios.cfg. Además, los ficheros xml se comprueban para los valores de retorno (que no sean 0) de RRDtool. Usando la opción -R (–RRDpath) se especifica el directorio donde los ficheros de RRD están ubicados, si tienen una localización no estándar. Si no desea que estas comprobaciones se realicen, especifique “no” como nombre de directorio. Usando las opciones -u (–user) y -g (–group) se puede especificar el usuario/grupo del directorio de perfdata si éstos no coinciden con los valores del usuario de nagios.
Después de la instalación, los cambios en nagios.cfg se pueden comprobar usando la opción -p (–precheck) antes de reiniciar nagios. De esta forma, puede corregir cualquier error sin necesidad de reiniciar cada vez.
Junto con la opción-o <object> (–object=<object>) se puede especificar una cadena que se compare con los nombres de equipos y/o las descripciones de los servicios en el fichero de caché de objetos. La cadena debería estar entrecomillada para escapar los espacios en blanco y otros caracteres especiales.
Si la cadena coincide con el nombre y cualquier dato de rendimiento, se mostrará. Si no se mostrarán los pertinentes mensajes de información.
Añadiendo un punto y coma a la cadena, obtendremos que sólo se compararan los nombres de los equipos, si el punto y coma se pone al principio de la cadena, sólo se inspeccionan las descripciones de los servicios. Un punto y coma dentro de la cadena, separa el nombre del equipo y la descripción del servicio.
Cuando use el modo NPCD puede utilizar -N <config file> (–npcdcfg=<config file>) para especificar la ubicación del fichero de configuración si su nombre o ubicación difiere de los valores por defecto (/usr/local/pnp4nagios/etc/npcd.cfg).
Usando la opción -P <config file> (–ppcfg=<config file>) puede especificar el nombre del fichero de configuración para process_perfdata.pl si su nombre o ubicación difiere de los valores por defecto (/usr/local/pnp4nagios/etc/process_perfdata.cfg).
Usando la opción -M (–monitor) le permite especificar el producto que entrega los datos a PNP. El defecto es “nagios” pero “icinga” está soportado también. Adicionalmente puede querer usar las opciones -b, -B y -c.
Algunas veces, los cambios en las plantillas generan un error que es difícil de encontrar mediante la GUI web. Usando la opción -T las plantillas se comprueban en busca de errores. Especifique la ruta al directorio de plantillas como parámetro.
Usando -n (–native) se puede especificar “es” o “de” para ver los mensajes en español o alemán, respectivamente.
La opción -e (–english) fuerza el uso de los mensajes en inglés si el script detecta valores de otros lenguajes para los que tenga traducción.
La opción -d (–debug) mostrará líneas adicionales de información que podrían ser útiles en el proceso de localizar probemas, donde -q (–quiet) elimina todos los mensajes. Los errores se mostrarán con un valor de retorno distinto de cero.
Cada línea de información comienza con una letra que identifica el tipo de información mostrada:
[I] mensaje de información sobre los valores de configuración, cosas a ser realizadas, …
[A] acciones que deben ser realizadas
[W] mensaje de aviso
[E] mensaje de error: PNP no funcionará si no se resuelve el(los) problema(s)
[H] sugerencia: valdría la pena leer la documentación apropiada
[D] mensaje de depuración, esperamos que se muestre el origen de su problema
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.
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.
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.
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.
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$]'
}
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.
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.
check_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}'`
echo $LINE \| procs=$COUNT
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: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN201