Valores medidos y gráficos

El diseñador de gráficos se divide en cuatro secciones:

Aquí puedes ver el gráfico exactamente como se verá en directo. También puedes usar todas sus funciones interactivas.

Las curvas incluidas en los gráficos se pueden editar directamente aquí. La edición del título de una curva en este campo se confirma con la tecla «Enter». La opción «Style» define cómo se muestran los valores en los gráficos. Estas son las opciones disponibles:

Las otras tres opciones —Mirrored Line, Mirrored Area y Mirrored Stacked— son similares, salvo que las curvas se dibujan hacia abajo desde la línea del cero. Esto permite un estilo gráfico como el que suele utilizar Checkmk en los gráficos de entrada/salida para lo siguiente:

En la columna «Actions», encontrarás un botón «» para clonar cada métrica que hayas creado. Con esto puedes copiar rápidamente las curvas y simplemente sustituir el nombre del host, por ejemplo.

Con la caja «Metrics» puedes añadir nuevas métricas a los gráficos. En cuanto introduzcas un nombre del host válido en el primer campo, el segundo campo se rellenará con una lista de los servicios del host. Al seleccionar una opción de esta lista, el tercer campo se rellenará con una lista de las métricas de ese servicio. En el cuarto y último campo, selecciona la función de consolidación. Aquí las opciones son «Minimum», « Maximum» y «Average». Estas funciones se utilizan cuando los datos almacenados en los RRD para el intervalo de tiempo especificado ya han sido comprimidos. En un intervalo en el que, por ejemplo, solo hay un valor disponible por cada media hora, puedes elegir trazar el valor mínimo, máximo o promedio original medido para este intervalo de tiempo.

Del mismo modo, puedes usar la función Add new scalar para mostrar los valores de un servicio para WARN, CRIT, máximo y mínimo como líneas horizontales.

También puedes añadir una constante al gráfico. Inicialmente se dibujará como una línea horizontal. A veces se necesitan constantes para generar fórmulas de cálculo. Más adelante hablaremos de esto.

Aquí encontrarás opciones que afectan a los gráficos gráficos completos.

Unit Influye en las etiquetas de los ejes y las leyendas. El valor por defecto «First entry with unit» especifica que se utiliza como unidad la primera entrada del gráfico definido por el usuario con una unidad conocida. Esto significa que la unidad para métricas y escalares siempre se conoce, pero no la de las constantes. Si ninguna entrada tiene una unidad conocida, el gráfico se muestra sin símbolo de unidad. Si, en cambio, seleccionas «Custom», se abrirán más opciones con las que podrás definir la unidad tú mismo. Ten en cuenta que es posible, aunque no recomendable, añadir dos métricas con unidades diferentes a un mismo gráfico.

Con «Explicit vertical range» puedes predefinir el eje vertical de un gráfico. El eje Y normalmente se escala de manera que todos los valores medidos en el intervalo de tiempo elegido quepan exactamente en el gráfico. Si creas un gráfico para valores porcentuales, por ejemplo, puedes elegir que siempre se muestren los valores de 0 a 100. Ten en cuenta, sin embargo, que los usuarios (y tú mismo) pueden, en cualquier caso, escalar un gráfico con el ratón, lo que hace que el posicionamiento sea ineficaz.

El diseñador de gráficos te permite combinar las curvas individuales mediante cálculos. El siguiente ejemplo muestra un gráfico con dos curvas: la carga de la CPU, para User y System.

Supongamos que, para este gráfico, solo te interesa la suma de las dos curvas. Para ello, check las cajas de selección de ambas curvas. Una vez hecho esto, en el panelMetrics , en la filaOperation on selected metrics , aparecerán unos cuantos botones nuevos para todas las operaciones disponibles:

Al hacer clic en «Sum» (Combinar), se unirán ambas curvas en una nueva. El color de esta nueva curva será automáticamente una mezcla de los colores de las dos curvas de entrada. La nueva curva se titulará «Sum of User, System». La fórmula utilizada para el cálculo se mostrará en la columna «Formula» (Fórmula). Además, aparecerá un nuevo símbolo «» (Combinar):

Al hacer clic en «» (Deshacer) se aplica una acción de «deshacer», con la que se pueden volver a mostrar las curvas individuales originales. Más consejos para las operaciones de cálculo:

Si miras los valores medidos en el pasado, a veces no te interesan los detalles exactos de su evolución a lo largo de un periodo de tiempo. Puede que te interese más un resumen aproximado, por ejemplo, la carga de la CPU en los últimos 7 días. El resultado en este ejemplo sería simplemente un número en forma de porcentaje, como el 88 %.

En una tabla de hosts o servicios, puedes añadir columnas que representen el promedio, el mínimo, el máximo u otros resúmenes de una métrica a lo largo de un periodo de tiempo. Esta función también te permite crear informes ordenados por estas columnas, por ejemplo, mostrar la lista de los hosts ESXi que tuvieron la utilización más baja en el periodo seleccionado.

Para mostrar estos valores medidos en una vista de tabla, haz lo siguiente:

Primero necesitas una vista de tabla a la que quieras añadir columnas. Puede ser una vista de hosts o de servicios. Para obtener más información sobre cómo crear o editar vistas de tabla, consulta el artículo sobre vistas de tabla.

Para el siguiente ejemplo, elegimos la vista de tabla «All hosts», que puedes abrir a través de Monitor > Hosts > All hosts. En el menú, selecciona «Display > Customize view». Esto te llevará a la página «Clone view», donde puedes personalizar la vista de tabla a tu gusto.

Para que la vista original All hosts no quede superpuesta por la copia, elige un nuevo ID y también un nuevo título bajo el cual se mostrará posteriormente la vista de tabla en el menú Monitor.

A continuación (opcionalmente), elimina todas las columnas que muestran el número de servicios en los diferentes estados.

Ahora añade una columna del tipo «Services: Metric History». Dado que se trata de una columna de servicios, en el caso de una vista de host necesitas el tipo de columna «Joined column» como primera selección, lo que permite mostrar una columna de servicios en una tabla de hosts. Con una vista de servicio, basta con añadir un nuevo «Column».

En «Metric», selecciona el nombre de la métrica que se va a evaluar históricamente. Si no estás seguro del nombre de la métrica, lo encontrarás en los detalles del servicio, en la entrada «Service Metrics»:

En el ejemplo elegimos la métrica CPU utilization, que casualmente coincide con el nombre del servicio.

Con RRD consolidation, lo mejor es elegir el mismo valor que se utiliza más abajo en Aggregation function, ya que no tendría mucho sentido calcular cosas como «el mínimo del máximo». Puedes averiguar en qué consiste la opción de selección para RRD en el siguiente capítulo sobre la organización de los datos RRD.

El «Time range» es el periodo de tiempo en el pasado que quieres investigar. En el ejemplo, son los últimos siete días, lo que equivale exactamente a 168 horas.

En el ejemplo, elegimos «Util @ 7 days» como «Column title». No te sorprendas si más adelante aparece un campo llamado «Title»: solo lo verás si aquí se utiliza un «Joined column», que siempre permite especificar un título. Simplemente deja el segundo título en blanco.

Por último, en el campo «Of Service», introduce el nombre del servicio al que pertenece la métrica seleccionada anteriormente. Presta atención a la ortografía exacta del servicio, incluyendo mayúsculas y minúsculas.

Después de guardar, aparecerá una nueva vista de tabla con una columna añadida que muestra el porcentaje de carga de la CPU durante los últimos siete días.

Notas

Por defecto, Checkmk está configurado para que la evolución de cada métrica se registre durante un intervalo de tiempo de cuatro años. La resolución base utilizada es de un minuto. Esto tiene sentido, ya que el intervalo de comprobación está preestablecido en un minuto, de modo que se recibirán nuevos datos de medición de cada servicio exactamente una vez por minuto.

Obviamente, almacenar un valor por minuto durante un periodo de cuatro años requerirá una enorme cantidad de espacio en disco (aunque los RRD solo requieren 8 bytes por valor medido). Por esta razón, con el tiempo los datos se comprimen. La primera compresión se realiza a las 48 horas. A partir de ese momento, solo se almacenará un valor cada cinco minutos. Se implementan etapas adicionales tras 10 días y 90 días:

La pregunta obvia ahora es: ¿cuál es la mejor manera de consolidar cinco valores de forma significativa en uno solo? Para ello, tienes a tu disposición las funciones de consolidación: máximo, mínimo y promedio. Lo que resulta significativo en la práctica depende de la aplicación o del punto de vista. Si, por ejemplo, quieres realizar la monitorización de las fluctuaciones de temperatura en un centro de datos durante un periodo de cuatro años, probablemente lo más interesante sea la temperatura máxima registrada. En el caso de las tasas de acceso de una aplicación, podría ser más interesante el promedio.

Para lograr la máxima flexibilidad para cálculos posteriores, los RRD de Checkmk están simplemente preconfigurados para almacenar los tres valores a la vez: mínimo, máximo y promedio. Para cada nivel de compresión y función de consolidación, el RRD incluye un estilo de almacenamiento en «anillo»: el llamado Round Robin Archive (RRA). En la estructura estándar hay 12 RRA. La estructura estándar de Checkmk requiere, por lo tanto, 384 952 bytes por métrica. Esta cifra se obtiene de: 2880 + 2880 + 4320 + 5840 puntos de medición, multiplicado por tres funciones de consolidación, multiplicado por 8 bytes por valor medido, lo que da un total exacto de 382 080 bytes. Si le sumas el encabezado del archivo de 2872 bytes, obtienes el tamaño final de 384 952 bytes mencionado anteriormente.

Una alternativa interesante sería, por ejemplo, almacenar un valor por minuto durante todo un año. Este método tendría una pequeña ventaja: los RRD tendrían en todo momento la resolución óptima y, por lo tanto, podrían prescindir de la consolidación y generar, por ejemplo, solo un valor medio. Si calculas 365 x 24 x 60 valores medidos, multiplicado por 8 bytes, el resultado es un total de casi exactamente 4 MB por métrica. De esta forma, aunque los RRD tienen un requisito de almacenamiento diez veces mayor, ¡la «E/S de disco» se reduce en realidad! La razón es que ya no es necesario almacenar y actualizar en doce RRA separados, sino que solo se necesita uno .

Si el esquema de almacenamiento predefinido no te conviene, puedes modificarlo mediante conjuntos de reglas (e incluso son posibles diferentes versiones por host o servicio). El conjunto de reglas que necesitas lo encontrarás más fácilmente a través de la búsqueda de reglas —es decir, el menú «Setup »— y, una vez allí, solo tienes que escribir «RRD ». Aquí encontrarás el conjunto de reglas « Configuration of RRD databases of services ». También hay un conjunto de reglas similar para hosts, pero los hosts solo tienen valores medidos en casos excepcionales. La imagen siguiente muestra la regla RRD con su configuración predeterminada:

En «Consolidation functions» y «RRA configuration» puedes definir y configurar el número y el tamaño de las fases de compresión listas para ser utilizadas por las consolidaciones. El campo «Step (precision)» define la resolución en segundos y, por regla general, es de 60 segundos (un minuto). Para servicios con un intervalo de comprobación inferior a un minuto, puede ser conveniente establecer este número en un valor menor. Ten en cuenta, sin embargo, que el valor del campo «Number of steps aggregated into one data point» ya no representará minutos, sino el intervalo de tiempo establecido en «Step (precision)».

Cada cambio en la estructura de los RRD afecta inicialmente solo a los RRD recién creados, es decir, a los hosts o servicios recién incorporados a la monitorización. También puedes permitir que Checkmk reestructure los RRD existentes. Esto se realiza mediante el comando cmk-convert-rrds, para el cual siempre está disponible la opción -v (verbosa). Checkmk inspeccionará entonces todos los RRD existentes y los reestructurará según sea necesario al formato de destino definido.

El comando es lo suficientemente inteligente como para reconocer los RRD que ya tienen la estructura deseada:

Si el nuevo formato tiene una resolución mayor o funciones de consolidación adicionales, los datos existentes se interpolarán lo mejor posible para que los RRD contengan los valores más significativos posibles. Sin embargo, es obvio que si, por ejemplo, en lugar de 2 días, ahora necesitas 5 días con valores a intervalos de un minuto, la precisión de los datos existentes no se puede aumentar de forma retroactiva.

La regla descrita anteriormente tiene una configuración adicional: «RRD storage format». Con ella puedes elegir entre dos métodos que Checkmk puede utilizar al crear RRD. El formato «One RRD per host/service» (formato Checkmk, para abreviar) almacena todas las métricas de un host o servicio en un único archivo RRD. Esto permite escribir los datos en una unidad de forma más eficiente, de modo que un conjunto completo de métricas siempre se pueda escribir en una sola operación. Estas métricas se ubican entonces en bloques de almacenamiento contiguos, lo que reduce el número de bloques que deben escribirse en el disco.

Si tus sitios de Checkmk se crearon con una edición comercial en una versión anterior a 1.2.8, quizá te interese comprobar si tus datos de medición se han convertido alguna vez al formato actual, mucho más eficiente. Si los datos siguen almacenados en formato PNP, puedes convertirlos al formato Checkmk aplicando una regla como se muestra en el conjunto de reglas anterior.

Aquí también necesitarás el comando cmk-convert-rrds y, de nuevo, detén siempre tu site antes de convertir los RRD existentes.

Como ves en la advertencia, Checkmk deja inicialmente los archivos existentes sin modificar. Esto te permite, en caso de duda, volver al formato de datos original, ya que no es posible realizar una conversión en sentido inverso. La opción --delete-rrds garantiza que esta copia no se cree o que se elimine posteriormente. Puedes realizar fácilmente la eliminación más tarde de forma manual utilizando de nuevo el comando:

Para reducir (drásticamente) el número de accesos de escritura a una unidad de disco, se puede utilizar un servicio auxiliar: el daemon de caché RRD (rrdcached). Es uno de los servicios del site que se inician automáticamente.

Todos los nuevos valores medidos para los RRD se envían desde el Checkmk Micro Core (ediciones comerciales) o desde el NPCD (Checkmk Community) al rrdcached. Este no escribe los datos directamente en los RRD, sino que los almacena en la memoria principal para escribirlos más tarde como una colección en el RRD correspondiente. De esta forma, el número de accesos de escritura a la unidad de disco (¡o a la SAN!) se reduce notablemente.

Para que no se pierdan datos en caso de reinicio, las actualizaciones se escriben además en archivos de registro. Estos también son accesos de escritura, pero como los datos están organizados secuencialmente, generan poca E/S.

Para que el daemon de caché de RRD pueda funcionar de manera eficiente, necesita mucha memoria principal. La cantidad necesaria depende del número de RRD y del tiempo que deben almacenarse los datos en caché. Esto último se puede definir en el archivo ~/etc/rrdcached.conf. La configuración estándar es almacenar durante 7200 segundos (dos horas) —este valor lo puede personalizar el usuario— más un intervalo aleatorio de 0 a 1800 segundos. Este retraso aleatorio por RRD evita la escritura «en ráfagas» y garantiza que la E/S se distribuya de forma regular a lo largo del tiempo:

Activa los cambios en la configuración de este archivo con:

Aquí tienes una vista general de los archivos y directorios más importantes relacionados con los valores medidos y los RRD (todos los que están en el directorio de inicio del site):