Valores medidos y gráficos

El diseñador de gráficos está dividido en cuatro secciones:

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

Aquí se pueden editar directamente las curvas incluidas en los gráficos. La modificación del título de una curva en este campo se confirma con la tecla "Intro". En Stylese define cómo se muestran los valores en los gráficos. Estas son las opciones posibles:

Las otras tres opciones -Mirrored Line, Mirrored Area yMirrored Stacked son similares, con la excepción de que las curvas se dibujan hacia abajo desde la línea cero. Esto permite un estilo de 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 él podrás copiar rápidamente las curvas y sustituir simplemente 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 se rellenará con una lista de los servicios del host. Al hacer una selección en esta lista, el tercer campo se llenará con una lista de las métricas de este 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, sólo se dispone de un valor por cada media hora, puedes elegir trazar el valor medido original mínimo, máximo o medio para este intervalo de tiempo.

Del mismo modo, puedes utilizar 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. Ésta se dibujará inicialmente como una línea horizontal. A veces se necesitan constantes para generar fórmulas de cálculo. Más adelante hablaremos de ello.

Aquí puedes encontrar opciones que afectan a los gráficos completos. Unit influye en las etiquetas de los ejes y las leyendas. Se establecerá automáticamente cuando se añada la primera métrica. Ten en cuenta que es posible, aunque no aconsejable, añadir dos métricas con unidades distintas a un mismo gráfico.

Con Explicit vertical range puedes predefinir el eje vertical de un gráfico. Normalmente, el eje Y se escala para 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 mostrar siempre 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 utilizando el ratón, haciendo 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: Carga de la CPU, para User y System.

Supongamos que para este gráfico sólo te interesa la suma de las dos curvas. Para ello, marca las cajas de selección de ambas curvas. Una vez hecho esto, en el panel Metrics de la fila Operation on selected metricshabrán aparecido unos nuevos botones para todas las operaciones elegibles:

Haciendo clic en Sum combinarás ambas curvas en una nueva curva. 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 aparecerá en la columna Formula. Además aparecerá un nuevo símbolo:

Hacer clic sobre él funciona como un "deshacer", con el que se pueden volver a visualizar las curvas individuales originales. Más consejos para las operaciones de cálculo:

Si observas 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, sino que puede ser más interesante un resumen aproximado, por ejemplo, la media de utilización 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 la media, 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 que ordenen 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, haz lo siguiente:

Primero necesitas una vista a la que quieras añadir columnas. Puede ser una vista de host o de servicios. Para más detalles sobre la creación o edición de vistas, consulta el artículo sobre vistas.

Para el siguiente ejemplo, elegimos la vista 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 a tu gusto.

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

Después (opcionalmente) elimina todas las columnas que muestran el número de servicios en los diferentes estados.

Añade ahora una columna del tipo Services: Metric History. Como se trata de una columna de servicios, en el caso de una vista de host necesitas como primera selección el tipo de columna Joined column, que permite mostrar una columna de servicios en una tabla de host. En el caso de una vista de servicios, basta con añadir una nueva columna 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, puedes encontrarlo en los detalles del servicio en la entrada Service Metrics:

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

Con RRD consolidation es mejor elegir el mismo valor que el utilizado a continuación 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 de RRD en el siguiente capítulo sobre la organización de los datos de RRD.

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

En el ejemplo, elegimos Util @ 7 days como Column title. No te sorprendas de que luego aparezca un campo con el nombre Title -sólo lo verás si aquí se utiliza Joined column, que siempre permite especificar un título-. 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, obtendrás una nueva vista con una columna añadida que muestra el porcentaje de carga de la CPU en los últimos siete días.

Notas

Por defecto, Checkmk está configurado para que el curso de cada métrica se registre a lo largo de un intervalo de tiempo de cuatro años. La resolución base utilizada es de un minuto, lo cual tiene sentido, ya que el intervalo de check está preestablecido en un minuto, de modo que precisamente una vez por minuto se recibirán nuevos datos de medición de cada servicio.

Obviamente, almacenar un valor por minuto durante un periodo de cuatro años requerirá una enorme cantidad de espacio en disco (aunque los RRD sólo necesitan 8 bytes por valor medido). Por esta razón, con el tiempo los datos se comprimen. La primera compresión se produce a las 48 horas. A partir de ese momento sólo se almacenará un valor cada cinco minutos. Las fases siguientes se aplican a los 10 días y a los 90 días:

La pregunta obvia ahora es: ¿cuál es la mejor forma de consolidar cinco valores de forma significativa en uno solo? Para ello están disponibles las funciones de consolidación:máximo,mínimo y media. Lo que es significativo en la práctica depende de la aplicación o del punto de vista. Si, por ejemplo, quieres monitorizar las fluctuaciones de temperatura de un centro de datos durante un periodo de cuatro años, probablemente lo que más te interese sea la temperatura máxima registrada. Para las tasas de acceso de una aplicación, podría interesar más una media.

Para conseguir 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 media. Para cada nivel de compresión y función de consolidación, el RRD incluye un estilo de almacenamiento en "anillo", el llamado Archivo Round Robin (RRA). En la estructura estándar hay 12 RRA. Por tanto, la estructura estándar para Checkmk requiere 384.952 bytes por métrica. Este número 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 de exactamente 382.080 bytes. Si se añade la cabecera del archivo de 2872 bytes, se obtiene el tamaño final de 384.952 bytes citado anteriormente.

Un esquema alternativo 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, con lo que se podría prescindir de la consolidación y, por ejemplo, generar sólo el valor medio. Calculando 365 x 24 x 60 valores medidos, multiplicados por 8 bytes, el resultado es un total de casi exactamente 4 MB por métrica. De este modo, aunque los RRD tengan una necesidad de almacenamiento diez veces mayor, ¡en realidad se reduce la "E/S de disco"! La razón es que ya no es necesario almacenar y actualizar en doce RRD distintos, en su lugar sólo se necesita uno.

Si el esquema de almacenamiento predefinido no te conviene, puede modificarse medianteconjuntos de reglas (e incluso son posibles versiones diferentes por host o servicio). El conjunto de reglas requerido se puede encontrar más fácilmente a través de la búsqueda de reglas -por tanto, el menú Setup - y una vez allí simplemente introduce RRD. Aquí encontrarás el conjunto de reglasConfiguration of RRD databases of services. También existe un conjunto de reglas similar para los host, pero los host sólo 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 establecer 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 check inferior a un minuto puede ser sensato fijar este número por debajo. 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 RRDs sólo tiene efecto inicialmente en los RRDsrecién creados, es decir, en los host 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 que siempre está disponible la opción -v (verbose). Checkmk inspeccionará entonces todos los RRD existentes y los reestructurará según sea necesario en el formato de destino definido.

Importante: Para garantizar la integridad de los datos contenidos en los RRD, detén siempre tu site (con omd stop) antes de convertir los RRD existentes con cmk --convert-rrds.

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 naturalmente obvio que si, por ejemplo, en lugar de 2 días, ahora necesitas 5 días con valores a intervalos de un minuto, no se podrá aumentar retroactivamente la precisión de los datos existentes.

La regla descrita anteriormente tiene un ajuste adicional: RRD storage format. Con él puedes elegir entre dos métodos que Checkmk puede utilizar al crear RRDs. 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 una escritura más eficaz de los datos en una unidad, de modo que siempre se puede escribir un conjunto completo de métricas en una sola operación. Estas métricas se ubican entonces en bloques de almacenamiento vecinos, reduciendo así el número de bloques que deben escribirse en el disco.

Si tus sites Checkmk se crearon con una edición comercial en una versión anterior a 1.2.8, quizá quieras comprobar si tus datos de medición se convirtieron 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 la que 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.

Puedes ver por la advertencia que Checkmk al principio deja inalterados los archivos existentes. Esto te permite, en caso de duda, volver a este formato de datos original, ya que no es posible una conversión en sentido inverso. La opción--delete-rrds garantiza que no se cree esta copia, o que se elimine posteriormente. Puedes realizar el borrado manualmente más tarde, 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 que se inician al arrancar un site:

Todos los nuevos valores medidos para los RRD se envían desde el Checkmk Micro Core (ediciones comerciales) o desde el NPCD (Checkmk Raw) al rrdcached. Éste no escribe los datos directamente en los RRD, sino que los retiene en la memoria principal para escribirlos posteriormente como una colección en el RRD correspondiente. De este modo se reduce notablemente el número de accesos de escritura a la unidad de disco (¡o a la SAN!).

Para que no se pierdan datos en caso de reinicio, las actualizaciones se escriben además en archivos de registro del diario. Estos también son accesos de escritura, pero como los datos se ordenan secuencialmente, generan poca IO.

Para que el daemon de caché RRD pueda trabajar con eficacia, necesita mucha memoria principal. La cantidad necesaria depende del número de RRD y del tiempo que deban almacenarse en caché los datos. Esto último puede definirse en el archivo~/etc/rrdcached.conf. La configuración estándar es almacenar durante 7200 segundos (dos horas) -el usuario puede personalizar este valor- más un intervalo aleatorio de 0-1800 segundos. Este retraso aleatorio por RRD evita la escritura "pulsada" y garantiza que la IO se distribuya regularmente en el tiempo:

Activa una alteración de la configuración de este archivo con:

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