 |
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
En las comprobaciones que miden valores de rendimiento, a menudo resulta difícil establecer los umbrales correctos.
Mientras que unos valores demasiado bajos generan estados de «WARN» o «CRIT» que supuestamente solo indican problemas, establecerlos demasiado altos los deja en un estado de «OK», lo que hace que la monitorización pase por alto los problemas.
Tomemos como ejemplo el servicio CPU load en un host Linux (o, de forma similar, Processor Queue en un host Windows): Puede que tengas un servidor que está inactivo la mayor parte del tiempo, pero que, regularmente, durante unos breves periodos de tiempo todos los días excepto los sábados y domingos, desde aproximadamente las 0:00 hasta las 7:00 de la mañana, se ejecutan en él algunas jobs de copia de seguridad de gran tamaño. Durante este tiempo, una carga de la CPU de 10 (con 20 cores) es totalmente normal. El resto del tiempo, incluso una carga de 3 podría parecer sospechosamente alta.
En Checkmk tienes varias posibilidades para implementar este ejemplo. Una de ellas es definir primero los intervalos de tiempo con las distintas cargas de trabajo y luego establecer valores umbral específicos para esos momentos. En nuestro ejemplo, esto significa definir primero un nuevo periodo de tiempo para el periodo de alta carga (de lunes a viernes de 0:00 a 7:00). A continuación, puedes especificar una regla para el servicio (CPU load o Processor Queue). Selecciona este nuevo periodo de tiempo y establece valores umbral diferentes (más altos) para él.
Usar un periodo de tiempo tiene la ventaja de que siempre es fácil entender por qué se produjo un estado de WARN / CRIT en un momento determinado. Sin embargo, vincular manualmente los valores umbral a los periodos de tiempo también es algo inflexible y, a veces, simplemente demasiado complicado.
Si utilizas una de las ediciones comerciales, hay otra forma de resolver este problema.
Se llama monitorización predictiva, y consiste en evaluar los datos para obtener una predicción de cómo se comportarán en el futuro.
Una vez configurada, la predicción no permanece estática, sino que se adapta a la realidad cambiante a lo largo del tiempo: la previsión de hoy para pasado mañana no permanecerá inalterada, porque los valores reales de mañana se habrán incluido para pasado mañana. Sin tener que viajar en el tiempo (¡qué agotador!), el proceso también se puede expresar de esta manera: Checkmk aprende continuamente. Dado que los valores umbral para los estados «WARN» y «CRIT» siempre se establecen en relación con los valores de predicción, los valores umbral también aprenden junto con la predicción.
2. Implementación de la monitorización predictiva
2.1. Del nombre del Plugin al parámetro de predicción
Hay toda una serie de Plugins de Checkmk que admiten la monitorización predictiva. A continuación encontrarás algunos ejemplos importantes:
La configuración de la monitorización predictiva se encuentra en el mismo lugar donde se establecen los umbrales para un servicio. Allí encontrarás la opción «Predictive levels (only on CMC)», si la comprobación en cuestión lo admite.
2.2. Creación de una regla para la monitorización predictiva
Para el servicio «CPU load» en el host Linux de nuestro ejemplo, puedes crear una nueva regla con el conjunto de reglas «CPU load (not utilization!)» en «Service monitoring rules», al que puedes acceder más rápidamente buscando en el Menú de configuración.
En la sección «Value» encontrarás parámetros a nivel de servicio para los que puedes seleccionar el valor «Predictive levels (only on CMC)»:
2.3. Selección de valores de referencia históricos
Tras seleccionar «Predictive levels (only on CMC)», se muestran los parámetros, de los cuales presentaremos primero los dos primeros con más detalle:
Con «Base prediction on» define la periodicidad con la que se espera que se repitan los datos de medición (mensual, semanal, diaria u horaria):
Day of the month: Se comparan entre sí los valores medidos de cada día del mes, es decir, el 1.º, 2.º, 3.º, etc. de cada mes.
Day of the week: La comparación se basa en los días de la semana, es decir, se realiza una predicción diferente para cada día de la semana (lunes, martes, miércoles, etc.). Esta suele ser la configuración correcta.
Hour of the day: Se comparan las horas individuales de cada día, es decir, la predicción se repite a diario.
Minute of the hour: La comparación por minutos y la repetición cada hora suelen ser útiles solo para probar una predicción.
En el siguiente parámetro, «Time horizon», introduce hasta cuántos días atrás debe evaluar Checkmk los datos de medición. Checkmk accede a los datos históricos almacenados en archivos RRD. Aunque los datos de medición de los archivos RRD se almacenan durante 4 años, no tiene sentido remontarse demasiado en el tiempo. Por un lado, los valores típicos del pasado reciente pueden diferir de los de un pasado más lejano.
Por otro lado, cuanto más atrás en el tiempo mires, menos datos de medición por unidad de tiempo habrá para comparar. Esto se debe a que, por defecto, Checkmk comprime los datos de medición disponibles de cada minuto en los archivos RRD en tres fases para ahorrar espacio: después de 2, 10 y 90 días. La compresión significa que el mínimo, el máximo y la media se calculan a partir de múltiples datos de medición y que estos datos calculados sustituyen a los datos medidos originalmente. Si los datos de medición de los dos últimos días están disponibles con una resolución completa de 1 minuto, la resolución es de 5 minutos después de 2 días, de 30 minutos después de 10 días y de 6 horas después de 90 días. Si Checkmk accede a datos históricos para la monitorización predictiva, siempre se toma el máximo de los tres valores almacenados.
Para nuestro servidor de ejemplo, con una carga de trabajo elevada de lunes a viernes por la noche, es recomendable seleccionar el periodo de referencia semanal y un intervalo de tiempo de referencia de (como máximo) 90 días. 90 días es un compromiso aceptable, ya que, por un lado, este intervalo contiene suficientes días de comparación, mientras que, por otro lado, los datos de medición siguen estando disponibles con una resolución de 30 minutos —siempre que no se hayan cambiado los valores por defecto.
Selecciona como «Base prediction on» la entrada «Day of the week» e introduce como «Time horizon» «90», tal y como se muestra en la imagen de arriba.
Al establecer el periodo de referencia semanal para un intervalo de 90 días en el pasado, Checkmk dispone de la información necesaria para calcular la curva de referencia. Esto implica evaluar cada lunes del periodo de tiempo (en 90 días hay 12 lunes), comparar el valor medido de cada lunes con los valores medidos de los demás lunes a la misma hora y calcular la media. Después del lunes, Checkmk maneja los demás días de la semana, de martes a domingo, de la misma manera. La curva de referencia así calculada para el pasado se actualiza y se convierte en la curva de referencia proyectada para el futuro.
 |
Los valores utilizados para calcular la media del periodo de referencia pueden ser, a su vez, valores ya calculados (es decir, no medidos), dependiendo de la resolución de los datos históricos en los archivos RRD. |
La curva de referencia calculada por Checkmk a partir de los dos parámetros definidos hasta ahora (periodo de referencia y intervalo de tiempo de referencia) se representa como una línea negra en la siguiente imagen:
A modo de vista previa, esta imagen muestra el gráfico de predicción, que podrás visualizar una vez completada la configuración. Además de la curva de referencia negra, los valores actuales se muestran como una línea azul —si están disponibles en el intervalo de tiempo mostrado.
Lo que falta para completar la configuración son las definiciones de los valores umbral para los estados «WARN» y «CRIT», que están marcados en el gráfico con fondos de color amarillo y rojo. La siguiente sección trata sobre la definición de estos umbrales.
2.4. Definición de umbrales para la predicción
Definirás los valores umbral para WARN y CRIT en función de los valores de predicción que se muestran en la curva de referencia.
Para ilustrar el efecto de los diferentes valores de los parámetros utilizados para definir los umbrales, echemos un vistazo de cerca a un único valor de la curva de referencia. Supondremos que el valor previsto del servicio CPU load es 10 a las 3:30 de la madrugada de los viernes.
Para los umbrales superiores está el parámetro Dynamic levels — upper bound, y para los umbrales inferiores, Dynamic levels — lower bound. Para ambos parámetros tienes tres opciones, que se describen en las tres secciones siguientes.
Diferencia absoluta respecto a la predicción
Con este valor, los umbrales se calculan aumentando o disminuyendo el valor de la predicción en un valor absoluto fijo.
Ejemplo: Warning at 2.0 hará que se muestre una advertencia si el valor es superior a 12 e inferior a 8.
Diferencia relativa respecto a la predicción
Con este valor, los umbrales se calculan aumentando o disminuyendo el valor de la predicción en un porcentaje.
Ejemplo: Warning at 10.0 % hará que se muestre una advertencia si el valor es superior a 11 e inferior a 9.
En relación con la desviación estándar
Con este valor, los umbrales se calculan aumentando o disminuyendo el valor de predicción en un múltiplo de la desviación estándar. La desviación estándar indica cuánto varían los valores en un periodo de referencia (por ejemplo, los viernes a las 3:30 a. m.).
Con esta opción, el cálculo de los valores umbral no es tan fácil de predecir, porque Checkmk calcula la desviación estándar internamente a partir de todos los valores medidos del periodo de referencia. Para ilustrar el efecto, necesitamos más información sobre las 12 mediciones del periodo de referencia los viernes a las 3:30 a. m.: Suponemos que 10 mediciones son iguales a 10, una es 11 y otra es 9. Por lo tanto, las 12 mediciones tienen un valor medio de 10 (que se corresponde con la predicción), una varianza de aproximadamente 0,167 y una desviación estándar de aproximadamente 0,41. (Nos ahorraremos los detalles del cálculo aquí, pero puedes consultar diversas páginas de estadística en internet).
Ejemplo: Warning at 1.0 como múltiplo de la desviación estándar hará que se muestre una advertencia si el valor está por encima de 10,41 y por debajo de 9,59.
Para evitar estados de «WARN» / «CRIT» no deseados, no se aplican umbrales si la desviación estándar no está definida (por ejemplo, porque solo hay un valor medido en el periodo de referencia) o es cero (si todos los valores medidos son idénticos).
En general, se aplica la siguiente regla: cuanto más consistentes sean los valores del pasado, menor será la desviación estándar y más estricta será la predicción. Por lo tanto, esta opción es útil para definir umbrales más estrechos para un periodo de referencia con valores estables y uniformes.
Valores mínimos de los umbrales superiores
Por último, con Limit for upper bound dynamic levels tienes la posibilidad de establecer valores mínimos absolutos para los valores del umbral superior. Esto te permite evitar estados no deseados de «WARN» / «CRIT» en momentos en los que las predicciones son muy bajas.
Ejemplo: Un valor de Warning level de 2.0 hará que solo se muestre una advertencia si el valor es superior a 2, incluso si el umbral superior para una advertencia es 1,5.
Gráfico de predicción con valores umbral
Los efectos descritos a modo de ejemplo para un valor son calculados por Checkmk para todos los valores de la curva de referencia. Puedes ver el resultado en el gráfico de predicción, que se describirá con más detalle en el siguiente capítulo. El gráfico muestra las curvas de los valores umbral superior e inferior por encima y por debajo de la curva de referencia. Las áreas correspondientes a WARN están coloreadas en amarillo y las de CRIT en rojo.
Debes comprobar cuidadosamente los rangos de WARN y CRIT en el gráfico de predicción, especialmente si tienes los umbrales calculados a partir de la desviación estándar, ya que los valores subyacentes a la desviación estándar no se pueden leer directamente en la interfaz de usuario de Checkmk. Al comprobar y, si es necesario, ajustar los niveles, puedes evitar que el servicio entre involuntariamente en los estados WARN o CRIT con demasiada frecuencia.
Con esto queda completada la implementación de la monitorización predictiva. En el siguiente capítulo aprenderás cómo se puede observar la configuración en la monitorización y cómo puedes visualizar el gráfico de predicción.
3. Análisis de los pronósticos
Si has configurado la monitorización predictiva para un servicio, activa los cambios y, una vez que Checkmk haya realizado una comprobación de este servicio, aparecerá el nuevo icono 
en la lista de servicios:
|
Especialmente tras la configuración inicial de un servicio, es posible que este icono no aparezca porque no hay suficientes datos disponibles para la predicción configurada.
En este caso, se muestra un mensaje del tipo « |
Haz clic en «» en la lista de servicios y se mostrará una representación gráfica del intervalo de tiempo de predicción actual —el gráfico de predicción—:
En el gráfico de predicción verás la curva de referencia como una línea negra, los valores actuales como una línea azul, y los rangos para los estados «OK» en blanco, para «WARN» en amarillo y para «CRIT» con un fondo rojo.
El intervalo de tiempo mostrado se basa en el periodo de referencia seleccionado. Por ejemplo, si tienes un periodo semanal, puedes ver los días individuales de la semana y usar la lista desplegable situada encima del gráfico para switch a otro día. Con la entrada especial de la lista «Everyday», el gráfico te mostrará los valores medios de todos los días para los que hay datos disponibles.
En el gráfico de ejemplo, se puede observar la alta utilización de la capacidad por la noche y la baja utilización de la capacidad durante el día. De 0:00 a 04:00 horas, los valores actuales (línea azul) son inferiores a la curva de referencia de predicción (línea negra)—de hecho, tan bajos que los valores umbrales inferiores se estaban rebasando de forma intermitente, lo que provocaba estados de WARN / CRIT. También se aprecia el intervalo entre las 08:30 y las 23:30 horas, en el que la línea azul se mantiene constantemente en el rango inferior CRIT. Este estado podría evitarse en el futuro aumentando los valores de los umbrales inferiores.
Por último, el gráfico muestra que los umbrales superiores se basan en la desviación estándar, ya que entre las 05:00 y las 07:30 los umbrales superiores tienden a aumentar mientras que los valores de la curva de referencia disminuyen. Este comportamiento solo se puede explicar por la desviación estándar, ya que las otras dos opciones (valor absoluto y porcentaje) habrían llevado a un ajuste de los valores de umbral en la dirección de la curva de referencia.
|
Al igual que con la configuración inicial, cualquier cambio en la monitorización predictiva solo surtirá efecto tras una nueva comprobación del servicio.
No es necesario esperar a la siguiente comprobación periódica, sino que puedes iniciarla manualmente desde la lista de servicios con el icono « |
