Principios básicos de monitorización con Checkmk

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

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

Junto con el estado, un host tiene otra serie de atributos que el usuario puede configurar, por ejemplo

Para que la monitorización pueda determinar el estado UNREACH, debe saber qué ruta puede utilizar para ponerse en contacto con cada host individual. Para ello, se pueden especificar uno o más hosts denominados padres para cada host. Por ejemplo, si sólo se puede llegar a un servidor A visto desde la monitorización a través de un router B, entonces B es un host padre de A. En Checkmk sólo se configuran los padres directos. Esto da como resultado una estructura en forma de árbol con el site de Checkmk en el medio (mostrado aquí como ):

Supongamos que, en el ejemplo de topología de red mostrado anteriormente, los hosts myhost y myhost4 ya no son accesibles. El fallo de myhost4 puede explicarse por el hecho de que myhost ha fallado. Por tanto, myhost4 se clasifica como UNREACH en la monitorización. Simplemente no es posible determinar claramente por qué Checkmk ya no puede llegar a myhost4, por lo que el estado DOWN sería engañoso en algunas circunstancias. En cambio, el UNREACH tiene el efecto de suprimir las notificaciones por defecto. Al fin y al cabo, ésta es la tarea más importante del concepto de padres, es decir, evitar las notificaciones masivas en caso de que todo un segmento de red dependiente quede inalcanzable para la monitorización debido a una interrupción en un único punto.

La función Checkmk Micro Core (CMC) utilizada en las ediciones comerciales también sirve para evitar las falsas alarmas. En este caso, el cambio de estado de un host averiado se retiene unos instantes y sólo se produce cuando se tiene la certeza de que el padre aún está accesible. Si, por el contrario, el padre está definitivamente DOWN, el host pasará a UNREACH, sin que se active una notificación.

En algunos casos, un host puede tener varios padres, por ejemplo, cuando un router se ejecuta en 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á alcanzable. Así, cuando un host tiene varios padres y al menos uno de ellos está UP, el host se considera alcanzable en la monitorización. En otras palabras, en tal situación, el host no pasará automáticamente al estado UNREACH.

Un host tiene una serie de servicios. Un servicio puede ser cualquier cosa -no confundas esto con los servicios en Windows-. Un servicio es cualquier parte o aspecto del host que puede estar OK, o no OK. Naturalmente, el estado sólo puede determinarse si el host está en estado UP.

Un servicio en monitorización puede tener los siguientes estados:

Para determinar qué condición es "peor", Checkmk utiliza la siguiente secuencia:

OK → WARN → UNKNOWN → CRIT

Un check garantiza que se pueda asignar un estado a un host o a un servicio. En la sección anterior se describe qué estados pueden ser. Los servicios y los checks están estrechamente relacionados. Por eso, a veces se utilizan estos términos indistintamente, incluso en este Manual de usuario, aunque en realidad son cosas distintas.

En la Configuración puedes mostrar qué check plugin es responsable de cada servicio. Abre las propiedades de un host con Setup > Hosts y luego en el menú Hosts > Service Configuration la lista de los servicios de este host. A continuación, utiliza Display > Show plugin names para mostrar una nueva columna que mostrará el check plugin responsable de cada servicio:

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

La conexión y dependencia de servicios y comprobaciones también puede verse en la monitorización. En la lista de servicios de un host en monitorización, puedes ver que en el menú de acción de 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:

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 razones de rendimiento y es una característica especial de Checkmk.

Checkmk identifica cada host que no está UP y cada servicio que no está OK como un problema. Un problema puede tener dos estados: no tratado y tratado. El procedimiento es que un problema nuevo se trata primero como no tratado. En cuanto alguien reconozca (confirme) el problema, se marcará como tratado, y no es de extrañar, los problemas no tratados son los que aún no han sido atendidos. Por tanto, la Vista general de la barra lateral diferencia estos dos tipos de problemas:

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

Puedes encontrar más detalles sobre los Reconocimientos en su propio artículo, Reconocer problemas.

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 forma que, siempre que un host o un servicio tenga un problema, se envía un correo electrónico a los contactos del objeto (ten en cuenta que el usuario de cmkadmin, por defecto, no es un contacto para ningún objeto). Sin embargo, se pueden personalizar de forma muy flexible. Las notificaciones también dependen de una serie de parámetros. Lo más sencillo es ver 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 núcleo de monitorización crea una notificación, que en un segundo paso pasa por una cadena de reglas. En estas reglas puedes definir más criterios de exclusión y decidir a quién se debe notificar y de qué forma (correo electrónico, SMS, etc.).

Puedes encontrar todos los detalles sobre las notificaciones en su propio artículo sobre Notificaciones.

A veces ocurre que un servicio cambia de estado de forma rápida y continua. Para evitar las notificaciones continuas, Checkmk pone dicho servicio en estado inestable. Esto se ilustra 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. Después de un tiempo adecuado, si no se producen más cambios rápidos y es 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 posibles notificaciones de problemas durante este tiempo. Además, probablemente querrás avisar a tus compañeros de que los problemas que aparezcan en la monitorización durante este tiempo pueden ser ignorados temporalmente.

Para ello, puedes introducir una condición de tiempos de mantenimiento programados en un host o servicio. Esto puede hacerse directamente antes de iniciar el trabajo, o con antelación. Los tiempos de mantenimiento programados se ilustran con los iconos:

Mientras un host o servicio tenga un tiempo de mantenimiento programado:

Además, cuando quieras documentar posteriormente estadísticas sobre la disponibilidad de host y servicios, es una buena idea incluir los tiempos de mantenimiento programados, ya que pueden tenerse en cuenta en posteriores evaluaciones de la disponibilidad.

Si llevas tiempo trabajando con Checkmk, es posible que aparezcan telarañas en tus vistas de host y servicios. En el caso de los servicios, por ejemplo, tiene este aspecto:

Estas telarañas simbolizan el estado obsoleto. Siempre que haya un host o un servicio obsoleto, también se mostrará en el complemento Overview snap-in, 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 host y los servicios se vuelven obsoletos. Para ello, lee la sección sobre intervalos de check.

Puedes restringir los periodos de tiempo en los que se ejecutan los checks. Los conjuntos de reglas Check period for hosts, Check period for active services y Check period for passive Checkmk services sirven para este propósito. Utiliza 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 por defecto un minuto para las comprobaciones de servicio y 6 segundos para las comprobaciones de host con un Smart Ping.

Estos valores predeterminados pueden anularse 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 un check activo se ejecuta precisamente una vez al día a una hora muy concreta. Por ejemplo, si estableces el intervalo de check en 24 horas y el periodo de check en 2:00 a 2:01 cada día (es decir, sólo un minuto al día), Checkmk se asegurará de que el check se desplaza realmente 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 el ajuste global Staleness value to mark hosts / services stale puedes definir cuánto tiempo debe pasar antes de que un host/servicio pase a obsoleto. Este ajuste se encuentra en Setup > General > Global settings > User interface:

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

Con la ayuda de la opción 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. Para ello puedes utilizar los conjuntos de reglas Maximum number of check attempts for host y Maximum number of check attempts for service.

Si los intentos de comprobación se fijan en 3, por ejemplo, y el servicio correspondiente se convierte en CRIT, inicialmente no se activará ninguna notificación. Sólo si las dos comprobaciones siguientes también producen un resultado que no es OK, el recuento de los intentos actuales aumentará a 3 y se enviará la notificación.

Un servicio que se encuentre en este estado intermedio -es decir, que no esté OK pero que aún no haya alcanzado el número máximo de intentos de check- tendrá un soft state. Sólo un hard state activará realmente una notificación.