Disponibilidad

Como Checkmk monitoriza continuamente todos los host y servicios a intervalos regulares, proporciona una base excepcional para la evaluación posterior de su disponibilidad. Y no sólo eso: también se puede calcular durante qué porcentaje de un intervalo de tiempo determinado un objeto estuvo en un estado o estados especificados, con qué frecuencia se produjo este estado, la duración de su parada más larga, y mucho más.

Cada cálculo se basa en una selección de objetos y unintervalo de tiempo especificadoen el pasado. A continuación, Checkmk reconstruye, dentro de este intervalo de tiempo, una secuencia cronológica de los estados de todos los objetos seleccionados. Por estado, se sumarán los tiempos y se mostrarán en una tabla. Esta tabla puede, por ejemplo, mostrar que un servicio concreto experimentó estados de 99,95 % OK, y 0,005 % WARN en el intervalo de tiempo definido.

Al realizar estos cálculos, Checkmk también tiene en cuenta correctamente factores como los tiempos de mantenimiento programados, los tiempos de inactividad del servicio, los intervalos de tiempo no supervisados y otros factores especiales, permite resumir los estados e ignorar las "interrupciones breves". También dispone de numerosas opciones de personalización y de la posibilidad de realizar Agregaciones BI.

Mediante la inclusión de tiempos de mantenimiento programados y estados especiales similares, existe en teoría un gran número de combinaciones posibles de estados, por ejemplo: CRIT + En tiempo de inactividad programado + En tiempo de mantenimiento + Inestable. Como la mayoría de estas combinaciones no son muy útiles, Checkmk las reduce a un número pequeño y, al hacerlo, procede según un principio de prioridades. Como en el ejemplo anterior el servicio estaba en tiempo de inactividad programado, simplemente se aplica el estado in scheduled downtime, y se ignora el estado real. Esto reduce la lista de estados posibles a los siguientes:

Este gráfico muestra el orden de prioridad de los estados. Más adelante mostraremos cómo se pueden ignorar o combinar algunos estados. Aquí están de nuevo los estados, en detalle:

Generar un análisis de disponibilidad es muy sencillo. Primero recupera cualquiervista de host, servicios o Agregaciones BI. Allí encontrarás en el menú Services o en Hosts el item Availability, que te lleva directamente al cálculo de la disponibilidad de los objetos seleccionados. Los datos se mostrarán en forma de tabla:

La tabla muestra los mismos objetos que se veían en la vista anterior. En cada columna se muestra la proporción del intervalo de tiempo solicitado en que un objeto se encontraba en el estado consultado. El valor se da en forma de porcentaje, por defecto con dos decimales, que también puedes personalizar fácilmente.

La consulta del intervalo de tiempo se puede personalizar con la opción de menú Availability > Change display options > Time Range item de menú. Más sobre esto más adelante...

Tienes la opción de recibir la tabla en formato PDF (sólo ediciones comerciales). También es posible descargar los datos en formato CSV (Export as CSV). Tendrá el siguiente aspecto para el ejemplo anterior:

Con la ayuda de un usuario de automatización, que puede autenticarse a través de la URL, también puedes recuperar datos -por ejemplo, conwget o curl) - y procesarlos automáticamente bajo el control del script.

Este botón te lleva a una visualización de la línea de tiempo del objeto correspondiente, en la que se detalla con precisión qué cambio(s) de estado se produjo(n) en el intervalo de tiempo especificado (abreviado aquí):

Algunos consejos útiles:

Como acabamos de mencionar, con el símbolo las líneas de tiempo ofrecen la posibilidad de añadir una anotación a un periodo de tiempo. Se proporciona un formulario precargado ("Propiedades") en el que se pueden introducir comentarios:

Con él puedes definir y ampliar el intervalo de tiempo con diferentes valores, según sea necesario. Esto resulta práctico, por ejemplo, si deseas anotar un intervalo de tiempo mayor que haya experimentado cambios de estado repetidos. Si omites introducir un servicio, la anotación se creará para el host, y se relacionará automáticamente con todos los servicios del host.

En cada vista de tabla de disponibilidad serán visibles automáticamente todas las anotaciones aplicables al intervalo de tiempo y a los objetos visualizados.

Pero las anotaciones tienen una función adicional. Los tiempos de mantenimiento pueden introducirse a posteriori o, por el contrario, eliminarse. El análisis de disponibilidad tiene en cuenta estas correcciones exactamente igual que con los tiempos de mantenimiento "normales". Hay al menos dos justificaciones legítimas para ello:

Para reclasificar los tiempos de mantenimiento, simplemente selecciona el checkbox Reclassify downtime of this period:

En la tabla de disponibilidad, junto al símbolo de la línea de tiempo se encuentra otro símbolo: . Esto te lleva a unavista del historial de monitorización con un filtro pre-rellenado para el objeto relevante y el intervalo de tiempo para la consulta. Aquí no sólo verás el evento en el que se basa el análisis de disponibilidad (los cambios de estado), sino también las notificaciones asociadas y eventos similares:

Lo que no se ve aquí es el estado del objeto al inicio del periodo de tiempo de la consulta. El cálculo de la disponibilidad mira aún más atrás en el pasado para determinar con fiabilidad el estado inicial.

Muchas opciones influyen en el formato de las visualizaciones, mientras que otras, a su vez, influyen en los métodos de cálculo. Para empezar, veamos las visualizaciones:

Los estados descritos en la introducción pueden personalizarse y condensarse de muchas maneras. De este modo se pueden generar de forma flexible formas de evaluación muy diferentes. Hay varias opciones para ello.

A veces la monitorización suele producir mensajes de problemas momentáneos, pero en condiciones normales el objeto ya está OK para cuando se ejecuta el siguiente check (al cabo de un minuto) - y no se ha encontrado ninguna forma mediante el ajuste de umbrales o similares de controlar bien estos casos. Una solución habitual es establecer el umbralMaximum number of check attempts de 1 a 3 para permitir más fallos antes de que se active una notificación. Así se ha desarrollado el concepto de Soft states, es decir, los estados WARN, CRIT oUNKNOWN, siempre que no se hayan "agotado" todos los intentos permitidos.

A veces, los usuarios que utilizan esta función nos preguntan por qué el Módulo de Disponibilidad de Checkmk no tiene una función para calcular utilizando sólo Hard states. La razón es la siguiente: Hay una solución mejor! Se podrían utilizar los hard states como base...

La opción Short time Intervals es mucho más flexible y al mismo tiempo muy sencilla. Basta con definir un tiempo que debe superarse para que se evalúen los estados.

Supongamos que el valor de tiempo se ha fijado en 2,5 minutos (150 segundos). Si un servicio ha estado continuamente OK, luego está CRIT durante 2 minutos, y después vuelve a estar OK, ¡el breve intervalo CRIT simplemente se evaluará como OK! La situación contraria, por cierto, ¡también funciona! Un breve OK dentro de una largafase WARN también se considerará WARN.

En general, los intervalos cortos en los que antes y después prevalezca el mismo estado, recibirán ese mismo estado. Para una secuencia de OK, luego un WARN de 2 minutos, seguido de CRIT, el WARNpersistirá, ¡aunque fuera de una duración inferior a la definida!

Ten en cuenta, al definir el tiempo, que en Checkmk el intervalo de check estándar es de un minuto. Por tanto, cada estado tiene una duración de múltiplos deaproximadamente un minuto. Como los tiempos de respuesta reales del agente varían ligeramente, esto puede ser fácilmente 61 ó 59 segundos, por lo que es más seguro no introducir minutos exactos para el valor, sino incluir un búfer -de ahí el ejemplo con 2,5 minutos.

Una función importante de los cálculos de disponibilidad en las ediciones comerciales de Checkmk es que estos cálculos pueden depender de periodos de tiempo. Con esto se pueden definir periodicidades para cada host o servicio individual. En estas periodicidades se espera que el host/servicio esté disponible y el estado se utiliza entonces para los cálculos. Por tanto, cada objeto tiene el atributo Service period. El procedimiento es el siguiente:

Aquí hay tres posibilidades sencillas. Por defecto,Base report only on service times oculta los tiempos fuera de los tiempos de servicio definidos. Estos tiempos ocultos no cuentan para el 100 %. Sólo se tendrán en cuenta los intervalos de tiempo dentro de los tiempos de servicio. En la visualización de la línea de tiempo, los tiempos restantes aparecerán "en gris".

Base report only on non-service times realiza lo contrario y, en efecto, calcula la visualización inversa: ¿Cómo de buena era la disponibilidadfuera de los tiempos de servicio?

La tercera opción Include both service and non-service times desactiva el concepto completo de tiempos de servicio y muestra los cálculos para todos los tiempos desde las 00:00 del lunes hasta las 24:00 del domingo.

Por cierto: Si un host no está en el tiempo de servicio, para Checkmk nosignifica automáticamente que esto también se aplique a los servicios del host. Los servicios siempre requieren su propia regla en Service period for services.

Al calcular la disponibilidad, hay que volver a abrir el historial completo del objeto seleccionado.Más adelante se explica en detalle cómo funciona. Especialmente en Checkmk Raw, el análisis puede llevar cierto tiempo, ya que su núcleo no tiene caché para los datos necesarios y hay que buscar secuencialmente en los datos de registro basados en texto.

Para que una consulta excesivamente compleja -que posiblemente se haya iniciado sin querer- no atasque un proceso Apache, consuma CPU y, por tanto, se "cuelgue", existen dos opciones para limitar la duración del cálculo. Ambas están activadas por defecto:

La Query time limit limita la duración de la consulta subyacente al núcleo de monitorización a un tiempo determinado. Si se supera este tiempo, el análisis se interrumpirá y se mostrará un mensaje de error. Si estás seguro de que el análisis se puede ejecutar durante más tiempo, simplemente aumenta el timeout manualmente.

La opción Limit processed data protege de los cálculos con muchos objetos. Aquí se aplicará un límite que funciona de forma análoga al de lasvistas. Si la consulta al núcleo de monitorización produce más de 5000 periodos de tiempo, el cálculo se interrumpirá con un aviso. La limitación se habrá preprocesado en el núcleo, donde se recogen los datos.

Una potente característica del cálculo de disponibilidad de Checkmk es la posibilidad de calcular la disponibilidad a partir de agregaciones BI. El gran atractivo aquí es que, para ello, Checkmk reconstruye retroactivamente el estado preciso de los respectivos agregados en un momento determinado utilizando los protocolos de los estados de los host y servicios individuales.

¿Por qué tanto tiempo y esfuerzo? ¿Por qué no limitarse a consultar la Agregación BI con un Check activo, y luego mostrar su disponibilidad? Bueno, el esfuerzo tiene bastantes ventajas para el usuario:

La recuperación de la vista de disponibilidad es inicialmente análoga a la de los host y servicios. Selecciona una vista con una o varias agregaciones BI, y selecciona el elemento de menú BI Aggregations > Availability. Aquí también hay un segundo método: cada agregación BI tiene una ruta directa a su disponibilidad mediante el símbolo:

En sí mismo, el cálculo es inicialmente análogo al de los servicios, pero sin las columnas Host down y flapping, ya que estos estados no existen para BI:

La gran diferencia está en la vista de tabla temporal. El siguiente ejemplo muestra un agregado en nuestro servidor de demostración, que fue CRITdurante un intervalo muy breve de un segundo (éste sería un buen ejemplo para el uso de la opción Short time intervals ).

¿Quieres saber cuál fue la causa de la interrupción? Basta con un simple clic en la varita mágica. Esto permite un viaje en el tiempo hasta el momento exacto en que se produjo la interrupción, y abre una visualización de la Agregación BI en ese momento -en la imagen siguiente, ya abierta en el lugar correcto-:

Para calcular la disponibilidad, Checkmk accede a los historiales de monitorización archivados, y para ello se orienta a los cambios de estado. Si, por ejemplo, a las 17:14 del 20/10/2021 un servicio cambia su estado a CRIT, y luego a las 17:24 vuelve a cambiar a OK, entonces sabes que durante ese periodo de tiempo de 10 minutos el servicio estuvo en estado CRIT.

Estos cambios de estado se registran en el registro de monitorización, tienen el tipo de alertaHOST ALERT o SERVICE ALERT, y tienen el siguiente aspecto, por ejemplo:

Siempre hay un archivo de registro actual que incluye entradas para la actividad más reciente hasta el momento actual, así como un directorio con un archivo de los periodos anteriores. La ubicación de estos archivos varía, dependiendo del núcleo de monitorización en uso:

La interfaz de usuario no accede directamente a estos archivos, sino que los consulta mediante una consulta Livestatus emitida desde el núcleo de monitorización. Entre otros factores, esto es importante porque en unamonitorización distribuida los archivos del historial no se almacenan en el mismo sistema que la GUI.

La consulta Livestatus utiliza la tabla statehist. A diferencia de la tabla log, que proporciona un acceso "desnudo" al historial, aquí se utiliza la tabla statehist porque ya ha realizado los pasos iniciales de cálculo, que consumen mucho tiempo. Entre otras cosas, asume la tarea de retroceder en el historial para determinar el estado inicial, y el cálculo de periodos de tiempo con el mismo estado, con sus inicios, duraciones y finales.

El procedimiento de condensación de los estados se realiza en la visión general del usuario mediante el Módulo de Disponibilidad, como se describe al principio de este artículo.