Monitorización de servicios con la versión 7.0 de Pandora FMS
Hoy vamos a hablar de un tipo de monitorización algo diferente de lo habitual. Generalmente, cuando hablamos de monitorización, nuestra cabeza piensa rápidamente en sistemas operativos, redes, comunicaciones, aplicaciones, bases de datos, líneas de comando, etc. Y sí, eso es fundamentalmente en lo que consiste la monitorización, pero hay otras formas no tan conocidas de tener un control de lo que pasa y asegurar que todo va bien en nuestra compañía. En este artículo nos vamos a centrar en una de esas formas de monitorización: la monitorización de servicios.
Definición de monitorización de servicios
En primer lugar vamos a definir qué es, en este contexto, un servicio. Si somos responsables IT de una compañía, nuestros servicios serán esa serie de funciones o trabajos que ofrecemos a nuestros clientes o colaboradores. Por ejemplo una tienda online, un sistema de localización de hoteles, un servicio de reparto de mercancías y paquetes, un CRM, una web de soporte, etc.
En el siguiente esquema podemos ver una compañía cualquiera y tres servicios típicos que puede ofrecer:
Estos tres servicios que son ofrecidos a sus clientes dependen por debajo de ciertos recursos tecnológicos. Cada uno de estos servicios es crítico para la compañía ya que, de fallar alguno, los ingresos y reputación se verían directamente afectados, habría clientes insatisfechos y una serie de consecuencias fatales.
Vamos a centrarnos en la monitorización, tanto a alto nivel como a bajo nivel, de estos servicios, los elementos que los conforman, relaciones de dependencia y recursos tecnológicos que los mantienen.
Análisis
Antes de definir nuestro árbol de servicios a alto nivel debemos partir de una infraestructura de monitorización ya funcionando, por lo que asumimos que ya tenemos una instalación completamente funcional recolectando información de nuestros sistemas. Partiendo de esto debemos ser nosotros, mediante un análisis, quienes definamos cuáles son los componentes críticos. ¿Y cuáles son, de hecho, los componentes críticos? Fácil, aquellos de los que nuestros servicios dependen directamente.
La labor de análisis debe centrarse en determinar cuáles son los servicios críticos de la compañía, y de qué elementos tecnológicos dependen directamente estos servicios. También durante el análisis se deberá identificar la importancia de cada uno de los componentes: ¿supone una detención total del servicio o únicamente implica una degradación del mismo? Se construirá este tipo de estructura controlando cada uno de los componentes que hacen que el servicio se ofrezca correctamente.
Diseño
Vamos a descender al siguiente nivel del servicio, abriendo los elementos que “cuelgan” de, por ejemplo, el servicio de tienda online:
Debemos chequear cuatro elementos, estos son también elementos “lógicos” y nos llevarán directamente al siguiente nivel de la monitorización de servicios; ya estaremos en la monitorización de servicios a bajo nivel, o más desgranada:
En los diagramas anteriores, tanto Content Updated cómo Communications constituyen servicios. Iremos monitorizando cada uno de los elementos inferiores (Systems UP, Router Up, Database UP…) y así definiremos el árbol de servicios, desde la monitorización a bajo nivel determinada por los elementos concretos, hasta los niveles superiores que reflejan el estado general de nuestros servicios, creando estas estructuras con elementos básicos y servicios anidados.
¿Y qué pasa si hay algún problema en uno de los componentes que están siendo monitorizados? ¿Cómo se refleja esto en nuestro árbol de servicios?
Lógica
Durante nuestra fase de análisis, determinamos la estructura del árbol de servicios, identificando cada uno de los componentes claves para que todo funcionase correctamente. Pero, además de identificar los elementos, determinamos la importancia de cada uno de ellos en función del impacto que pudiese ocasionar sobre el servicio un mal funcionamiento.
No es lo mismo que haya una interrupción total de las comunicaciones que bloquee al 100% mi tienda, a que el sistema de envío de correo no funcione y no lleguen las confirmaciones de los pedidos.
Basándonos en el previo análisis y aplicando esta lógica determinaremos el peso de cada elemento en el árbol de nuestro servicio. Esto quedará entendido totalmente mediante los siguientes esquemas.
- Caso 1: uno de los servidores que controlan que el contenido esté actualizado se ha apagado, lo que supone un impacto crítico a nivel de “Content updated”. No obstante, la tienda online sigue levantada, es posible realizar pedidos y en su gran mayoría funcionarán correctamente. Existe una degradación del servicio que no tiene un impacto crítico, y se vería reflejado de este modo en los árboles de servicio:
- Content updated: reflejando estado rojo por la caída de uno de sus componentes críticos. Significa interrupción total.
- Online shop: reflejando estado de aviso por problemas en uno de sus componentes no críticos. Significa degradación del servicio.
- Chip company: reflejando estado de aviso por problemas no críticos en uno de sus componentes. Significa degradación del servicio.
- Caso 2: las comunicaciones han quedado interrumpidas por una caída del router principal, lo que supone un problema crítico a nivel de “Communications”. Esto implica que no es posible acceder a la tienda online, por lo que la severidad del problema hace que a nivel de “Online shop” este inconveniente también suponga un problema crítico dada la interrupción total del servicio. Se reflejaría de este modo:
- Communications: estado crítico ya que se encuentran totalmente interrumpidas por la caída del router principal.
- Online shop: estado crítico por la interrupción total del servicio debido a la caída de las comunicaciones.
- Chip company: reflejando estado crítico debido a la caída total de uno de sus tres servicios principales.
Estructura final
Finalmente iremos construyendo árboles de servicios más grandes y complejos con los que, gracias a la flexibilidad del sistema, podremos siempre controlar el estado de nuestros servicios tanto a alto como a bajo nivel, y poder visualizar rápidamente el estado de nuestros sistemas más importantes.
En la siguiente captura podemos ver un ejemplo real de un árbol de servicios. En este caso controla el sistema de monitorización de la oficina:
La siguiente captura muestra la monitorización de un servicio en cluster:
Los árboles de servicio pueden ser utilizados en dashboards y consolas visuales y son ideales para mostrar en grandes monitores o pantallas en nuestros CPD o salas de operadores de monitorización.
Aplicación a módulos
Además de poder crear bonitas estructuras para visualizarlas en módulos puede venirnos a la cabeza la pregunta… ¿para qué? ¿Cómo aplico este sistema de monitorizacion de servicios para funcione de forma autónoma y proactiva? La respuesta es sencilla, porque todos los elementos que vemos en una estructura de servicios tienen su equivalente en forma de módulo.
Por partes. Cuando creamos un servicio, una de las opciones de configuración consiste en indicar un agente que servirá para almacenar los módulos generados de forma automática, mientras configuramos el servicio.
Por cada servicio aparecerán tres módulos:
- SLA Value Service: valor porcentual del cumplimiento del SLA en el momento actual.
- SLA Service: si el SLA se está cumpliendo o no en este momento.
- Service: suma de los pesos del servicio.
El peso es una forma de ver el estado general de salud del servicio. Generalmente, más peso significará más elementos con estado incorrecto (Warning o Critical); estos pesos son configurables. Pero no vamos a entrar en ese nivel de detalle aquí.
En la siguiente captura podemos ver tres módulos de un servicio “Web Services”, mostrando los valores mencionados. En primer lugar el peso total (0), indicando que todo está bien; en segundo lugar que el SLA se está cumpliendo; y en tercer lugar el porcentaje de SLA. Como puede observarse hay un umbral crítico cuando el valor del SLA desciende hasta 95%, en cuyo caso recibiremos inmediatamente una notificación:
La ventaja de estos módulos es que, como hemos visto, permiten definir umbrales (es posible hacerlo al crear el servicio) y asignar alertas. De modo que cuando estemos en valores de SLA negativos o el estado de salud general de los servicios no sea el adecuado, podemos recibir un SMS instantáneamente o enviar un correo a nuestro departamento de soporte.
Además es posible representar gráficas, especialmente útil para mostrar el valor porcentual del SLA y ver sus evoluciones, si ha habido algún problema durante el cual no se ha cumplido o existe algún factor puntual o temporal que pueda afectar.
Para finalizar, puedes obtener más información en el siguiente vídeo:
El equipo de redacción de Pandora FMS está formado por un conjunto de escritores y profesionales de las TI con una cosa en común: su pasión por la monitorización de sistemas informáticos. Pandora FMS’s editorial team is made up of a group of writers and IT professionals with one thing in common: their passion for computer system monitoring.
