VMWare. Monitorizar vCenter appliance con check_mk

Empezaremos con la monitorización de nuestro vCenter appliance y usaremos nuestra instalación de OMD que incluye check_mk para configurar la monitorización con este. Si no tenemos ni queremos tener check_mk podemos siempre monitorizar con los clientes estandar nsclient++ (si es windows) o NRPE si usas el appliance con Suse Linux.

El appliance de vCenter es un Linux Suse Enterprise Server así que lo podemos monitorizar con el cliente para Linux de check_mk. Si tuviéramos nuestro vCenter instalado en Windows Server el procedimiento sería similar pero con el agente de check_mk para Windows.

Bajamos el paquete de instalación del agente (RPM para Suse) de la página de downloads de check_mk y lo instalamos en nuestro vCenter appliance. Nos creará el correspondiente fichero de configuración en xinetd y nos pondrá automáticamente dicho demonio en on en el runlevel actual (3).

Conviene que editemos /etc/xinetd.d/check_mk y permitamos solo acceso a nuestro servidor Nagios.

only_from = 127.0.0.1 IP_Nagios

Creamos en nuestro fichero de configuración de check_mk nuestro host tal como se explicó en otro artículo. La entrada en nuestro array “all_hosts” puede ser algo así (con tags que puede ser de interés más adelante)

 "vcenter|Linux|Suse|vSphereVCapp"

Inventariamos nuestro host y reiniciamos check_mk para que cree la configuración en ficheros de Nagios.

check_mk_add_vcenter

Ya tenemos nuestro vcenter appliance monitorizado. La ostia el check_mk este… Y con el icono de acceso a las gráficas y estas ya configuradas en PNP4Nagios (tenemos una instalación de OMD).

check_mk_agent_vcenter_show

La única pega que tiene tanto automatismo es el control de los rangos, que te puede volver loco cambiarlos para una máquina en concreto solamente. Como vemos está dando un “Warning” en un servicio y lo más probable es que sea normal que está máquina tenga muchos “threads”.

En este caso se resuelve configurando explícitamente el chequeo y sus rangos de Warning / Crítical tal como especifica el manual de check_mk para chequeos manuales. Como referencia podemos usar los ficheros e configuración que genera de forma automática en: /opt/omd/sites/chg/var/check_mk/autochecks

 checks = [
( "vcenter", "cpu.threads", None, (2700, 2800) ),
]

Volvemos a inventariar el Host con –II y reiniciamos check_mk.

Recordar que el tema de los rangos es algo muy “vivo” que hay que ir ajustando a los diferentes servicios de nuestros equipos.Lo mejor siempre es echar mano de las gráficas de PNP4Nagios para ver la evolución de estos y ajustarlos en consecuencia.
Realmente con esto tenemos solo un parte hecha pero realmente más interesante sería analizar los demonios que  usa el appliance y monitorizarlos también con check_mk. Posiblemente en futuros artículos entremos más en profundidad pero con un análisis rápido podemos monitorizar algunos servicios importantes de vCenter. Añadimos lo siguiente a nuestro fichero de configuración de check_mk:

checks = [
# Configura explicitamente los rangos para el vcenter
( “vcenter”, “cpu.threads”, None, (2700, 2800) ),

# POSTGRES PS para vCenter 5.1 cpn BBDD local.
( “vcenter”, “ps”, “POSTGRES logger process”, ( “~.*logger process”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “POSTGRES balloon process”, ( “~.*balloon process”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “POSTGRES autovacuum launcher process”, ( “~.*autovacuum launcher process”,1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “POSTGRES stats collector process”, ( “~.*stats collector process”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “POSTGRES DB”, ( “~.*/opt/vmware/vpostgres/1.0/bin/postmaster*”, 1, 1, 1, 1 ) ),
# Otros servicios importantes de vcenter app
( “vcenter”, “ps”, “Lighttpd”, ( “~.*/opt/vmware/sbin/vami-lighttpd”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “VPXD”, ( “/usr/lib/vmware-vpx/vpxd”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “Vami login”, ( “/opt/vmware/share/vami/vami_login”, 1, 1, 1, 1 ) ),
( “vcenter”, “ps”, “Netdumper”, ( “/usr/sbin/vmware-netdumper”, 1, 1, 1, 1 ) ),
]

Que nos nos añadirá los servicios a Nuestro Nagios:

vcenter_process

Ahora nos tocaría, si no lo hemos echo ya, monitorizar nuestros ESX(i) con un plugin standard o bién hacerlo con el plugin de check_mk que es fantástico.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Comment moderation is enabled. Your comment may take some time to appear.