Disponibilidad ampliada (SLA)

En Checkmk puedes evaluar la disponibilidad y, para ello, configurar también una evaluación básica de SLA. Ahora bien, la disponibilidad absoluta durante un periodo determinado no es especialmente significativa. Por poner un ejemplo extremo: una disponibilidad del 99,9 % permitiría menos de 10 horas de tiempo de mantenimiento al año —en realidad, solo 8 horas, 45 minutos y 36 segundos, para ser precisos. Si repartes esas 8,76 horas a lo largo de un año, el promedio es de poco más de 43 minutos al mes, lo que puede ser aceptable para muchos sistemas. Sin embargo, una interrupción de una hora seguida causaría muchos daños. Es obvio que una interrupción así debería reflejarse en la evaluación de la disponibilidad.

Si utilizas una de las ediciones comerciales, Checkmk cuenta con una función específica para los service level agreements (SLA). La función SLA se basa en los datos de disponibilidad y permite ahora una evaluación mucho más detallada.

Se pueden implementar dos tipos básicos de evaluación:

Puedes combinar uno o ambos tipos para varios sites; por ejemplo, para garantizar que, durante el periodo del informe, un servicio concreto esté al menos un 90 % en estado «OK», y que se permita un máximo de dos eventos de dos o más minutos para marcar la condición «CRIT».

Los resultados de estos cálculos se pueden mostrar posteriormente en dos formatos en las vistas de tabla:

Por ejemplo, aquí puedes ver la evaluación de un sistema de archivos en la Vista general: desde hoy (con 3 iconos en la columna de la derecha) y para los últimos 15 días, y también ver inmediatamente que hubo problemas evidentes hasta hace 4 días:

Pero, ¿qué te revelan estas evaluaciones ahora? Por un lado, puedes ver el cumplimiento o incumplimiento de los SLA completados y, por ejemplo, informar a tus clientes de estas evaluaciones. Por otro lado, ya puedes identificar de antemano un fallo inminente: Por defecto, el indicador de SLA se iluminará en CRIT cuando se haya superado su valor. Pero también se puede ajustar para que cambie a CRIT si, por ejemplo, el estado de CRIT permitido para el servicio ha alcanzado el 80 por ciento —y antes de ese punto podría cambiar a una bandera de WARN.

En definitiva, los SLA son en su mayoría vistas de tabla muy detalladas, generadas a partir del análisis de los datos de disponibilidad. Las verás más adelante en dos momentos: en tablas, opcionalmente para todos los hosts y servicios que aparecen en la lista, o solo para los servicios que están específicamente vinculados a SLA individuales. En segundo lugar, hay una página de detalles completa para cada combinación de servicio y SLA.

La base de la función SLA son los datos de disponibilidad. Los cálculos sobre las especificaciones del SLA, por supuesto, no se aplican a todo el inventario de datos sin procesar; al fin y al cabo, los informes de SLA deben abarcar periodos de tiempo específicos. Así que primero se determina para qué periodo deben cumplirse los requisitos del SLA: el llamado «periodo de SLA». Por ejemplo: «Durante cada periodo de monitorización mensual, el estado del servicio MyService debe ser de al menos un 90 % OK». Para este periodo SLA no se utilizarán necesariamente (ni inevitablemente) todos los datos del mes correspondientes a un funcionamiento 24/7. Los datos se pueden convertir a los periodos de tiempo definidos en la configuración, es decir, limitarse aproximadamente al horario laboral.

Esto da lugar a un requisito más concreto, como: «El servicio MyService durante un mes (el periodo del SLA), en horario laboral (el periodo de tiempo) —de lunes a viernes de 10:00 a 20:00— debe estar disponible al 90 % (requisito del SLA)». El SLA y los periodos de tiempo se complementan entre sí, aunque, por supuesto, este último no tiene por qué estar restringido: Puedes utilizar todos los datos de monitorización generados durante el periodo del SLA.

En resumen: necesitas dos periodos para restringir la base de datos para el cálculo de un requisito del SLA:

Se genera un resultado independiente para cada periodo SLA. El número de estos resultados individuales que se muestran en una tabla se puede configurar mediante vistas de tabla. Así, por ejemplo, las últimas cinco semanas, limitadas a días laborables, se muestran como cinco periodos SLA individuales directamente en los hosts y servicios.

Como es habitual en Checkmk, entre la fuente de datos (definición del SLA) y la salida (vista de tabla) sigue habiendo una regla que asignar para los servicios específicos del SLA, pero esto no es obligatorio. Y así, para los SLA, esto suele traducirse en un proceso de tres pasos, cuando se aplican a servicios específicos:

A continuación te explicamos cómo configurar un SLA sencillo que incluya una vista de tabla: Los sistemas de archivos de los hosts MyHost1 y MyHost2 deben estar en condición «OK» durante al menos el 90 % del tiempo en un periodo de informe de una semana (en este ejemplo se ha alcanzado un máximo del 80 %). Además, se permite que adopten la condición «WARN» durante dos o más minutos en un máximo de cinco ocasiones.

Primero, crea el SLA propiamente dicho. Puedes encontrar la configuración en Customize > Business reporting > Service Level Agreements (por cierto, solo puedes ver este elemento de menú en el Modo mostrar más):

Crea un nuevo SLA a través de New SLA. En la sección «General Properties», primero asigna un ID único, aquí MySLA, y un título, como Filesystems:

En «SLA settings», establece el «SLA period» en el periodo deseado, como «Weekly». Por lo tanto, los siguientes requisitos siempre serán válidos para este periodo de una semana.

Pero, antes de configurar los requisitos reales, también puedes añadir restricciones adicionales en «Filtering and computation options» (Configuración > SLA > Configuración general), y establecer opciones que, sin embargo, no son necesarias para nuestro sencillo ejemplo de SLA:

A continuación, especifica los requisitos reales en la sección «SLA requirements» con «Add new timeperiod». Siempre que hayas especificado periodos de tiempo, estos también se pueden usar con los SLA, como ya se ha mencionado para la disponibilidad general. Selecciona un periodo de tiempo en «Active in timeperiod», o como aquí en el ejemplo «24X7 - Always» para definir los requisitos para un funcionamiento 24/7. En «Title», pon un nombre significativo, por ejemplo, «90 percent OK»:

Para Computation Type, en la primera solicitud selecciona Service state percentage y añade un nuevo criterio a través de Add state configuration. Se abre un nuevo párrafo para Monitoring state requirement. Para solicitar al menos un 90 % de disponibilidad, configura este registro en OK, minimum, 90. Si este valor no se alcanza, el SLA se considera incumplido y pasa al estado CRIT, como se verá más adelante en la página de resultados.

Quizás el SLA no debería esperar a que se incumpla para pasar a CRIT, sino directamente a WARN tan pronto como se consuma el 50 % del margen, y luego a CRIT si queda un 10 % de margen. Lo que realmente incumple el SLA produciría entonces broken, pero sin más cambios de estado (más información sobre esto más adelante en la sección «Página de detalles del SLA»). Para una configuración así, check la caja en Levels for SLA monitoring. Aquí puedes introducir los valores residuales para la transición a WARN y CRIT. Con esto se completa la primera solicitud.

Ahora añade una segunda solicitud con Add new timeperiod. Vuelve a establecer el periodo de tiempo: en Title, por ejemplo, especifica Max 5 warnings of 2 minutes como nombre y, en este caso, establece Computation Type en Maximum number of service outages: La solicitud real es entonces: Maximum 5 times WARN with duration 0 days 0 hours 2 mins 0 secs:

Según el SLA, por cada periodo del SLA, el servicio puede estar en el estado especificado un máximo de cinco veces, y cada vez durante un máximo de dos minutos, sin que el SLA se marque como incumplido. En lugar de «WARN», por supuesto, también se podría especificar otro estado en este punto. Y de nuevo, a través de «Levels for SLA monitoring», también puedes ajustar y determinar cuántos incidentes restantes activarán una advertencia, antes de que el SLA se incumpla realmente con un «WARN» o un «CRIT».

Como se ha mencionado anteriormente, puedes añadir más de estos requisitos y entrelazar SLA detallados. Pero todavía no hay servicios que «reaccionen» a este SLA; en nuestro ejemplo, una regla debe establecer esta conexión. A continuación, en la sección de visualizaciones de SLA específicas de cada columna, se describe cómo utilizar la configuración creada hasta este momento sin dicha conexión de servicio SLA.

El SLA tiene una conexión con un servicio a través del conjunto de reglas «Setup > Services > Service monitoring rules > Assign SLA definition to service». Crea una regla, activa la única opción específica de la regla «Assign SLA to service» y, a continuación, elige tu definición de SLA «MySLA», que aparece en la lista con el título «Filesystems».

A continuación, en «Conditions» (Seleccionar servicios), dentro de la sección «Services» (Seleccionar servicios), define filtros adicionales para los servicios deseados. Como siempre, aquí puedes trabajar con expresiones regulares y, como en este ejemplo, vincular la definición del SLA a todos los sistemas de archivos locales a través de Filesystem. Si lo deseas, puedes restringirlo todo utilizando los filtros específicos de la regla para carpetas, tags del host y hosts explícitos; en nuestro ejemplo, son los hosts MyHost1 y MyHost2:

Por supuesto, en este punto también podrías omitir cualquier filtrado de servicios y simplemente vincular el SLA a todos los servicios. A continuación se explica cómo y por qué es mejor hacerlo con una vista de tabla de SLA específica de columna.

Así que ya has creado la definición de SLA MySLA y la has vinculado a todos los servicios de los dos hosts que empiezan por Filesystem. Ahora crea una nueva vista de tabla para los SLA. Para el ejemplo de SLA, debería bastar con una vista de tabla sencilla de los dos hosts con sus servicios de sistema de archivos y sus SLA. Para mayor claridad, se añaden los servicios de Checkmk a los que actualmente no hay ningún SLA vinculado. El resultado se parecerá a la imagen que aparece al final de este capítulo.

Crea una nueva vista de tabla con Customize > Visualization > Views > Add view. En la primera consulta, especifica All services como Datasource. Confirma en la siguiente consulta si se debe mostrar la información de un único objeto con el valor por defecto No restrictions to specific objects.

En «General Properties», introduce un ID (aquí MySLAView_Demo), un título (como My SLA Demo View) y, por último, selecciona un tema como Workplace si quieres ver las vistas de SLA más tarde en un item independiente del menú «Monitor». El resto de valores pueden dejarse sin cambiar para esta prueba.

Ahora ve a la caja «Columns» y, inicialmente a través de «Add column», añade las tres columnas generales «Services: Service state», «Hosts: Hostname» y «Services: Service description» como base para la vista de tabla.

El selector de columnas también contiene dos columnas específicas de SLA: Hosts/Services: SLA - Service specific y Hosts/Services: SLA - Column specific. Esta última muestra una definición de SLA fija para cada servicio de la vista de tabla —la mejor alternativa a un SLA para todos los servicios, como se ha mencionado anteriormente. Más adelante hablaremos de esto.

Añade la columna «Hosts/Services: SLA - Service specific» en este momento. Aquí tienes ahora todo tipo de opciones para presentar los resultados de los SLA:

SLA timerange: Utiliza esto para establecer el periodo de tiempo para el que deseas ver los resultados del SLA. Por ejemplo, si tienes el periodo de informe Monthly en tu definición de SLA y aquí Last Year, obtendrás doce resultados individuales. En este ejemplo, se utiliza la opción SLA period range para especificar directamente el número de periodos de informe mostrados: Para cinco periodos/resultados, configura Starting from period number en 0 y Looking back en 4.

Layout options (Elementos de SLA): Por defecto, esta opción está configurada en Only Display SLA Name. Para ver realmente los resultados de los SLA, selecciona aquí Display SLA statistics. Puedes seleccionar hasta tres elementos diferentes:

Activa las tres opciones para este ejemplo.

Generic plugin display options: En este punto, para la visualización de los SLA de interrupción/porcentaje, define si deben aparecer los resúmenes (textos) o, respectivamente, los resultados individuales (iconos) para los periodos de informes. Para ver ambos en acción, deja la opción de SLA por porcentaje en Show separate result for each SLA period y selecciona Service outage count display options a Show aggregated info over all SLA periods.

Si quieres agrupar la vista de tabla por hosts individuales, en «Grouping» añade la columna «Hosts: Hostname», lo que garantiza una separación visual de los hosts.

Dado que la vista de tabla solo debe mostrar los hosts MyHost1 y MyHost2, en el último paso tienes que establecer un filtro en Context / Search Filters para Hostname: MyHost1|MyHost2. Para una vista de tabla de ejemplo un poco más clara, puedes establecer un filtro en Service, por ejemplo, filesystem.*|Check_MK.*. Así obtendrás los servicios del sistema de archivos supervisados por SLA y, como contrapartida no supervisada, los servicios de Checkmk; de esta forma, los resultados al usar la visualización de SLA específica del servicio serán simplemente más claros.

Con esto queda completada la configuración de la vista de tabla. Tras la selección en el menú «Monitor», obtendrás como resultado una vista de tabla con cinco iconos de estado como resultados individuales del SLA porcentual, y un resumen en forma de porcentaje para el SLA de interrupciones —por supuesto, solo en las líneas de servicios del sistema de archivos; las líneas de Checkmk permanecen vacías.

La vista de tabla específica del servicio tiene una desventaja: aunque puedes crear varias reglas que asignen el mismo servicio a diferentes SLA, solo puedes mostrar el SLA asignado a la primera de esas reglas; no hay forma de que el SLA de una segunda regla de control se muestre en una segunda columna.

Sin embargo, puedes mostrar fácilmente varias columnas con diferentes SLA fijos y especificados. Estas vistas de tabla específicas por columna son útiles, por ejemplo, si necesitas varios SLA que se apliquen a todos los servicios de algunos o todos los hosts. Así que podría tratarse de definir algo como SLA de oro, plata y bronce, cada uno en una columna separada junto a los servicios de un host. De este modo, de un vistazo quedará claro qué definiciones de SLA cumple un servicio o host. En resumen: la vista de tabla específica te permite mostrar más de un único SLA para los servicios.

En el ejemplo anterior, se ejecutaron los tres pasos mencionados al principio: crear un SLA, vincularlo a un servicio e instalarlo en una vista de tabla. Para las vistas de tabla específicas de columna, puedes omitir el segundo paso. Crea solo el SLA y configura una vista de tabla con la columna «Hosts/Services: SLA - Column specific». Los resultados del SLA se mostrarán entonces en cada línea, independientemente del servicio correspondiente.

La siguiente imagen muestra la vista de tabla de SLA anterior para «MyHost1» con una columna adicional que muestra los resultados del SLA (un máximo de tres interrupciones de los servicios de Checkmk) para cada servicio:

Así, la diferencia entre las visualizaciones específicas del servicio y las de la columna queda claramente visible. Lo que también debería quedar claro: el SLA diseñado específicamente para los servicios de Checkmk, por supuesto, solo tiene un sentido moderado en las columnas del sistema de archivos. ¡Por lo tanto, vale la pena planificarlo a fondo antes de comenzar una implementación!

Una pequeña nota más: en las opciones de las vistas específicas del servicio, arriba en «Generic plugin display options» hemos visto los ajustes para los SLA de interrupción y porcentaje. En las opciones de las vistas específicas de columna también puedes ver estos dos, pero solo si el SLA incluye realmente criterios de interrupción y porcentaje. Aquí no es apropiado lo genérico, sino lo estático: se invoca una definición fija de SLA. Solo se verán las opciones que pertenecen a este SLA.

Hay muchas formas de combinar SLA, servicios y vistas de tabla; aquí se requiere una buena planificación de lo que quieres mostrar exactamente a través de los SLA.

Integrar la información del SLA en tablas ofrece una vista general rápida, pero, por supuesto, también puedes examinar los resultados en detalle. En una vista de tabla, al hacer clic en la celda con los datos del SLA, se accede directamente a la página de detalles de los resultados del SLA para el servicio afectado:

Aquí se pueden encontrar cuatro tipos diferentes de información:

General information: Aquí puedes ver los datos brutos de disponibilidad y, por lo tanto, los cálculos del SLA como una vista general del estado para cada periodo, y debajo los resultados agregados de los requisitos del SLA.

A continuación, aparecen tablas para cada requisito individual del SLA. La pestaña «Timeline» muestra todos y cada uno de los estados, y la fila «Result» muestra los resultados para cada periodo de informe individual. Una característica especial aquí: Si, tal y como se describe en el ejemplo, has establecido niveles de SLA y el SLA pasa a «CRIT» antes de incumplirse, esto se indicará aquí con una barra naranja y no con la barra roja habitual. Las barras se volverán rojas cuando el SLA se incumpla. Una vez que lo veas, pasa el puntero del ratón por la barra de resultados, donde, a través de un tooltip, podrás ver los eventos individuales responsables de ese estado. En la siguiente imagen, el estado es «WARN» (Cumplido), ya que solo quedan dos de las tres interrupciones permitidas:

El mensaje «SLA broken» también aparecería en este tooltip.

Una pequeña nota sobre el uso de la vista de tabla: Si pasas el ratón por encima de la barra de resultados «Aggregated results» o «Result» de un periodo, este periodo se resaltará, tanto para todos los requisitos individuales como para el resumen en «General information». Con un clic puedes seleccionar o deseleccionar uno o más periodos.

Por último, en SLA specification, encontrarás los datos de configuración de tu SLA, que te ayudarán a evaluar y comprender mejor los resultados presentados:

En el artículo sobre disponibilidad ya has leído sobre cómo usar la disponibilidad para las Agregaciones BI. Los SLA también están disponibles para las Agregaciones BI, aunque hay que dar un pequeño rodeo: El estado de una Agregación BI se puede supervisar a través del agente especial de BI como un servicio normal. Esto aparece entonces, por ejemplo, como Aggr Disk & Filesystems en las vistas de tabla y, a su vez, se puede asociar a un SLA mediante la regla Assign SLA definition to service ya utilizada anteriormente. Como resultado, tendrá un aspecto similar a este:

La regla del agente especial se encuentra en Setup > Agents > Other integrations > BI Aggregations, y el conjunto de reglas está en el artículo de BI.

El agente especial requiere el sitio correspondiente y, si es necesario, sus datos de inicio de sesión si se trata de un sitio remoto. La configuración principal se realiza en Filter aggregations. Aquí es donde se especifican todas las agregaciones que deseas incluir como servicios independientes en la monitorización. En By aggregation name (exact match), introduce el título de la regla de nivel superior de una agregación, por ejemplo, Disk & Filesystems (que luego se complementa con Aggr como un nuevo servicio Aggr Disk & Filesystems).

Los nombres exactos de las reglas/agregaciones deseadas se pueden encontrar, por ejemplo, en Setup > Business Intelligence > Business Intelligence > Default Pack - Aggregations:

Nota: Aquí hay riesgo de confusión: En la configuración de BI, creas la Agregación BI, es decir, la lógica, mediante reglas, y estas reglas se introducen aquí a través de sus títulos como Aggregation Name.

En la práctica, los SLA son una combinación de muchas configuraciones diferentes: el propio SLA, las opciones de vista de tabla y servicio, los periodos de tiempo, las reglas y, por supuesto, los datos de disponibilidad. Si el SLA muestra resultados diferentes a los esperados, revisa toda la cadena. En caso de duda, también ayuda visualizar todo el proceso con lápiz y papel, para ver de un vistazo toda la información implicada. Los siguientes puntos pueden servir como lista de verificación básica:

Una vez que hayas comprobado las configuraciones, puedes verificar el funcionamiento del SLA utilizando cambios de estado manuales (ficticios) y tiempos de mantenimiento programados, aplicando comandos a los objetos de una vista de tabla.

En tal caso, abre la configuración de la vista afectada y check primero lo más obvio: ¿Hay siquiera una columna con un SLA? Sin embargo, los filtros contradictorios son una causa más probable: Si has vinculado el SLA a un servicio mediante una regla, este servicio, por supuesto, no puede estar excluido de las opciones de vista en Context / Search Filters.

Los SLA vinculados a servicios tienen aún otra fuente de error: Como se ha descrito anteriormente, solo puedes mostrar un SLA vinculado a una regla por cada servicio en una vista de tabla: el de la primera regla con coincidencia. Por último, la vista de tabla solo recibe la instrucción de mostrar en cada línea el SLA asociado al servicio, no el segundo ni el quinto SLA vinculado. Si has creado reglas correspondientes, simplemente se ignorarán. En tales casos, puedes switch a la visualización específica por columnas.

En su forma más simple, el estado de un SLA solo cambia en las vistas de la GUI cuando se incumplen sus requisitos. Para que se te informe de un cambio de estado con antelación, debes configurar los niveles del SLA.