 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Los servicios son la «esencia» real de un sistema de monitorización. Cada uno representa un engranaje importante en tu complejo entorno de TI. La utilidad de la monitorización en su conjunto depende de la precisión y la eficacia con que se hayan configurado los servicios. Por último, la monitorización debe notificar de forma fiable cada vez que surja un problema en algún lugar, pero también debe minimizar las notificaciones falsas o inútiles.
Checkmk demuestra posiblemente su mayor fortaleza a la hora de configurar servicios: cuenta con un sistema inigualable y muy potente para la detección y configuración automáticas de servicios. Con Checkmk no hay necesidad de definir cada servicio individualmente mediante plantillas y asignaciones específicas. Checkmk puede detectar de forma automática y fiable la lista de servicios que hay que supervisar y, ante todo, mantenerla actualizada. Esto no solo ahorra mucho tiempo, sino que también hace que la monitorización sea precisa. Garantiza que los cambios diarios en un centro de datos se cubran siempre con rapidez y que ningún servicio importante quede sin supervisar.
El descubrimiento de servicios en Checkmk se basa en un principio básico importante: la separación entre «qué» y «cómo»:
¿Qué se debe monitorizar? → El sistema
/varen el hostmyserver01¿Cómo se debe realizar la monitorización? → cuando el espacio utilizado alcance el 90 % WARN , cuando alcance el 95 % CRIT
Lo
que
detecta automáticamente el descubrimiento de servicios. Es
una combinación del nombre
del host
(myserver01
), el check plugin
(df:
data system check en Linux) y el item
(/var
). Los check plugins que pueden crear un máximo de un servicio en un
host no requieren un item (por ejemplo, el check plugin para la carga de la CPU). Los
resultados del descubrimiento de servicios se presentan en una tabla como se muestra a continuación:
| Host | Check plugin | Item |
|---|---|---|
|
|
|
|
|
|
|
|
|
… |
… |
… |
|
|
|
… |
… |
… |
El «cómo» —es decir, los umbrales y parámetros de check para cada
servicio— se configura de forma independiente mediante reglas. Puedes,
por ejemplo, definir una regla que realice la monitorización de todos los sistemas de datos con el punto de montaje /var,
y los umbrales del 90 % y el 95 %, sin tener que pensar en
qué hosts existe ese sistema de datos. ¡Esto es lo que hace que configurar
con Checkmk sea tan claro y sencillo!
Hay algunos servicios que no se pueden instalar mediante el descubrimiento automático. Entre ellos se encuentran, por ejemplo, las comprobaciones consultadas a través de sitios web especificados por HTTP. Estas se crean mediante reglas, como puedes ver en el artículo sobre comprobaciones activas.
La lista de posibilidades que tiene Checkmk para la monitorización de sí mismo se encuentra en el artículo Supervisar tu propio sistema.
2. Servicios del host en la configuración
2.1. Añadir un nuevo host
Una vez que hayas añadido un nuevo host en la configuración, el siguiente paso es abrir la lista de servicios. Con esta acción se lleva a cabo por primera vez el descubrimiento de servicios para este host y, al mismo tiempo, se comprueba la accesibilidad de las fuentes de datos. También puedes abrir esta lista en cualquier momento posterior para reiniciar el descubrimiento o realizar modificaciones en la configuración. Hay varias formas de abrir la lista de servicios:
a través del botón «
» (Save & run service discovery) en el «Properties of host» (Configuración)en la barra de menú de Properties of host a través de Host > Run service discovery
a través del símbolo
en la lista de hosts de una carpeta en la configuracióna través de la entrada
Run service discovery en el menú de acción del servicio Check_MK Discovery de un host
Cuando se acaba de incorporar un host, sus servicios aún no se han configurado, por lo que todos los servicios detectados aparecen en la categoría «Undecided services - currently not monitored»:
El método habitual para añadir los servicios recién detectados es simplemente pulsar el botón «
» (Accept all).
De esta forma, también se añadirán todas las host labels de una sola vez.
Después, haz clic rápidamente en «Activate changes» (Añadir al servicio de monitorización), tras lo cual el host aparecerá en la monitorización.
2.2. Añadir servicios que faltan
Para un host que ya está siendo objeto de monitorización, esta lista tiene un aspecto diferente. En lugar de «Undecided services - currently not monitored», verás «Monitored services». Si Checkmk detecta algo en un host que no está siendo objeto de monitorización, pero que debería estarlo, la lista tendrá un aspecto similar a este:
Al hacer clic en 
Monitor undecided services o en Accept all, simplemente se añaden todos los servicios que faltan para que la monitorización vuelva a estar completa.
Si solo quieres añadir algunos de los servicios que faltan, también puedes hacer clic en el botón para Move to monitored services.
2.3. Servicios desaparecidos
En los centros de datos, las cosas no solo pueden aparecer, sino también desaparecer. Una instancia de base de datos puede dejarse de utilizar, un LUN puede desmontarse, un sistema de archivos puede eliminarse, etc. Checkmk reconoce automáticamente estos servicios como desaparecidos. En la lista de servicios, por ejemplo, se verá así:
La forma más sencilla de deshacerte de estos servicios es, de nuevo, haciendo clic en «» (Accept all) o pulsando el botón «
» en cada línea individual,
que significa «Remove vanished services» (Eliminar servicio).
Atención: ¡El motivo de la desaparición puede deberse, por supuesto, a un problema!
La desaparición de un sistema de archivos también puede significar que, debido a un error, no se ha podido montar.
¡Al fin y al cabo, la monitorización está ahí para estos casos!
Solo debes eliminar el servicio cuando estés realmente seguro de que ya no necesita monitorización.
2.4. Eliminar servicios no deseados
No necesariamente querrás realizar la monitorización de todo lo que Checkmk encuentre. El descubrimiento funciona de forma orientada a objetivos, por supuesto, y puede excluir muchos datos innecesarios de antemano. No obstante, ¿cómo puede saber Checkmk, por ejemplo, que una instancia de base de datos concreta se ha configurado solo «para jugar», y no está en producción? Hay dos formas de eliminar dichos servicios:
Desactivar servicios temporalmente
Para eliminar temporalmente ciertos servicios de la monitorización, basta con hacer clic en el icono 
.
De esta forma, el servicio se moverá a la lista de Undecided services.
O incluso puedes hacer clic en el icono 
al principio de la línea, para desactivar el servicio.
Y, por supuesto, no te olvides de la habitual Activate changes.
Sin embargo, esto solo está pensado para acciones temporales y de menor envergadura, ya que los servicios deseleccionados de esta manera aparecerán resaltados como missing por Checkmk, y la comprobación de descubrimiento (que te mostraremos más adelante) tampoco dará el resultado esperado. En cualquier caso, eso supondría simplemente demasiado trabajo y no sería realmente práctico en un entorno con miles de servicios…
Desactivar servicios de forma permanente
Es mucho más elegante y duradero ignorar permanentemente los servicios con la ayuda del conjunto de reglas «Disabled services». Aquí no solo puedes excluir servicios individuales de la monitorización, sino también formular reglas como «No quiero realizar la monitorización de servicios que empiecen por myservice en el host myserver01."
Puedes acceder a la regla a través de Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.
Una vez que hayas guardado las reglas y vuelvas a la lista de servicios del host, verás los servicios desactivados en la sección «Disabled Services», junto con cualquier servicio que se haya desactivado manualmente.
2.5. Actualización de servicios
Hay varios Plugins que detectan cosas durante un descubrimiento. Por ejemplo, el plugin para interfaces de red chequea la velocidad establecida en la interfaz durante el descubrimiento. ¿Por qué? ¡Para poder avisarte en caso de que cambie! Rara vez es buena señal que una interfaz esté a veces configurada a 10 Mbit/s y otras a 1 Gbit/s; esto podría ser más bien un indicio de una negociación automática defectuosa.
¿Qué pasa si este cambio es deseado y se quiere aceptar como válido a partir de
ahora?
O bien: elimina el servicio mediante el icono , que
significa «Move to undecided services», y vuelve a añadirlo inmediatamente
después.
O bien actualiza todos los servicios del host haciendo clic en Actions > Remove all
and find new en la barra de menú. Esto es, naturalmente, mucho más fácil, pero solo cuando
no quieres mantener servicios individuales en estado de error.
2.6. Actualizar las etiquetas de host y servicio
Actualizar solo las etiquetas de servicio es muy fácil: basta con ir a Actions > Host labels > Update host labels y Actions > Services > Update service labels, respectivamente, en la barra de menú.
Si solo necesitas añadir o actualizar etiquetas de servicio individuales (nuevas), puedes hacerlo en la línea del servicio correspondiente en la caja Changed services haciendo clic en 
.
2.7. Condiciones especiales con SNMP
Hay algunas características especiales para los dispositivos que participan en la monitorización a través de SNMP. Puedes obtener más información al respecto en el artículo sobre SNMP.
3. Descubrimiento masivo: descubrimiento simultáneo en varios hosts
Si quieres realizar un descubrimiento en varios hosts con una sola acción, puedes facilitarte el trabajo con las acciones masivas de Checkmk. En primer lugar, elige los hosts en los que se va a realizar el descubrimiento. Tienes varias opciones para ello:
En una carpeta, marca las casillas de los hosts individuales y luego haz clic en « Hosts > On selected hosts > Run bulk service discovery» en la barra de menú.
Busca los hosts con la función «setup host search», selecciona todos los hosts del resultado de la búsqueda haciendo clic en «
» y, a continuación, vuelve a
seleccionar «Hosts > On selected hosts > Run bulk service discovery» en la barra de menú.En una carpeta, haz clic en «Hosts > In this folder > Run bulk service discovery» en la barra de menú.
Con la tercera variante también puedes realizar el descubrimiento de servicios de forma recursiva en todas las subcarpetas. En las tres opciones anteriores, el siguiente paso te llevará al siguiente diálogo:
En el menú desplegable «Parameters», la opción «Custom service configuration update» está preseleccionada. Las cuatro checkboxes de abajo ofrecen exactamente las mismas opciones que tienes en la lista de servicios de la configuración y que ya hemos explicado anteriormente. En el menú desplegable, también tienes la opción de seleccionar «Refresh all services (tabula rasa)».
En «Selection» puedes volver a controlar la selección de hosts. Esto tiene sentido sobre todo si los has seleccionado a través de la carpeta en lugar de mediante las casillas de verificación. La mayoría de las opciones están pensadas para acelerar el descubrimiento:
Include all subfolders |
Si has iniciado el descubrimiento masivo para todos los hosts de una carpeta, esta opción estará activa por defecto. El descubrimiento se ejecutará también en todos los hosts de todas las subcarpetas. |
Only include hosts that failed on previous discovery |
Los hosts para los que haya fallado un descubrimiento de servicios anterior mediante acciones masivas (por ejemplo, porque el host no era accesible en ese momento) se marcan con el símbolo « |
Only include hosts with a failed discovery check |
Esto limita el descubrimiento a aquellos hosts en los que la comprobación de descubrimiento falló. Cuando trabajas con la comprobación de descubrimiento, este es un buen método para acelerar considerablemente el descubrimiento en muchos hosts. Sin embargo, la combinación con la opción «Refresh all services (tabula rasa)» tiene menos sentido en este caso, ya que puede distorsionar el estado de los servicios existentes. |
Exclude hosts where the agent is unreachable |
Los hosts a los que no se puede acceder provocan largos retrasos durante el descubrimiento debido a los tiempos de timeout de la conexión. Esto puede afectar mucho al rendimiento del descubrimiento en un gran número de hosts. Si los hosts ya están en monitorización —y se sabe que están en estado «DOWN»—, puedes omitirlos aquí y así evitar los tiempos de timeout. |
Los Performance Options están predefinidos para que se realice un full service scan. Si no te interesan los nuevos Plugins, puedes acelerar considerablemente el descubrimiento si no eliges esta opción.
El conjunto de 10 establecido en Number of hosts to handle at once significa que
siempre se realizan diez procesos en una sola acción. Esto se consigue internamente
mediante una solicitud HTTP. Si tienes problemas de timeout debido a que algunos hosts
tardan mucho en detectarse, puedes intentar reducir este número
(a costa del tiempo total necesario).
En cuanto confirmes el diálogo, el procedimiento comenzará y podrás observar su progreso:
4. Check los parámetros de los servicios
Muchos de los check plugins se pueden configurar mediante parámetros. Lo más habitual es establecer umbrales para WARN y CRIT. Los parámetros pueden estructurarse de una forma mucho más compleja, como se muestra en este ejemplo de monitorización de temperatura con Checkmk:
El parámetro de check de un servicio se compone de tres partes:
Cada Plugin tiene un valor por defecto para el parámetro.
Algunos Plugins establecen valores durante un descubrimiento (véase más arriba).
Los parámetros se pueden configurar mediante reglas.
Los parámetros de las reglas tienen prioridad sobre los establecidos por un descubrimiento, y estos , a su vez, tienen prioridad sobre los valores por defecto. Para parámetros complejos en los que los subparámetros individuales se configuran mediante casillas de verificación (como con la temperatura , por ejemplo), estas reglas de prioridad se aplican por separado para cada subparámetro. Así, si configuras solo un subparámetro mediante reglas, los demás conservan sus respectivos valores por defecto. De esta forma puedes, por ejemplo, activar el cálculo de la tendencia de las temperaturas con una regla, y con un conjunto de reglas establecer el valor umbral de temperatura para un dispositivo sensor físico. El conjunto completo de parámetros se compondrá entonces a partir de ambas reglas.
Los parámetros exactos que tiene un servicio se pueden encontrar en la página de
parámetros del servicio. Se puede acceder a ella a través del símbolo
en la lista de servicios del host. Si quieres ver los parámetros
de todos los servicios directamente en la tabla de servicios, puedes mostrarlos haciendo clic en «
Display > Details > Show check parameters
» en la barra de menú. Tendrá
un aspecto similar a este:
5. Personalización del descubrimiento de servicios
Ya hemos mostrado anteriormente cómo puedes configurar el descubrimiento de servicios para ocultar los servicios que no te interesan. Además, hay otros conjuntos de reglas para varios Plugins que influyen en el comportamiento del descubrimiento con estos Plugins. No solo hay ajustes para omitir items, sino también otros que buscan items de forma activa o los agrupan en colecciones. La denominación de los items también puede ser un problema en ocasiones, por ejemplo, en el caso de los puertos de conmutación y las interfaces de red en los que puedes decidir qué descripción o alias se utilizará como item (que se empleará en el nombre del servicio) en lugar de su ID de interfaz.
Todos los conjuntos de reglas relevantes para el descubrimiento de servicios se pueden encontrar en Setup > Services > Discovery rules. Por favor, no confundas estos conjuntos de reglas con los destinados a parametrizar los servicios propiamente dichos. De hecho, varios Plugins tienen dos conjuntos de reglas: uno para el descubrimiento y otro para los parámetros. Aquí tienes algunos ejemplos.
5.1. Monitorización de procesos
No tendría mucho sentido que Checkmk se limitara a definir un servicio para la monitorización de todos los procesos que se encuentran en un host. La mayoría de los procesos o bien no tienen interés o solo están presentes temporalmente. Como mínimo, hay cientos de procesos ejecutándose en un servidor Linux típico.
Por lo tanto, para supervisar servicios, debes trabajar con servicios forzados o —y esto es mucho más elegante— utilizando el conjunto de reglas «Process discovery» para indicar al descubrimiento de servicios qué procesos debe buscar. De esta manera, siempre puedes permitir que se establezca una monitorización automáticamente cuando se encuentre un proceso definitivamente interesante en un host.
La siguiente imagen muestra una regla del conjunto de reglas «Process discovery
» que
busca procesos que ejecuten el programa/usr/sbin/apache2
.
En este ejemplo, se creará un servicio (Grab user from found processes
)
para cada usuario del sistema operativo diferente para el que se encuentre dicho proceso.
El servicio se llamaráApache %u
, donde%u
se sustituirá por el nombre de usuario. Para el umbral, el número de instancias del proceso
se establecerá en 1/1 (mínimo) y 30/60 (máximo) respectivamente:
Ten en cuenta que los umbrales predefinidos se denominan Default parameters for detected services. Puedes asignarlos —y, del mismo modo, todos los demás servicios— mediante reglas. A modo de recordatorio: las reglas anteriores configuran el descubrimiento de servicios —el «qué». Si los servicios están presentes por primera vez, la secuencia de reglas State and count of processes es la responsable de los umbrales.
El hecho de que puedas establecer umbrales durante un descubrimiento es una ayuda para tu comodidad. Sin embargo, hay una pega: los cambios en la regla de descubrimiento solo entran en vigor con el siguiente descubrimiento. Si cambias los umbrales, tendrás que ejecutar un nuevo descubrimiento. Si, por el contrario, solo utilizas la regla para descubrir los servicios (el «qué») y el conjunto de reglas « State and count of processes» para el «cómo», entonces no tendrás este problema.
Para supervisar determinados procesos o un solo proceso en un host Windows, solo tienes
que indicar el nombre del archivo (incluida la extensión) sin ninguna ruta en el campo «
Executable». Puedes encontrar todos estos nombres en la pestaña «Detalles» del
Administrador de tareas de Windows, por ejemplo. En la regla «Process discovery», esto podría verse así
para el proceso «svchost»:
Puedes encontrar más información sobre el descubrimiento de procesos en la ayuda en línea de este conjunto de reglas. Como siempre, puedes activarla a través de «Help > Show inline help» en la barra de menú.
5.2. Monitorización de servicios en Windows
El descubrimiento y la configuración de la monitorización de los servicios de Windows es análoga a la de los procesos y se controla mediante los conjuntos de reglas Windows service discovery(qué) y Windows services (cómo) respectivamente. Aquí tienes un ejemplo de una regla que supervisa dos servicios:
Al igual que con los procesos, aquí el descubrimiento de servicios es también solo una opción. Si, basándote en las características del host y las carpetas, puedes formular reglas precisas para los hosts en los que se esperan servicios específicos, entonces también puedes trabajar con servicios forzados. Esto es independiente de la situación real; sin embargo, puede requerir un esfuerzo considerablemente mayor, ya que en estas circunstancias necesitas muchas reglas para describir exactamente qué servicio se debe esperar en cada host.
5.3. Monitorización de puertos del switch
Checkmk utiliza la misma lógica para la monitorización de las interfaces de red de los servidores y de los puertos del switch. En el caso de los puertos del switch, las opciones existentes para el descubrimiento de servicios son especialmente interesantes, aunque (a diferencia de los procesos y los servicios de Windows) el descubrimiento inicialmente funciona sin reglas. Es decir, por defecto, Checkmk realiza la monitorización automáticamente de todos los puertos físicos que actualmente se encuentran en estado UP. El conjunto de reglas aplicable se llama «Network interface and switch port discovery» y ofrece numerosas opciones de configuración que aquí solo se describen brevemente:
Las siguientes opciones son las más importantes:
En la sección «Appearance of network interface» puedes determinar cómo debe aparecer la interfaz en el nombre del servicio. Puedes elegir entre «Use description», «Use alias» y «Use index».
La restricción o ampliación de los tipos o nombres de las interfaces objeto de monitorización.
6. Configuración de servicios obligatorios
Hay algunas situaciones en las que el descubrimiento automático de servicios no tendría sentido. Esto ocurre siempre que quieras forzar el cumplimiento de una directriz específica. Como vimos en el capítulo anterior, puedes permitir que la monitorización de los servicios de Windows se configure automáticamente cuando estos se detecten. ¿Qué ocurre cuando la ausencia de un servicio de este tipo supone un problema? Por ejemplo:
Se debe instalar un antivirus concreto en todos los hosts Windows.
NTP debe estar configurado en todos los hosts Linux.
En tales casos, simplemente puedes imponer esos servicios. Encontrarás el punto de partida para ello en Setup > Services > Enforced services. Detrás de esto hay una colección de conjuntos de reglas que tienen exactamente los mismos nombres que los conjuntos de reglas utilizados para configurar los parámetros de estas comprobaciones.
Sin embargo, las reglas difieren en dos puntos:
Son reglas para hosts, no para servicios. Los servicios serán creados por las reglas.
Dado que no se realiza ningún descubrimiento, debes seleccionar el check plugin que se utilizará para la comprobación.
El siguiente ejemplo muestra el cuerpo de la regla State of NTP time synchronisation en Enforced services:
Junto con los umbrales, aquí se configura el check plugin (p. ej.,chrony
ontp_time
). Para los check plugins que requieren un item, también debes
especificarlos. Por ejemplo, esto es necesario para el check pluginoracle_processes
, que requiere los detalles del SID de la base de datos que se va a realizar la monitorización:
Un servicio manual definido de esta manera se instalará en todos los hosts a los que se apliquen estas reglas. Ahora habrá tres condiciones posibles para la monitorización real:
El host está correctamente instalado y el servicio está en estado «OK».
El agente notifica que el servicio solicitado no se ejecuta o tiene un problema. El servicio marca entonces como «CRIT» o «UNKNOWN».
El agente no proporciona ninguna información, por ejemplo, porque NTP ni siquiera está instalado. El servicio permanece entonces en PEND y el servicio «Check_MK» pasa a WARN con la nota de que falta la sección relevante en los datos del agente.
No necesitarás la mayoría de los conjuntos de reglas del módulo «Enforced services », solo están ahí para completar. Los casos más comunes de comprobaciones manuales son:
Monitorización de servicios de Windows (Conjunto de reglas: Windows Services)
Monitorización de procesos (Conjunto de reglas: State and count of processes)
7. El check de descubrimiento
En la introducción prometimos que Checkmk no solo detecta la lista de servicios automáticamente, sino que también puede mantenerla actualizada. También sería lógico poder ejecutar manualmente un descubrimiento masivo de todos los hosts de vez en cuando.
7.1. Check automático de servicios no supervisados
Sin embargo, mucho mejor para esto es un check de descubrimiento periódico, que se configura automáticamente en los nuevos sites. Este servicio Check_MK Discovery existe para cada host y registrará una advertencia cada vez que encuentre items no supervisados:
Los detalles de los servicios no supervisados o desaparecidos se pueden encontrar en la página de detalles del servicio Check_MK Discovery, en el campo Details:
Se puede acceder fácilmente a la lista de servicios del host en la configuración a través del menú de acción de 
del servicio Check_MK Discovery
y la entrada Run service discovery.
La configuración de la comprobación de descubrimiento se realiza de forma muy sencilla utilizando el conjunto de reglas «Periodic service discovery». En un sitio recién instalado out of the box, ya encontrarás una regla definida para aplicarse a todos los hosts:
Además del intervalo en el que se ejecutará la comprobación, puedes configurar el estado de monitorización para casos de servicios no monitorizados, servicios desaparecidos, etiquetas de servicio modificadas y nuevas host labels.
7.2. Añadir servicios automáticamente
Puedes hacer que la comprobación de descubrimiento añada automáticamente los servicios que faltan. Para ello, activa la opción «Automatically update service configuration», lo que te dará acceso a más opciones.
Además de las adiciones, en «Parameters» también puedes elegir eliminar servicios desaparecidos, o incluso eliminar todos los servicios existentes y realizar un nuevo descubrimiento completo. Esta última opción se encuentra en el menú desplegable bajo el nombre «Refresh all services and host labels (tabula rasa)». ¡Ambas opciones deben utilizarse con cuidado! ¡Un servicio desaparecido puede indicar un problema! La comprobación de descubrimiento simplemente eliminará dicho servicio y te hará creer que todo está en orden. La actualización es especialmente arriesgada. Por ejemplo, la comprobación de switchports solo incluirá en la monitorización los puertos que estén en estado «UP». ¡Los puertos con estado «DOWN» se considerarán desaparecidos y se eliminarán rápidamente de la comprobación de descubrimiento!
Hay que tener en cuenta otro problema: añadir servicios o incluso la Activate Changese automática puede distraerte —a ti, el administrador— cuando estás realizando una configuración. En teoría, puede ocurrir que mientras estás trabajando en reglas y ajustes, en ese mismo momento un check de descubrimiento active tus cambios. ¡En Checkmk solo se pueden activar todos los cambios a la vez! Para evitar este tipo de situaciones, puedes reprogramar la hora de esta función, por ejemplo, para que se realice durante la noche. La imagen de arriba muestra un ejemplo de esto.
En «Vanished clustered services» puedes manejar los servicios en clúster por separado. La particularidad aquí es que, si un servicio en clúster se traslada de un nodo a otro, podría considerarse brevemente como desaparecido y, en consecuencia, eliminarse sin querer. Si desactivas esta opción, por el contrario, los servicios que realmente hayan desaparecido nunca se eliminarán.
La configuración de «Group discovery and activation for up to» garantiza que no todos los servicios recién detectados activen inmediatamente una comprobación de Activate Changes, sino que habrá un tiempo de espera especificado para que se puedan activar varios cambios en una sola acción. Incluso si la comprobación de descubrimiento está configurada en un intervalo de dos horas o más, esto solo se aplica a cada host por separado. Las comprobaciones no se ejecutan simultáneamente para todos los hosts, lo cual es bueno, ya que una comprobación de descubrimiento requiere muchos más recursos que una comprobación normal.
8. Servicios pasivos
Los servicios pasivos son aquellos que no son iniciados activamente por Checkmk, sino por resultados de comprobaciones que llegan regularmente desde fuentes externas. Esto suele ocurrir a través del canal de comandos del core. Aquí tienes un procedimiento paso a paso para crear un servicio pasivo:
Primero, tienes que notificar el servicio al core. Esto se hace con el mismo conjunto de reglas que en tus propias comprobaciones activas, salvo que omites el Command line:
La imagen también muestra cómo puedes verificar si se reciben regularmente los resultados de las check-ups. Si estos no aparecen durante más de diez minutos, el servicio se marcará automáticamente como UNKNOWN.
Tras un «Activate Changes», el nuevo servicio comenzará su vida en el estado PEND:
El envío del resultado del check se realiza ahora en la línea de comandos mediante una llamada a
echodel comando PROCESS_SERVICE_CHECK_RESULT en la
tubería de comandos ~/tmp/run/nagios.cmd.
La sintaxis se ajusta a las convenciones habituales de Nagios, incluyendo una
marca de tiempo actual entre corchetes. Como argumento del comando necesitas
el nombre del host (p. ej., myhost) y el nombre del servicio seleccionado
(p. ej., BAR). Los dos argumentos siguientes son, de nuevo, el estado
(0 … 3) y la salida del Plugin. La marca de tiempo se
crea con $(date +%s):
El servicio muestra ahora inmediatamente su nuevo estado:
9. Descubrimiento de servicios desde la línea de comandos
Una GUI está bien, pero la buena vieja línea de comandos a veces sigue siendo
práctica, ya sea para la automatización o simplemente porque permite a un usuario experimentado
trabajar más rápido. Se puede iniciar el descubrimiento de servicios con el comando «cmk
-I» en la línea de comandos. Hay un par de variables en
este proceso. Para todas ellas se recomienda la opción «-v», para que
puedas ver lo que ocurre. Sin «-v», Checkmk se comporta como el buen
viejo Unix tradicional: mientras todo vaya OK, no dice nada.
Con una simple búsqueda «-I» para todos los hosts por nuevos servicios:
Con el comando «-I» también puedes introducir uno o más nombres del host para
detectar solo esos. Esto tiene además un segundo efecto: mientras que
un «-I» en todos los hosts básicamente solo funciona con datos almacenados en la caché,
¡Checkmk siempre trabaja con datos actualizados de un host designado explícitamente!
También puedes filtrar usando tags:
Esto realizaría el descubrimiento de todos los hosts con el tag del host mytag.
El filtrado por tags está disponible para todas las opciones cmk que admiten múltiples hosts.
Con las opciones --cache y, respectivamente, --no-cache,
puedes determinar explícitamente el uso de la caché.
Se pueden obtener resultados adicionales con un segundo -v. Con dispositivos SNMP
incluso puedes ver cada OID recuperado del dispositivo:
Se puede realizar una renovación completa de los servicios (tabula rasa) con un
doble -II:
También puedes restringir todo esto a un único check plugin. Para ello, la
opción es --detect-plugins= , y debe colocarse antes del nombre del host:
Cuando hayas terminado, puedes activar los cambios con «cmk -O
» (encmk -R
con Nagios Core):
Y cuando te encuentres con un error durante un descubrimiento…
… con un comando adicional «--debug» puedes generar un seguimiento detallado de la pila de Python
de la ubicación del fallo:
9.1. Vista general de opciones
En resumen: todas las opciones de un vistazo:
|
Descubrir nuevos servicios |
|
Eliminar y volver a detectar todos los servicios (tabula rasa) |
|
Detallado: muestra los hosts y los servicios detectados |
|
Muy detallado: muestra un protocolo preciso de todas las operaciones |
|
Ejecutar un descubrimiento (y también un borrado total) solo para el check plugin especificado |
|
Ejecutar un descubrimiento (y también un borrado total) solo para los hosts con la etiqueta especificada |
|
Forzar el uso de datos de caché (normalmente es el valor predeterminado solo cuando no se especifica ningún host) |
|
Recupera datos actualizados (normalmente es el valor predeterminado solo cuando se especifica el nombre del host) |
|
Cancelar en caso de error y mostrar el seguimiento completo de la pila de Python |
|
Activar cambios (ediciones comerciales con CMC como core) |
|
Activar cambios (Checkmk Community con Nagios como core) |
9.2. Guardar en archivos
El resultado del descubrimiento de servicios —es decir, como se ha explicado anteriormente, las
tablas de nombres de host, check plugins, items y parámetros identificados— se puede
encontrar en la carpeta var/check_mk/autochecks. Aquí, para cada
host hay un conjunto de datos que almacena los servicios descubiertos automáticamente.
Siempre que no dañes la sintaxis Python de este conjunto de datos, puedes modificar o
eliminar líneas individuales manualmente. Al eliminar el conjunto de datos se eliminan todos los servicios
y se marcan de nuevo como «sin supervisar».
[
{'check_plugin_name': 'cpu_loads', 'item': None, 'parameters': (5.0, 10.0), 'service_labels': {}},
{'check_plugin_name': 'cpu_threads', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'diskstat', 'item': 'SUMMARY', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_performance', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_util', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'livestatus_status', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'lnx_thermal', 'item': 'Zone 0', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mem_linux', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mounts', 'item': '/', 'parameters': ['errors=remount-ro', 'relatime', 'rw'], 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'tcp_conn_stats', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'timesyncd', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'uptime', 'item': None, 'parameters': {}, 'service_labels': {}},
]10. Grupos de servicio
10.1. ¿Para qué sirven los grupos de servicio?
Hasta ahora has aprendido a incluir servicios en la monitorización. Ahora bien, no tiene mucho sentido tener que revisar listas de miles de servicios y/o tener que pasarte siempre por las vistas de tabla de los hosts. Por ejemplo, si quieres ver todos los servicios del sistema de archivos o de actualización juntos, puedes simplemente crear grupos de forma similar a como lo haces con los grupos del host.
Los grupos de servicio te facilitan poner mucho más orden en la monitorización a través de vistas de tabla y mapas de NagVis, así como cambiar las notificaciones específicas y los alert handlers.
Por cierto, casi siempre podrías crear las vistas correspondientes utilizando únicamente los filtros de vista, pero los grupos de servicio están organizados de forma más clara y son más fáciles de manejar.
10.2. Creación de grupos de servicio
Encontrarás los grupos de servicio en Setup > Services > Service groups.
Crear un grupo de servicio es sencillo:
Crea un grupo en 
Add group y asígnale un nombre que no se pueda cambiar posteriormente, así como un alias significativo:
10.3. Añadir servicios a un grupo de servicio
Para asignar servicios a grupos de servicios necesitas el conjunto de reglas Assignment of services to service groups. La forma más rápida de llegar allí es a través de la Vista general de los grupos de servicios (Setup > Services > Service Groups). Aquí solo tienes que hacer clic en «Service Groups > Assign to group > Rules» en la barra de menú. Como alternativa, por supuesto, puedes encontrar la regla mediante la búsqueda de reglas en el menú «Setup», o rebuscar en Setup > Services > Service monitoring rules > Various > Assignment of services to service groups. Ahora usa Create rule in folder para hacer precisamente eso. Primero especificas a qué grupo de servicios quieres asignar servicios, por ejemplo, myservicegroup o su alias «My service group 1».
Ahora viene la parte interesante en la sección «Conditions».
Por un lado, puedes usar carpetas, tags del host y nombres del host explícitos para establecer restricciones fuera de los servicios.
En segundo lugar, nombras los servicios que quieres agrupar, como Filesystem y myservice, para crear un conjunto de sistemas de archivos.
La especificación de los servicios se realiza aquí mediante expresiones regulares. Esto te permite definir los grupos con exactitud.
10.4. Comprobación de los grupos de servicio de un servicio
Puedes checkear la asignación de servicios en la página de detalles de un servicio concreto. A continuación, por defecto, aparece la línea Service groups the service is member of.
10.5. Uso de los grupos de servicio
Como ya se ha mencionado, los grupos de servicios se utilizan en varios lugares, como vistas, mapas de NagVis, notificaciones y alert handlers. Para las nuevas vistas, es importante que utilices Service groups como fuente de datos. Por supuesto, el widget Views también contiene vistas predefinidas para grupos de servicios, por ejemplo, un resumen claro:
Al hacer clic en los nombres de los grupos de servicio, obtendrás una vista completa de todos los servicios del grupo correspondiente.
Si utilizas grupos de servicios en los mapas de NagVis, obtendrás un resumen de los grupos de servicios que se abre en un menú al pasar el cursor por encima de un icono:
Cuando utilizas grupos de servicios en notificaciones y alert handlers, están disponibles como condiciones/filtros, de los que puedes usar uno o varios:
11. Más información sobre los check plugins
11.1. Una breve descripción de su funcionalidad
Los check plugins son necesarios para generar servicios en Checkmk.
Cada servicio utiliza un check plugin para determinar su estado, crear y mantener métricas, etc.
Al hacerlo, dicho plugin puede crear uno o más servicios por host.
Para poder distinguir entre varios servicios del mismo plugin, se necesita un item.
Por ejemplo, para el servicio Filesystem /var, el item es el texto /var.
En el caso de los Plugins que solo pueden generar un máximo de un servicio por host (
CPU utilization, por ejemplo), el item está vacío y no se muestra.
11.2. Check plugins disponibles
Puedes encontrar una lista de todos los check plugins disponibles en Setup > Services > Catalog of check plugins. Aquí puedes buscar los plugins individuales y filtrarlos por varias categorías:
Para cada plugin se mostrarán tres columnas de información: una descripción del servicio (Tipo de comprobación), el nombre del check plugin (Nombre del plugin) y sus fuentes de datos compatibles (Agentes):
