Disponibilidad

Dado que Checkmk realiza continuamente la monitorización de todos los hosts y servicios a intervalos regulares, ofrece una base excepcional para la evaluación posterior de su disponibilidad. Y no solo eso: también permite calcular durante qué porcentaje de un intervalo de tiempo determinado un objeto se encontraba en uno o varios estados específicos, con qué frecuencia se produjo ese estado, la duración de su interrupción más larga y mucho más.

Cada cálculo se basa en una selección de objetos y un intervalo de tiempo específico en 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 cada estado, se suman los tiempos y se muestran en una tabla. Esta tabla puede, por ejemplo, mostrar que un servicio concreto experimentó estados del 99,95 % OK y del 0,005 % WARN durante 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 mantenimiento de servicio, los intervalos de tiempo no monitorizados y otros factores especiales, permite resumir los estados e ignorar las «breves interrupciones». También hay disponibles numerosas opciones de personalización. También es posible disponer de Agregaciones BI.

Al incluir tiempos de mantenimiento programados y estados especiales similares, en teoría hay un gran número de combinaciones posibles de estados, por ejemplo: CRIT + In Planned Maintenance + In Service Time + Inestable. Como la mayoría de estas combinaciones no son muy útiles, Checkmk las reduce a un número reducido y, al hacerlo, sigue un principio de prioridades. Dado que en el ejemplo anterior el servicio se encontraba en un tiempo de mantenimiento programado, simplemente se aplica el estado «in scheduled downtime», y se ignora el estado real. Esto reduce la lista de estados posibles a lo siguiente:

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

Generar un análisis de disponibilidad es muy sencillo. Primero, recupera cualquier vista de hosts, servicios o Agregaciones BI. Allí encontrarás en el menú «Services» o «Hosts» el elemento «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 de tabla anterior. En cada columna se muestra la proporción del intervalo de tiempo solicitado en la que un objeto se encontraba en el estado que se está consultando. El valor se da en forma de porcentaje, por defecto con dos decimales, lo cual también puedes personalizar fácilmente.

La consulta del intervalo de tiempo se puede personalizar con el elemento de menú «Availability > Change display options > Time Range». Más sobre esto más adelante…​

Tienes la opción de recibir la tabla en formato PDF (solo ediciones comerciales). También es posible descargar los datos en formato CSV: (Export as CSV). En el ejemplo anterior, quedaría así:

Con la ayuda de un usuario de automatización, que puede autentificarse a través de la URL, también puedes recuperar datos —por ejemplo, con wgeto curl— y procesarlos automáticamente bajo el control de un script.

El símbolo se encuentra en cada fila de la tabla. Este botón te lleva a una visualización de la línea de tiempo del objeto en cuestión, en la que se detallan con precisión los cambios de estado que se produjeron 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 prellenado («Propiedades») en el que se pueden introducir comentarios:

Con esto 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 más amplio que haya experimentado cambios de estado repetidos. Si no introduces ningún servicio, la anotación se creará para el host. Esta se relacionará automáticamente con todos los servicios del host.

En todas las vistas de tabla de disponibilidad, todas las anotaciones aplicables al intervalo de tiempo y a los objetos que se muestran serán visibles automáticamente.

Pero las anotaciones tienen una función adicional. Los tiempos de mantenimiento se pueden introducir retrospectivamente —o, por el contrario, eliminar. El análisis de disponibilidad tiene en cuenta estas correcciones exactamente de la misma manera que con los tiempos de mantenimiento «normales». Hay al menos dos justificaciones legítimas para esto:

Para reclasificar los tiempos de mantenimiento, solo tienes que marcar la 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 una vista del historial de monitorización con un filtro preconfigurado para el objeto relevante y el intervalo de tiempo de la consulta. Aquí no solo 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 disponibilidad se remonta aún más atrás en el tiempo para determinar de forma fiable el estado inicial.

Hay muchas opciones que influyen en el formato de las visualizaciones, mientras que otras, a su vez, influyen en los métodos de cálculo. Para empezar, echemos un vistazo a las visualizaciones:

Los estados descritos en la introducción se pueden personalizar y condensar 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 genera mensajes de problemas momentáneos, pero en condiciones normales el objeto ya está eOKe cuando se ejecuta la siguiente check (al cabo de un minuto)—y no se ha encontrado ninguna forma, mediante el ajuste de umbrales o medidas similares, de controlar adecuadamente estos casos. Una solución habitual es configurar el Maximum number of check attempts entre 1 y 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 o UNKNOWN— siempre que no se hayan «agotado» todos los intentos permitidos.

De vez en cuando, los usuarios que usan esta función nos preguntan por qué el módulo de disponibilidad de Checkmk no tiene una función para calcular usando solo Hard states. La razón es esta: ¡hay una solución mejor! Se podrían usar los hard states como base…​

La opción «Short time Intervals» es mucho más flexible y, al mismo tiempo, muy sencilla. Solo tienes que definir un periodo de tiempo que debe superarse antes de 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 en estado «OK», luego en «CRIT» durante 2 minutos, y luego vuelve a «OK», el breve intervalo de tiempo «CRIT» simplemente se evaluará como «OK». ¡Por cierto, la situación opuesta también funciona! Un breve «OK» dentro de una larga fase «WARN» se evaluará igualmente como «WARN».

En términos generales, los intervalos cortos en los que antes y después prevalece el mismo estado recibirán ese mismo estado. Para una secuencia deOK , seguida de un intervalo de 2 minutosWARN y, a continuación,CRIT , elWARN persistirá, ¡incluso si su duración fue menor que el tiempo definido!

Ten en cuenta al definir el tiempo que, en Checkmk, el intervalo de comprobación estándar es de un minuto. Por lo tanto, cada estado tiene una duración de múltiplos de aproximadamente un minuto. Como los tiempos de respuesta reales del agente varían ligeramente, esto puede ser fácilmente 61 o 59 segundos. Por lo tanto, es más seguro no introducir minutos exactos como valor, sino incluir un margen de seguridad —de ahí el ejemplo de 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 hacerse en función de periodos de tiempo. Con esto se pueden definir horarios para cada host o servicio individual. En esos horarios se espera que el host/servicio esté disponible y se utilizará entonces el estado para los cálculos. Por lo tanto, cada objeto tiene el atributo «Service period». El procedimiento es el siguiente:

Aquí hay tres posibilidades sencillas. La configuración predeterminada de « Base report only on service times» oculta los tiempos fuera de los horarios de servicio definidos. Estos tiempos ocultos no cuentan para el 100 %. Solo se tendrán en cuenta los intervalos de tiempo dentro de los horarios 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 hace lo contrario, y, en efecto, calcula la visualización inversa: ¿qué tal fue la disponibilidad fuera del horario de servicio?

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

Por cierto: si un host no está en el horario de servicio, para Checkmk eso no significa 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 todo el historial del objeto seleccionado. Más abajo puedes ver cómo funciona esto en detalle. Especialmente en Checkmk Community, el análisis puede tardar un rato, ya que su core 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 bloquee un proceso de Apache, consuma CPU y, por lo tanto, se «cuelgue», hay dos opciones para limitar la duración del cálculo. Ambas están activadas por defecto:

La opción «Query time limit» limita la duración de la consulta subyacente al core de monitorización a un tiempo especificado. Está predefinida en treinta segundos. Si se supera este tiempo, el análisis se abortará y se mostrará un error. Si estás seguro de que el análisis puede ejecutarse durante más tiempo, simplemente aumenta el timeout manualmente.

La opción «Limit processed data» protege contra cálculos con muchos objetos. Aquí se aplicará un límite que funciona de forma análoga al de las vistas de tabla. Si la consulta al core de monitorización genera más de 5000 periodos de tiempo, el cálculo se abortará con una advertencia. La limitación se habrá procesado previamente en el core, donde se recopilan 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 exacto de los respectivos agregados en un momento concreto utilizando los protocolos de los estados de los hosts y servicios individuales.

¿Por qué tanto tiempo y esfuerzo? ¿Por qué no simplemente 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 hosts y los servicios. Selecciona una vista con una o más 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 similar 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 de la línea de tiempo de «». El siguiente ejemplo muestra un agregado en nuestro servidor de demostración, que estuvo «CRIT» durante un intervalo de tiempo muy breve de un segundo (este 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 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 vista de la Agregación BI en ese momento —en la siguiente imagen, ya abierta en la ubicación correcta:

Para calcular la disponibilidad, Checkmk accede a los registros del historial de monitorización archivados y, para ello, se basa en 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 alerta HOST ALERTo SERVICE ALERT, y tienen este aspecto, por ejemplo:

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

La interfaz de usuario no accede a estos archivos directamente, sino que los consulta mediante una consulta Livestatus emitida desde el core de monitorización. Entre otros factores, esto es importante porque en una monitorización distribuida los archivos de 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 primeros pasos de cálculo, que llevan mucho tiempo. Entre otras cosas, se encarga de revisar el historial para determinar el estado inicial y de calcular los periodos de tiempo con el mismo estado, con sus inicios, duraciones y finales.

El procedimiento de condensación de los estados lo lleva a cabo el Módulo de Disponibilidad en la Vista general del usuario, tal y como se describe al principio de este artículo.