Principios básicos de monitorización con Checkmk

Todo en Checkmk gira en torno a los hosts y los servicios. Un host puede ser muchas cosas, por ejemplo:

En la monitorización, un host siempre tiene uno de los siguientes estados:

Además del estado, un host tiene otros atributos que el usuario puede configurar, por ejemplo:

Para que la monitorización pueda determinar el estado de UNREACH, debe saber qué ruta puede utilizar para establecer contacto con cada host individual. Para ello, se pueden especificar uno o más de los llamados hosts padres para cada host. Por ejemplo, si un servidor A, tal y como se ve desde el sistema de monitorización, solo es accesible a través de un router B, entonces B es un host padre de A. En Checkmk solo se configuran los padres directos. Esto da lugar a una estructura en forma de árbol con el site de Checkmk en el centro (que aquí se muestra como ):

Supongamos que, en el ejemplo de topología de red mostrado arriba, ya no se puede acceder a los hosts myhost y myhost4. El fallo de myhost4 se puede explicar por el hecho de que myhost ha fallado. Por lo tanto, myhost4 se clasifica como «UNREACH» en la monitorización. Simplemente no es posible determinar con claridad por qué Checkmk ya no puede acceder a myhost4, por lo que el estado «DOWN» podría resultar engañoso en algunas circunstancias. En cambio, el «UNREACH» tiene el efecto de suprimir las notificaciones por defecto. Esta es, al fin y al cabo, la tarea más importante del concepto de «parents», es decir, evitar notificaciones masivas en caso de que todo un segmento de red dependiente quede inaccesible para la monitorización debido a una interrupción en un único punto.

La prevención de falsas alarmas también se ve favorecida por una función del Checkmk Micro Core (CMC) que se usa en las ediciones comerciales. Aquí, el cambio de estado de un host que ha fallado se retrasa unos instantes y solo se lleva a cabo cuando se tiene la certeza de que el padre sigue siendo accesible. Si, por el contrario, el padre está definitivamente «DOWN», el host pasará a «UNREACH» sin que se active ninguna notificación.

En algunos casos, un host podría tener varios padres, por ejemplo, cuando un router funciona con alta disponibilidad en un clúster. Basta con que Checkmk pueda determinar de forma única el estado del host cuando uno de estos padres está accesible. Por lo tanto, cuando un host tiene varios padres y al menos uno de ellos está UP, el host se considera accesible en la monitorización. En otras palabras, en tal situación, el host no pasará automáticamente al estado UNREACH.

Un host tiene varios servicios. Un servicio puede ser cualquier cosa; no lo confundas con los servicios de Windows. Un servicio es cualquier parte o aspecto del host que puede estar «OK» o «not OK». Naturalmente, el estado solo se puede determinar si el host está en estado «UP».

Un servicio que se está sometiendo a monitorización puede tener los siguientes estados:

A la hora de determinar qué condición es «peor», Checkmk utiliza la siguiente secuencia:

OK → WARN → UNKNOWN → CRIT

Una comprobación garantiza que se pueda asignar un estado a un host o a un servicio. En la sección anterior se describe cuáles pueden ser estos estados. Los servicios y las comprobaciones están estrechamente relacionados. Por este motivo, estos términos se utilizan a veces indistintamente, quizá incluso en este Manual de usuario, aunque en realidad son cosas diferentes.

En la configuración puedes ver qué check plugin se encarga de cada servicio. Abre las propiedades de un host con «Setup > Hosts» y, a continuación, en el menú «Host > Run service discovery», la lista de servicios de este host. Después, usa «Display > Show plugin names» para mostrar una nueva columna que indicará el check plugin responsable de cada servicio:

Como puedes ver en el ejemplo del check plugin df, un check plugin puede ser responsable de más de un servicio. Por cierto, los nombres de los check plugins que aparecen en la lista también son enlaces que muestran una descripción del check plugin.

La conexión y la dependencia entre servicios y comprobaciones también se pueden ver en la monitorización. En la lista de servicios de un host en la monitorización, puedes ver que en el menú de acciones de «», en la entrada «Reschedule», hay una flecha amarilla para algunos servicios (), pero una flecha gris para la mayoría de los demás (). Un servicio con la flecha amarilla se basa en una comprobación activa:

Dicha comprobación activa la ejecuta directamente Checkmk. Los servicios con la flecha gris se basan en comprobaciones pasivas cuyos datos se obtienen de otro servicio, el servicio Check_MK. Esto se hace por motivos de rendimiento y es una característica especial de Checkmk.

Checkmk identifica como problema a cualquier host que no esté en UP y a cualquier servicio que no esté en OK. Un problema puede tener dos estados: no tratado y procesado. El procedimiento es que un problema nuevo se trata primero como no tratado. En cuanto alguien reconozca el problema, se marcará como procesado y, como es lógico, los problemas no tratados son aquellos a los que aún no se ha prestado atención. Por eso, la Vista general de la barra lateral distingue estos dos tipos de problemas:

Por cierto: los problemas de servicio de hosts que actualmente no están UP no se identifican como problemas.

Puedes encontrar más detalles sobre los reconocimientos en su propio artículo.

Cuando cambia el estado de un host (por ejemplo, de «OK» a «CRIT»), Checkmk registra un evento de monitorización. Estos eventos pueden generar o no una notificación. Checkmk está diseñado de tal manera que, cada vez que un host o un servicio tiene un problema, se envía un correo electrónico a los contactos del objeto (ten en cuenta que, por defecto, ningún usuario recién creado es contacto de ningún objeto). Sin embargo, esto se puede personalizar con mucha flexibilidad. Las notificaciones también dependen de varios parámetros. Lo más sencillo es fijarnos en los casos en los que no se envían notificaciones. Las notificaciones se suprimen …​

Si no se cumple ninguno de estos requisitos previos para suprimir las notificaciones, el core de monitorización crea una notificación, que en un segundo paso pasa por una secuencia de reglas. En estas reglas puedes definir criterios de exclusión adicionales y decidir a quién se debe notificar y de qué forma (correo electrónico, SMS, etc.)

Todos los detalles relativos a las notificaciones se pueden encontrar en el artículo dedicado a las notificaciones.

A veces ocurre que un servicio cambia de condición de forma continua y rápida. Para evitar notificaciones continuas, Checkmk pone ese servicio en condición inestable. Esto se indica con el icono «».

Cuando un servicio entra en estado inestable, se genera una notificación que informa al usuario de la situación y silencia las notificaciones posteriores. Tras un tiempo adecuado, si no se producen más cambios rápidos y se hace evidente un estado final (bueno o malo), el estado inestable desaparece y se reanudan las notificaciones normales.

Si realizas tareas de mantenimiento en un servidor, dispositivo o software, normalmente querrás evitar las notificaciones de problemas durante ese tiempo. Además, probablemente querrás avisar a tus compañeros de que los problemas que aparezcan en la monitorización durante ese tiempo pueden ignorarse temporalmente.

Para ello, puedes introducir una condición de tiempo de mantenimiento programado en un host o servicio. Esto se puede hacer justo antes de comenzar el trabajo o con antelación. El tiempo de mantenimiento programado se indica con los siguientes iconos:

Mientras un host o servicio se encuentra en un periodo de tiempo de mantenimiento programado:

Además, si más adelante quieres documentar estadísticas sobre la disponibilidad de los hosts y servicios, es buena idea incluir el tiempo de mantenimiento programado. Este se puede tener en cuenta en evaluaciones de disponibilidad posteriores.

Si llevas un tiempo trabajando con Checkmk, es posible que aparezcan telarañas en tus vistas de tablas de hosts y servicios. En el caso de los servicios, por ejemplo, se ve así:

Estas telarañas simbolizan el estado obsoleto. Siempre que haya un host o servicio obsoleto, esto también se mostrará en el snap-in «Overview», que se ampliará con la columna «Stale».

Pero, ¿qué significa exactamente el estado obsoleto? En general, un host o servicio se marca como obsoleto cuando Checkmk deja de recibir información actualizada sobre su estado durante un periodo de tiempo prolongado:

Puedes ajustar el límite de tiempo tras el cual los hosts y los servicios se consideran obsoletos. Para ello, lee la sección sobre intervalos de comprobación.

Puedes restringir los periodos de tiempo en los que se ejecutan las comprobaciones. Los conjuntos de reglas Check period for hosts, Check period for active services y Check period for passive Checkmk services sirven para esto. Usa estas reglas para seleccionar uno de los periodos de tiempo disponibles como periodo de check.

Las comprobaciones se ejecutan a intervalos fijos dentro de la monitorización basada en el estado. Checkmk utiliza un valor predeterminado de un minuto para las comprobaciones de servicio y de 6 segundos para las comprobaciones de host con Smart Ping.

Estos valores predeterminados se pueden anular utilizando los conjuntos de reglas «Normal check interval for service checks» y «Normal check interval for host checks»:

Si ahora combinas un periodo de check con un intervalo de check, puedes asegurarte de que una comprobación activa se ejecute exactamente una vez al día a una hora muy concreta. Por ejemplo, si configuras el intervalo de check en 24 horas y el periodo de check de 2:00 a 2:01 todos los días (es decir, solo un minuto al día), Checkmk se asegurará de que la comprobación se traslade efectivamente a esta breve ventana de tiempo.

El estado de los servicios ya no se actualizará fuera de este periodo de check definido y los servicios se marcarán como obsoletos con el icono «». Con la configuración global «Staleness value to mark hosts / services stale» puedes definir cuánto tiempo debe pasar antes de que un host/servicio se considere obsoleto. Esta configuración se encuentra en «Setup > General > Global settings > User interface:»

Este factor representa n veces el intervalo de check. Así que si tu intervalo de check está fijado en un minuto (60 segundos), un servicio para el que no haya nuevos resultados de check pasará a estar obsoleto tras 1,5 veces ese tiempo, es decir, tras 90 segundos.

Con la ayuda de la opción de intentos de comprobación, puedes evitar notificaciones en caso de errores esporádicos. Esto hace que una comprobación sea menos sensible, por así decirlo. Puedes utilizar los conjuntos de reglas Maximum number of check attempts for host y Maximum number of check attempts for service para este fin.

Si los intentos de comprobación se establecen en 3, por ejemplo, y el servicio correspondiente pasa a estar «CRIT», inicialmente no se activará ninguna notificación. Solo si las dos comprobaciones siguientes también dan un resultado que no sea «OK», el recuento de intentos actuales aumentará a 3 y se enviará la notificación.

Un servicio que se encuentre en este estado intermedio —es decir, que no sea «OK» pero que aún no haya alcanzado el número máximo de intentos de check— tendrá un soft state. Solo un hard state activará realmente una notificación.