Checkmk
DeutschEnglish
master2.3.0
to checkmk.com
Important

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

1.1. ¿Debería intervenir la monitorización?

Uno pensaría que es obvio que un sistema de monitorización nunca debería intervenir en los eventos, sino que, bueno, debería limitarse a monitorizar. Y probablemente sea buena idea dejarlo así.

Sin embargo, hay que reconocer que resulta tentador pensar que un sistema capaz de identificar problemas de forma fiable también podría corregirlos, siempre que funcionara de forma automática.

Se pueden imaginar fácilmente algunos ejemplos adecuados:

  • Reiniciar un servicio que ha sufrido un crash.

  • Activar un recolector de basura si una máquina virtual Java se está quedando sin memoria.

  • Reconstruir un canal VPN si está definitivamente muerto.

Si uno puede aceptar esto, entonces debe pensar de otra manera sobre la monitorización. De un sistema que simplemente observa y «no es necesario» para las operaciones, un proceso paso a paso lleva a que la monitorización se convierta en un órgano vital en el centro de datos.

Pero corregir problemas no es lo único que la monitorización puede hacer automáticamente cuando identifica un problema. Muy útil, pero también inofensiva, es la colección de datos de diagnóstico adicionales en el momento de un fallo. Sin duda, se te ocurren de inmediato muchos otros casos en los que se podrían utilizar los alert handlers como punto de partida.

1.2. Alert handlers en Checkmk

CEE Los alert handlers son scripts que escribes tú mismo y que Checkmk ejecuta por ti en las ediciones comerciales si se detecta un problema —o, más precisamente—, si un host o un servicio cambia de estado.

Los alert handlers son muy similares a las notificaciones y se configuran de manera similar, pero hay algunas diferencias importantes:

  • Los alert handlers son independientes de los tiempos de mantenimiento programados, los periodos de notificación, los Reconocimientos y controles similares.

  • Los alert handlers se activarán en el primer reintento (si se han configurado múltiples intentos de check).

  • Los alert handlers son independientes de los usuarios y los grupos de contacto.

  • Los alert handlers solo están disponibles en las ediciones comerciales.

También se puede decir que los alert handlers son de «bajo nivel». En cuanto un host o un servicio cambie de estado, tus alert handlers configurados se activarán inmediatamente. De esta manera, un alert handler puede incluso realizar una reparación con éxito antes de que se genere una alerta real.

Por supuesto, como siempre en Checkmk, puedes usar reglas para definir las condiciones en las que debe ejecutarse un gestor concreto. En este artículo encontrarás cómo hacerlo y todo lo demás sobre los alert handlers.

CRE Un consejo para los usuarios de la comunidad de Checkmk que utilicen CRE: también puedes hacer que la monitorización ejecute acciones automáticamente. Para ello, utiliza los «gestores de eventos» de Nagios. Configúralos con archivos de configuración manuales en sintaxis de Nagios en ~/etc/nagios/conf.d/. Los gestores de eventos están bien documentados. Puedes encontrar información fácilmente a través de Google.

2. Configuración de los alert handlers

2.1. Guardar scripts en el directorio correcto

Los alert handlers son scripts que se ejecutan en el servidor Checkmk. Deben guardarse en el directorio ~/local/share/check_mk/alert_handlers/ y pueden estar escritos en cualquier lenguaje compatible con Linux, como BASH, Python o Perl. No te olvides de hacer que los scripts sean ejecutables con `chmod +x`.

Si se inserta un comentario en la segunda línea del script (con el símbolo #), este aparecerá como el nombre del script en la lista de selección de la regla:

~/local/share/check_mk/alert_handlers/myhandler
#!/bin/bash
# Foobar handler for repairing stuff
...
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

2.2. Un alert handler sencillo para probar

Al igual que con las notificaciones, el script obtiene toda la información del host o servicio como variables del entorno, todas ellas con el prefijo ALERT_.

Para comprobar exactamente qué variables del entorno aparecen en el script, puedes usar el siguiente alert handler para hacer una prueba:

~/local/share/check_mk/alert_handlers/debug
#!/bin/bash
# Dump all variables to ~/tmp/alert.out

env | grep ^ALERT_ | sort > $OMD_ROOT/tmp/alert.out
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

  • env muestra todas las variables del entorno.

  • grep ^ALERT_ selecciona aquellas que empiezan por ALERT_.

  • sort Ordena la lista resultante alfabéticamente.

2.3. Activación del alert handler

La activación del controlador se realiza mediante Setup > Events > Alert handlers.

Haz lo siguiente:

  1. Guarda el script en ~/local/share/check_mk/alert_handlers/debug.

  2. Hazlo ejecutable con chmod +x debug.

  3. Accede a la página de configuración a través de Setup > Events > Alert handlers.

  4. Allí, define una nueva regla con Add rule.

El formulario para seleccionar el alert handler permite el acceso directo y muestra el título que se registra en la segunda línea del script. Además, puedes añadir argumentos, que debes introducir en los campos de texto. Estos se interpretarán como argumentos de línea de comandos en el script. En tu shell puedes acceder a ellos con $1, $2, etc.

alert handler arguments

¡Una vez guardada la regla, el alert handler se activará inmediatamente y se ejecutará con cada cambio de estado de cualquier host o servicio!

2.4. Pruebas y diagnóstico de fallos

Para probarlo, cambia manualmente un servicio, por ejemplo, de Fake check results a CRIT. Ahora debería haberse creado el archivo con las variables. Aquí están sus primeras veinte líneas:

OMD[mysite]:~$ head -n 20 ~/tmp/alert.out
ALERT_ALERTTYPE=STATECHANGE
ALERT_CONTACTNAME=check-mk-notify
ALERT_CONTACTS=
ALERT_DATE=2016-07-19
ALERT_HOSTADDRESS=127.0.0.1
ALERT_HOSTALIAS=myserver123
ALERT_HOSTATTEMPT=1
ALERT_HOSTCHECKCOMMAND=check-mk-host-smart
ALERT_HOSTCONTACTGROUPNAMES=all
ALERT_HOSTDOWNTIME=0
ALERT_HOSTFORURL=myserver123
ALERT_HOSTGROUPNAMES=check_mk
ALERT_HOSTNAME=myserver123
ALERT_HOSTNOTESURL=
ALERT_HOSTNOTIFICATIONNUMBER=1
ALERT_HOSTOUTPUT=Packet received via smart PING
ALERT_HOSTPERFDATA=
ALERT_HOSTPROBLEMID=0
ALERT_HOSTSHORTSTATE=UP
ALERT_HOSTSTATE=UP
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Encontrarás un archivo de registro de la (no) ejecución del alert handler en~/var/log/alerts.log . La sección correspondiente a la ejecución del alert handlerdebug , para el servicioFilesystem / en el hostmyserver123 , tendrá un aspecto similar a este:

~/var/log/alerts.log
2016-07-19 15:17:22 Got raw alert (myserver123;Filesystem /) context with 60 variables
2016-07-19 15:17:22 Rule ''...
2016-07-19 15:17:22  -> matches!
2016-07-19 15:17:22 Executing alert handler debug for myserver123;Filesystem /
2016-07-19 15:17:22 Spawned event handler with PID 6004
2016-07-19 15:17:22 1 running alert handlers:
2016-07-19 15:17:22 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 1 running alert handlers:
2016-07-19 15:17:24 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 Handler [6004] for myserver123;Filesystem / exited with exit code 0.
2016-07-19 15:17:24 Output:

Un par de consejos útiles más:

  • Los textos generados por los alert handlers en la salida estándar aparecen en el archivo de registro junto con Output:.

  • El código de salida del script también se registrará (exited with exit code 0).

  • Los alert handlers resultan realmente útiles cuando ejecutan un comando en el host de destino. Checkmk ofrece una solución lista para usar en Linux que se explicará más adelante.

3. Configuración basada en reglas

Como se muestra en el ejemplo introductorio, los eventos que deben activar los alert handlers se definen mediante reglas. Esto funciona de forma totalmente análoga a las notificaciones, solo que algo más simplificado. En el ejemplo no especificamos ninguna condición, lo cual, naturalmente, no es realista en la práctica. El siguiente ejemplo muestra una condición que un alert handler define para hosts y servicios específicos:

alert handlers rule condition

El alert handler solo se activará

  • para los hosts myhost123 y myhost124,

  • para el servicio JVM CaramKern Memory,

  • si el estado cambia de OK o WARN a CRIT,

  • y solo en el segundo intento de check.

Para que se active el gestor, en este ejemplo es necesario usar una regla Maximum number of check attempts for service para establecer el número mínimo de intentos de comprobación en 2. Para suprimir una notificación en caso de que el recolector de basura funcione correctamente, el número debe establecerse en 3, ya que si el gestor puede resolver el problema directamente tras el segundo intento, el tercer intento debería detectar un estado OK y, por lo tanto, no será necesaria ninguna notificación adicional.

Tip

A diferencia de otros lugares en Checkmk, todas las reglas del alert handler se ejecutarán si se cumplen las condiciones. Incluso si dos reglas llaman al mismo alert handler, este se ejecutará dos veces. El asistente de alerta (que se explica en el siguiente capítulo) suprimirá la segunda ejecución con un mensaje de error, ya que el mismo alert handler no debe ejecutarse varias veces al mismo tiempo. Aun así, se recomienda configurar las reglas para que este caso no se produzca.

4. Cómo se ejecutan los alert handlers

4.1. Ejecución asíncrona

Los alert handlers se usan muy a menudo para iniciar sesión de forma remota en una máquina afectada mediante SSH u otro protocolo, y una vez allí, ejecutar una acción controlada por un script. Dado que esta máquina tiene un problema, no se puede descartar que la conexión tarde mucho tiempo o incluso que se produzca un timeout.

Para que la monitorización no se detenga, ni otros manejadores de alertas se bloqueen durante este tiempo, por principio los manejadores de alertas se ejecutan de forma asíncrona. Un proceso auxiliar —el asistente de alerta— se encarga de esta función, y lo inicia el CMC. Para reducir la sobrecarga, esto solo ocurre si se ha creado al menos una regla de alert handler. En el archivo `cmc.log` verás entonces la siguiente línea:

~/var/log/cmc.log
2016-07-19 15:17:00 [5] Alert handlers have been switched on

Con cada cambio de estado de un host o servicio, el asistente de alerta recibe una notificación del CMC con toda la información relevante del evento. A continuación, evalúa todas las reglas de alerta y determina si se debe activar un gestor. Si es así, se iniciará el script correspondiente y se ejecutará en segundo plano como un proceso externo.

4.2. Detener el core de monitorización

Cuando detienes el CMC (por ejemplo, a través de omd stop o apagando el servidor de monitorización), todos los asistentes de alerta que sigan ejecutándose se interrumpirán. Estos no se repetirán más tarde, ya que ¿quién sabe cuándo será «más tarde»? ¡Es posible que reiniciar un servicio o algo similar resulte más perjudicial que útil!

4.3. Timeouts

Para protegerse de que se inicien demasiados procesos en caso de error, cuando un alert handler está en ejecución se aplica un timeout de 60 segundos (configurable). Al final de este tiempo, el alert handler se detendrá. En concreto, esto significa que al final del timeout se enviará una señal 15 (SIGTERM) al alert handler. De esta forma, tiene la posibilidad de detenerse de forma limpia. Tras otros 60 segundos (timeout doble), se «terminará» definitivamente con una señal 9 (SIGKILL).

4.4. Superposición

Checkmk impide la ejecución simultánea de asistentes de alerta si se aplican al mismo host/servicio y ejecutarían el mismo script con los mismos parámetros. Una situación así indica que el primer manejador todavía está en ejecución y que no tendría sentido iniciar una segunda copia del mismo manejador: el segundo manejador se cancelaría al instante y se identificaría como «fallido».

4.5. Códigos de salida y salida

Las salidas y los códigos de salida del alert handler se evalúan de forma fiable y se devuelven al núcleo, donde se guardan en el historial de monitorización. Además, puedes activar una notificación (ver más abajo).

4.6. Configuración global

Hay una serie de ajustes globales para ejecutar los alert handlers:

alert handlers options

La opción «Alert handler log level» influye en el registro del archivo de registro del asistente de alerta (~/var/log/alerts.log).

4.7. Control maestro

alert handlers master control off

Con un clic en el snap-in «Master control» puedes desactivar los alert handlers de forma global. Los alert handlers que se estén ejecutando en ese momento no se verán afectados y se completarán.

¡No te olvides de volver a poner el pequeño switch en verde tan pronto como sea posible! De lo contrario, podrías caer en la falsa sensación de seguridad de que la monitorización lo está solucionando todo…​


5. Alert handlers en el historial

Los alert handlers crean entradas en el historial de monitorización. Esto te ofrece una mejor trazabilidad en comparación con disponer únicamente del archivo de registro alerts.log. Se crea una entrada tan pronto como se inicia un alert handler y otra cuando finaliza.

Por lo tanto, los alert handlers se tratan de la misma manera que los Plugins de monitorización típicos, lo que significa que deben generar una línea de texto y devolver uno de los cuatro códigos de salida: 0 (OK), 1 (WARN), 2 (CRIT) o 3 (UNKNOWN). Todos los errores que impiden desde el principio la ejecución de un controlador (aborto debido a una ejecución duplicada, falta de script, timeout, etc.) se marcan automáticamente con UNKNOWN.

Por ejemplo, al llamar a este sencillo controlador…​

~/local/share/check_mk/alert_handlers/dummy
#!/bin/bash
# Dummy handler for testing

sleep 3
echo "Everything is fine again"
exit 0
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

... produce un resultado como el anterior en el historial del servicio correspondiente (como siempre, el mensaje más reciente aparece en la parte superior):

alert handler history

También hay una vista genérica Monitor > System > Alert handler executions , que ofrece una visualización global de todos los alert handlers en ejecución.

6. Notificación a través de los alert handlers

La ejecución de un alert handler —o, más exactamente, la finalización de una ejecución— es un evento que activa una notificación. De esta forma, te enteras de que un alert handler ha completado su tarea. Hay dos tipos de eventos que puedes filtrar en una regla de notificación:

alert handler notif condition

Así, puedes diferenciar entre controladores ejecutados con éxito (código de salida 0 - OK) y fallos (todos los demás códigos). La notificación por correo electrónico de Checkmk no muestra el resultado de la comprobación, sino el resultado del alert handler.

7. Alert handler para cada ejecución de check

Los alert handlers normalmente solo se activan cuando cambia el estado de un host o servicio (o durante los intentos de reintento al manejar problemas). Las ejecuciones de checks simples sin cambio de estado no activan ningún alert handler.

Con «Global settings > Alert handlers > Types of events that are being processed > All check executions!» puedes configurar exactamente eso. Cada ejecución de una check puede activar potencialmente un alert handler. Puedes, por ejemplo, usar esto para transferir datos de la monitorización activa a otros sistemas.

¡Ten cuidado con esta configuración! Iniciar procesos y ejecutar scripts consume muchos recursos de la CPU. Checkmk puede ejecutar fácilmente 1000 comprobaciones por segundo, pero Linux seguramente no podría manejar 1000 scripts de alert handler por segundo.

Para que esto sea posible de forma útil, Checkmk ofrece la opción de escribir alert handlers como funciones de Python, que luego se ejecutan en línea, sin necesidad de crear procesos. Estos alert handlers en línea se pueden guardar en el mismo directorio que los scripts de alert handlers normales. El siguiente ejemplo funcional muestra la estructura de un alert handler en línea:

~/local/share/check_mk/alert_handlers/foo
#!/usr/bin/python
# Inline: yes

# Do some basic initialization (optional)
def handle_init():
    log("INIT")

# Called at shutdown (optional)
def handle_shutdown():
    log("SHUTDOWN")

# Called at every alert (mandatory)
def handle_alert(context):
    log("ALERT: %s" % context)
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Este script no tiene una función central, sino que simplemente define tres funciones, aunque solo se requiere la función handle_alert(). Esta se invoca tras cada ejecución de check y, en su argumento, context recibe un diccionario de Python con variables como "HOSTNAME", "SERVICEOUTPUT", etc. Estas representan las variables del entorno que también reciben los controladores normales; sin embargo, aquí sin el prefijo ALERT_. El ejemplo anterior se puede utilizar para ver el contenido de context.

Todas las salidas generadas por la función auxiliar log() se guardan en ~/var/log/alert.log. Las dos variables globales omd_root y omd_site se basan en el directorio de inicio y el nombre del site de Checkmk, respectivamente.

Checkmk invoca las funciones handle_init() y handle_shutdown() al iniciar o detener el core de monitorización y permiten realizar una inicialización, por ejemplo, al establecer una conexión con una base de datos.

Información adicional:

  • Fíjate en # Inline: yes en la segunda línea.

  • El core debe reiniciarse después de cada cambio en el script (omd restart cmc).

  • import Se permiten comandos.

  • Los asistentes de alertas de Checkmk invocan tus funciones de forma sincrónica. ¡Asegúrate de que no se produzcan estados de espera!

8. Ejecución remota en Linux

8.1. Principios básicos

Todas las versiones de Checkmk incluyen un alert handler integrado que permite la ejecución fiable de scripts en sistemas Linux supervisados. Las características más importantes de esta solución son:

  • Los scripts se ejecutan mediante SSH con restricción de comandos.

  • No se pueden utilizar comandos arbitrarios, sino solo aquellos que tú definas.

  • Todo esto se puede implementar mediante Agent bakery.

Los alert handlers remotos de Linux constan de los siguientes elementos individuales:

  • El alert handler «linux_remote» con el título «Linux via SSH» en el servidor Checkmk.

  • El script de «mk-remote-alert-handler» en el sistema de destino.

  • Los scripts («controladores remotos») que hayas escrito tú en el sistema de destino.

  • Entradas en .ssh/authorized_keys para aquellos usuarios del sistema de destino que los ejecutarán.

  • Reglas en Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux) que generan claves SSH.

  • Reglas de alert handler que invocan a linux_remote.

8.2. Configuración

Supongamos que quieres ejecutar el script de /etc/init.d/foo restart en el sistema Linux myserver123 cada vez que el servicio Process FOO entre en estado crítico (que ya hemos configurado). Proceda de la siguiente manera:

Codificación del gestor remoto

A continuación, escribe el script que se ejecutará en el sistema de destino. Como estamos trabajando con Agent bakery, instala el script en el servidor Checkmk (¡no en el sistema de destino!). El directorio correcto para esto es ~/local/share/check_mk/agents/linux/alert_handlers. Aquí también, el comentario de la segunda línea proporciona un título para la selección en la interfaz de usuario:

~/local/share/check_mk/agents/Linux/alert_handlers/restart_foo
#!/bin/bash
# Restart FOO service

/etc/init.d/foo restart || {
    echo "Could not restart FOO."
    exit 2
}
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Haz que el script sea ejecutable:

OMD[mysite]:~$ cd local/share/check_mk/agents/linux/alert_handlers
OMD[mysite]:~/local/share/check_mk/agents/linux/alert_handlers$ chmod +x restart_foo
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Nuestro script de ejemplo está diseñado de tal manera que, en caso de error, termina con un Código 2 para que el alert handler lo evalúe como unCRITo.

Preparación del paquete del agente con el gestor

Aquí describiremos el procedimiento con Agent bakery. Más abajo encontrarás consejos para la instalación manual.

Define una regla en «Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux)». En las propiedades, se puede ver el controlador remoto Restart FOO service que acabas de definir. Selecciónalo para la instalación:

alert handlers install remote

Una vez guardado, verás la regla en la lista: se ha generado automáticamente un par de claves SSH para llamar al handler, cuya huella digital aparecerá en la regla. La huella digital se ha acortado para ajustarse al ancho de esta captura de pantalla:

alert handlers install remote2

La clave pública está destinada al agente. La clave privada la necesitará más adelante el servidor Checkmk para que se pueda llamar a un script instalado de esta manera sin tener que introducir una contraseña.

También se puede utilizar otro usuario como root, naturalmente solo si tiene los derechos adecuados para la acción requerida. El agente Checkmk solo instalará la clave SSH en sistemas donde este usuario ya exista.

Crear agente

Ahora crea nuevos agentes con button bake agents. En la lista de agentes listos debería aparecer ahora una entrada en la que se puedan ver tu controlador remoto y tu clave SSH. La captura de pantalla también se ha acortado aquí. Esta vez, en la cantidad de paquetes que se pueden descargar:

alert handlers baked handler

Instalar el agente

A continuación, instala el paquete RPM o DEB en tu sistema de destino (la instalación del archivo TGZ no permite configurar la clave SSH y, por lo tanto, es incompleta). Con la instalación ocurren las siguientes cosas:

  • Se instalará tu script de control remoto.

  • Se instalará el programa auxiliar mk-remote-alert-handler.

  • Para los usuarios seleccionados (en este caso, root), se creará una entrada en authorized_keys que permitirá la ejecución del gestor.

  • Se crearán los directorios .ssh y authorized_keys según sea necesario.

Con una instalación mediante DEB, quedará algo así:

root@myserver123:~# dpkg -i check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb
Selecting previously unselected package check-mk-agent.
(Reading database ... 515080 files and directories currently installed.)
Preparing to unpack ...check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb ...
Unpacking check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Setting up check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Reloading xinetd...
 * Reloading internet superserver configuration xinetd                            [ OK ]
Package 9d3ab34905da4934: adding SSH keys for Linux remote alert handlers for user root...
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Al echar un vistazo a la configuración de SSH para root, se ve lo siguiente:

root@myserver123:~# cat /root/.ssh/authorized_keys
command="/usr/bin/mk-remote-alert-handler restart_foo",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAACAQCqoDVNFEbTqYEmhSZhUMvRy5SqGIPp1nE+EJGw1LITV/rej4AAiUUBYwMkeo5aBC6VOXkq78CdRuReSozec3krKkkwVbgYf98Wtc6N3WiljS85PLAVvPadJiJCkXFctbxyI2xeF5TQ1VKDRvzbBjXE9gjTnLWbPy77RC8SVXLoOQgabixpWQquIIdGyccPsWGTRgeI7Ua0lgWZQUJt7OIKQ0X7Syv2VHKJNqtW28IWu8y2hBEY/TERip5EQoNT/VclhHqjDG2y3F45PswcXD5in6y30EnfHGcwk+PD6fgp7jPGbO2+QBUwYgW67GmRpbaVQ97CqXFJvORNF+C6+O8DNweyH3ogspjfKvM7eN+M4NIJzjMRyNBMzqF3VmrMeqpzRjfFj2BS/8UbXGgHzZRapwrK3+GXX1pG49n77cIs+GWos9xb1DxX1pEu2tgQwRBBhYcTkk2eKkH18LKzFUyObxtQmf40C24cdQOp6USbwzsniqehsLIHH2unQ7bW6opF/GiaEjZamGbgsPOe8rmey5Vcd//e8cS+OsmcPZNybsTJpBeHpes+5bw0e1POw9GD9qptylrQLYIO5R467Ov8YlRFgYKyaDFHD40j5/JHPzmtp4vjH8Si7YZZOzvTRgBYEoEgbLS5dgdr/I5ZMRKfDPCpRUbGhp9kUEdGX99o5Q== mk-remote-alert-handler-9d3ab34905da4934
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ten en cuenta que tu sistema podría estar configurado de tal manera que, por lo general, no sea posible el acceso SSH como root. En este caso, puedes acceder a través de otro usuario y trabajar allí con sudo, que está configurado para que el comando deseado se pueda ejecutar sin contraseña.

Llamar al gestor mediante una regla

Ya casi hemos alcanzado nuestro objetivo. El agente está listo. Ahora solo falta una regla para invocar realmente el alert handler. El procedimiento es el descrito al principio de este artículo y se lleva a cabo mediante la creación de una regla adecuada. Esta vez, elige Linux via SSH como alert handler, introduce el usuario para el que se debe instalar la clave SSH y selecciona tu gestor remoto:

alert handlers rule foo

Establece también una condición razonable en la regla; de lo contrario, ¡se intentará establecer una conexión SSH con cada alerta de servicio!

Prueba

Cuando, por ejemplo, configures ahora manualmente el servicio correspondiente en CRIT, en el historial del servicio verás en breve:

alert handlers foo failing

Naturalmente, si no existe ningún servicio «foo», entonces «/etc/init.d/foo restart» tampoco puede funcionar. Sin embargo, se puede ver que este comando se ha procesado y que el estado de error se ha notificado correctamente. Del mismo modo, que Checkmk ha activado una notificación que fue detenida por un alert handler.

Por cierto, el mensaje «Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.» es inofensivo y solo aparece en el primer contacto con el host. Para evitar el laborioso intercambio manual de la clave del host, se invoca SSH con «-o StrictHostKeyChecking=false». En la primera conexión, la clave se almacenará para su uso futuro.

8.3. Configuración sin Agent bakery

Por supuesto, también funciona preparar un agente manualmente. En tal caso, te recomendamos realizar el procedimiento de Agent bakery en un sistema de prueba, examinar luego los datos relevantes y replicarlos manualmente en tu propio sistema. Aquí puedes encontrar una lista de las rutas de los archivos.

En este caso, también es importante que en Agent bakery crees una regla para instalar el gestor remoto, ya que en esta regla se generarán las claves SSH para el acceso y también para que las utilice el alert handler. La clave pública para la instalación en authorized_keys se encuentra en el archivo de configuración ~/etc/check_mk/conf.d/wato/rules.mk (o en una subcarpeta de rules.mk).

9. Archivos y directorios

9.1. Rutas en el servidor Checkmk

Ruta Función

~/var/log/alerts.log

Archivo de registro con todos los eventos relevantes para el alert handler (registrados por el asistente de alerta).

~/var/log/cmc.log

Archivo de registro del core. Aquí también se almacena parte de la información del alert handler.

~/local/share/check_mk/alert_handlers/

Guarda aquí tus alert handlers personalizados.

~/var/check_mk/core/history

Aquí se almacena el archivo de registro del historial de monitorización y también es evaluado por el core.

~/local/share/check_mk/agents/linux/alert_handlers/

Alert handlers remotos que se ejecutarán en sistemas Linux.

9.2. Rutas en el host Linux de monitorización

Ruta Función

/usr/bin/mk-remote-alert-handler

Script auxiliar para ejecutar los controladores remotos.

/usr/lib/check_mk_agent/alert_handlers/

Manejadores remotos escritos por ti.

/root/.ssh/authorized_keys

Configuración de SSH para el usuario root.

~harri/.ssh/authorized_keys

Configuración de SSH para el usuario harri.
Last modified: Thu, 05 Feb 2026 14:58:34 GMT via commit 4776cff3b
En esta página