NSCLIENT++. Instalación y configuración básica.




La página de nsclient++… la verdad es que está un poco desordenada y cuesta encontrar la documentación correcta. En el directorio de instalación del cliente incluye un par de pdf con una documentación similar con lo que necesitamos para configurar el agente y los chequeos con Nagios.
Bajamos nsclient++ de su página y lo instalamos en nuestro Windows. En nuestro caso probamos la versión NSCP-0.4.1.90-Win32.
Al instalar elegimos “Custom Setup” y nos selecciona todos los componentes para instalar (luego puedes desactivarlos en el fichero de configuración).
Configuramos el servidor de Nagios que se podrá conectar y si queremos, una password. También los módulos a instalar (una vez sepamos lo que necesitamos instalaríamos solo lo necesario o lo desactivaríamos posteriormente).

El instalador nos crea un servicio “NSClient++”, como automático y nos lo inicia (proceso nsc). Nsclient funciona por defecto en los puertos 5666 (check_nt), 12489 (nrpe) y escucha en todas las IPs.
netstat -an | find "5666"
 TCP 0.0.0.0:5666 0.0.0.0:0 LISTENING
 TCP [::]:5666 [::]:0 LISTENING
netstat -an | find "12489"
 TCP 0.0.0.0:12489 0.0.0.0:0 LISTENING
 TCP [::]:12489 [::]:0 LISTENING
De hecho también nos crea la regla en nuestro Firewall de Windows para permitir que el programa responda. Verificad en cualquier caso. Tened en cuenta que la password proporcionada solo es para el módulo de chequeo check_nt, no para el resto. Lo mejor es siempre configurar el Firewall del equipo para que solo acepte conexiones para los puertos de nsclient++ desde el servidor de Nagios. Además esa pass creo recordar no va encriptada (aunque tiene un método para “ofuscarla”).
En la instalación por defecto “C:\Program Files\NSClient++” podemos ver:
nscp.exe El binario que ejecuta como servicio pero que también podemos usarlo modo comandos para realizar pruebas y configuraciones.
nsclient.ini El archivo de configuración reducido. El que usa por defecto.
nsclient-full.ini El archivo de configuración extendido. Incluye todas las secciones
*.pdf Manuales un tanto desactualizados
DIR Scripts Pues eso…
DIR modules Todos los módulos que incluye y puede usar el programa (como dlls).

Intalación de check_nt y check_nrpe en Nagios.

De momento nos vamos a nuestro servidor de Nagios para probar e instalar si fueran necesarios los plugins para chequear servicios en un equipo Windows con el agente nsclient++. Luego volvemos a la configuración del cliente.
Si seguimos las instrucciones de instalación del artículo de instalación en Centos / Redhat 6.4 ya tendremos instalados ambos plugin (/usr/lib64/nagios/plugins/). Si no, podemos instalarlos: yum install nagios-plugins-nt nagios-plugins-nrpe.Si nos gusta más Debian / Ubuntu y seguimos el artículo correspondiente también deberíamos tener ambos instalados. Podría faltarnos nrpe:apt-get install nagios-nrpe-plugin
Si nos gusta OMD… pues también los tendremos ya de serie en su directorio de plugins.
Probaremos desde el servidor de Nagios, siempre en línea de comandos y omitiendo rutas.

Probando check_nt

check_nt -H 192.168.1.33 -v UPTIME -p 12489 -s pass
System Uptime - 0 day(s) 8 hour(s) 30 minute(s)
Con check_nt hay que darle el Puerto y la pass que le pusimos durante la instalación (que vale solo para check_nt, no para nrpe y está en el ini de configuración).Podemos ver la ayuda con “check_nt –h”. Algo más interesante con check_nt:
check_nt -H 192.168.1.33 -v CPULOAD -l 60,90,95 -p 12489 -s pass
CPU Load 2% (60 min average) | '60 min avg Load'=2%;90;95;0;100

check_nt -H 192.168.1.33 -v USEDDISKSPACE -l c -w 80 -c 90 -p 12489 -s pass
c:\ - total: 488,28 Gb - used: 226,80 Gb (46%) - free 261,48 Gb (54%) | 'c:\ Used Space'=226,80Gb;390,63;439,45;0.00;488,28

check_nt -H 192.168.1.33 -v SERVICESTATE -l AVP,wuauserv -p 12489 -s pass
OK: All services are in their appropriate state.
Estos son sencillos y se entienden, podemos chequear memoria, procesos concretos en ejecución, uptime, discos, cpu, servicios y contadores de Windows (muy útil estos porque hay muchas aplicaciones que crean contadores y puedes monitorizar ciertas cosas interesantes sobre estas por medio de los contadores). Estos chequeos de check_nt funcionan tal cual, no es necesario configurar nada en el ini del cliente. De todas formas… es mejor usar nrpe del que a continuación se habla. Se puede hacer lo mismo y más que con check_nt (de hecho llama a los comandos de este realmente cuando los usas mediante nrpe), es más seguro (ssl) y tiene muchas más funcionalidades. De hecho… desactiva ya mejor check_nt en el nsclient.ini 🙂
NSClientServer = 0

 Probando check_nrpe

check_nrpe -H 192.168.1.33
 I (0,4,1,90 2013-02-04) seem to be doing fine...
Algunos chequeos con check_nrpe (usando el comando “alias” predefinido en el fichero ini donde estarán también los intervalos de alerta por defecto):
check_nrpe -H 192.168.1.33 -c alias_disk
 WARNING: D:\: Total: 117G - Used: 105G (90%) - Free: 11.7G (10%) < warning|'C:\ %'=54%;10;5 'C:\'=226.8G;48.82;24.41;0;488.28 'D:\ %'=10%;10;5 'D:\'=105.49G;11.71;5.84999;0;117.18 'E:\ %'=80%;10;5 'E:\'=67.2G;32.9;16.45;0;329.03 'G:\ %'=46%;10;5 'G:\'=322.97G;59.61;29.8;0;596.1 'M:\ %'=31%;10;5 'M:\'=681.56G;98.41;49.2;0;984.1

check_nrpe -H 192.168.1.33 -c alias_cpu
OK CPU Load ok.|'5m'=10%;80;90 '1m'=11%;80;90 '30s'=14%;80;90

./check_nrpe -H 192.168.1.33 -c alias_mem
OK: physical memory: Total: 3.25G - Used: 2.23G (68%) - Free: 1.02G (32%), virtual memory: Total: 2G - Used: 336M (16%) - Free: 1.67G (84%), paged bytes: Total: 6.5G - Used: 3.01G (46%) - Free: 3.49G (54%), page file: Total: 6.5G - Used: 3.01G (46%) - Free: 3.49G (54%)|'physical memory %'=68%;80;90 'physical memory'=2.23G;2.58999;2.91999;0;3.24 'virtual memory %'=16%;80;90 'virtual memory'=336.47M;1638;1843.08;0;2047.87 'paged bytes %'=46%;80;90 'paged bytes'=3G;5.19;5.83999;0;6.49 'page file %'=46%;80;90 'page file'=3G;5.19;5.83999;0;6.49
Estos chequeos funcionan porque existen en el fichero de configuración (nsclient.ini) del cliente la definición de los alias (alias_xxxx). La sintaxis es muy clara –c COMANDO –a OPCION1 OPCION2 …
Ahora pasándoles parámetros con “-a” (vemos que hay alias que requieren parámetros):
check_nrpe -H 192.168.1.33 -c alias_cpu_ex -a 50 60
 Exception processing request: Request contained arguments (not currently allowed, check the allow arguments option).
Ops… un horror!!!! Modificamos en el fichero ini del cliente y añadimos al final (buscamos la sección correspondiente [], si no está la ponemos también entonces):
[/settings/NRPE/server]
 allow arguments = true
 [/settings/external scripts]
 allow arguments = true
Vemos que el mismo valor se usa para varias secciones NRPE, check_nt, scrips externos,… Si queremos habilitar argumentos usando esos tendremos que habilitarlo en su respectiva sección. Para aclararnos podemos mirar el ini extendido nsclient-full.ini (que no se usa pero tiene todos los valores posibles parece) y cortar y pegar en el ini que si aplica, nsclient.ini.
Me llama la atención la nueva sintaxis para nombrar las cabeceras de las secciones (para mí son nuevas, hacía tiempo que no lo usaba 🙂 ). En cualquier caso con la sintaxis antigua parece que también funciona. Probamos de nuevo con argumentos:
check_nrpe -H 192.168.1.33 -c alias_cpu_ex -a 50 60
 OK CPU Load ok.|'5m'=0%;50;60 '1m'=2%;50;60 '30s'=4%;50;60
 check_nrpe -H 192.168.1.33 -c alias_process -a proceso_fulano
 CRITICAL: proceso_fulano: stopped < critical|'proceso_fulano'=0;0;1
Hay que tener en cuenta que el uso de argumentos supone un posible problema de seguridad según nos indican en la documentación. Si los usamos debemos proteger el cliente Windows con su firewall para que solo use el puerto nrpe el host de Nagios. En cuanto a que es mejor, definir los intervalos de alerta en el cliente o en el chequeo desde Nagios… pues como siempre, depende. Si los defines en el cliente puedes tener en Nagios un grupo de Host específico al que le apliques el mismo chequeo de servicio, sin distinguir intervalos/opciones. Es una ventaja ya que los intervalos de Warning /Crítical pueden variar dependiendo del tipo de Host. Por otro lado si los tenemos en la definición de los objetos en Nagios está todo más a mano, no es necesario acceder a los hosts para cambiarlo/revisarlo y siempre está el dato en Nagios, pero probablemente tendremos que llamar a muchos servicios de host de forma individual porque tengan unos intervalos distintos, en lugar de asignárselo a un grupo de Host y pista.
Mediante NRPE se amplía el abanico de chequeos además de los habituales, chequeo de espacio de ficheros/ directorios, sobre propiedades de ficheros, valores de WMI, event logs, fichero logs, … Otros ejemplos:
Algunos comandos más interesantes:
Avísame si mi fichero de logs “C:\SOFWARE\LogMyApp.exe se pasa de tamaño:
check_nrpe -H 192.168.1.33 -c CheckFileSize -a ShowAll MaxWarn=1024K MaxCrit=4096K File=c:\\SOFTWARE\\LogMyApp.exe
 CRITICAL: c:\SOFTWARE\LogMyApp.exe: 15.4M > critical|'c:\SOFTWARE\LogMyApp.exe'=15.3M;1;4
OJO: para que funcione bien el tema de las rutas de ficheros vemos que hay que duplicar (escapar) la barra de directorio. Pero para que es o funcione debemos activa en nuestro ini del cliente:
[/settings/NRPE/server]
 allow nasty characters = true
Avísame si se me sale de madre mi directorio… p.e. c:\Temp
check_nrpe -H 192.168.1.33 -c CheckFileSize -a ShowAll MaxWarn=1024M MaxCrit=4096M File:_WIN=c:\\Temp\\*.*
 OK: _WIN: 5.46M|'_WIN'=5.45M;1024;4096
Así como verificar el tamaño de ficheros puede ser interesante (logs, dbs,…), el tema de los directorios es más delicado. Si pruebas con directorios grande te dará un timeout el plugin ya que lógicamente el Windows tiene que ponerse a ello. Quizá se pueda aumentar el timeout pero no me tiene mucho sentido estresar a los sistemas así.
Hay que ser muy fino probando los checks con la sintaxis, si te devuelve 0 bytes es que has puesto algo mal.
Chequear contadores de Windows.
Podemos también preguntar por el valor de cualquier contador Windows. Para ubicar bien sus nombres podemos usar el Monitori de rendimiento de Windows. Los buscamos, los añadimos y luego vemos claramente cual es su ruta completa.
check_nrpe -H 192.168.1.33 -c CheckCounter -a "Counter:proc=\\Procesador(_Total)\\% de tiempo de procesador" ShowAll
 OK: proc: 10.3046|'proc'=10.30455
Otro ejemplo de uso de consulta de valores WMI. Chequear la carga en todas las CPUs.
check_nrpe -H 192.168.1.33 -c CheckWMIValue -a "Query=Select * from win32_Processor" MaxWarn=50 MaxCrit=80 Check:CPU=LoadPercentage ShowAll=long
 OK: Everything seems fine.|'CPU'=31;50;80

Modo test.

Si algo va mal o incluso para probar ciertos comandos previamente siempre podemos usar el cliente en Windows directamente. Tiene un montón de opciones de debug y de inyección de comandos directos. Siempre tenemos que parar el servicio primero si usamos el modo test/debug. Por ejemplo:
net stop nscp
nscp.exe test
En ese momento podemos o bien “injectar” el comando a ejecutar (escribir directamente su alias, p.e.: alias_cpu) o ejecutar el comando nrpe correspondiente desde Nagios y ver en el modo debug como le llega al cliente y que hace con él.
Continúa en el artículo sobre los comandos externos. Podemos ejecutar vbs, bat, powershelll,… lo cual puede ser sumamente interesante para el chequeo de tareas concretas.

Comentarios

Entradas populares de este blog

Orange Pi IoT 2G Flashear memoria NAND

Usar datos gratis para proyectos IoT FreedomPop y Orange Pi 2G IoT (también Simyo).

Configurar modem GSM en la Orange Pi 2G IoT (Orange España)