Ir al contenido

Sistema de monitorización

De Wikipedia, la enciclopedia libre

En un sistema informático, el sistema de monitorización o subsistema de monitorización es el subsistema encargado de hacer un seguimiento del estado del sistema completo, tanto de la infraestructura como del resto de subsistemas, con el fin de asegurar la fiabilidad y estabilidad de los servicios que provee el conjunto. Es decir, permite evaluar la salud y el rendimiento del sistema completo.[1]

Este tipo de sistemas se basan en la recogida de métricas, procesamiento y visualización de los datos junto con la generación de alertas cuando sucede algo que puede ser un síntoma de un riesgo o mal funcionamiento.[2]

Métrica

[editar]

La base del sistema de monitorización es la recopilación de valores que al analizarlos permiten entender el comportamiento, las tendencias, los riesgos y poder prever el impacto que tendrán posibles futuros cambios. Se llama métrica a aquellas características del sistema que al ser medidas se obtiene una secuencia de valores registrados con su sello de tiempo. Por ejemplo para un servidor web, el conjunto total de peticiones recibidas es una métrica.[3][1]

Es frecuente asociar distintas etiquetas a las métricas para permitir definir un modelo de datos con distintas dimensiones. Por ejemplo, para un servidor web, para la métrica para la métrica del conjunto total de peticiones recibidas podemos definir etiquetas para identificar que método HTTP se usa y, por otro lado, definir etiquetas para identificar el directorio o subdirectorio sobre el que se realiza la petición. Con estos datos, por ejemplo, podríamos obtener datos sobre las peticiones HTTP que usan el método POST para el path /api/tracks.[3]

En un mundo ideal deberíamos controlar con una métrica todo aquello que pudiera en un momento ser relevante. Sin embargo puede que esto no sea posible o incluso deseable por algunos/s de los siguientes motivos:[1]

  • Recursos disponibles para realizar el seguimiento (personas, infraestrucutura, presupuesto)
  • La complejidad y propósito de la aplicación. Hay que tener especial seguimiento de las partes críticas.
  • Entorno de despliegue. Es mucho más interesante tener una monitorización más robusta en los entornos de producción que en los de desarrollo o testing. Por esta razón suele haber diferencias en la severidad, granularidad y cantidad de métricas medidas
  • La probabilidad de que la merica sea útil. Cada métrica adicional incrementa la complejidad y gasta recursos.
  • La importancia de la estabilidad del sistema

Tipos de información usada en las métricas

[editar]

Para cada sistema las métricas sobre las que se recogen los valores son distintas. Podemos distinguir entre distintos niveles cuando planificamos la estrategia de monitorización:[1]

  • Métricas basadas en las máquinas. En lo más bajo de la jerarquía de métricas están los indicadores de las máquinas. Aquí se incluyen cualquier métrica involucrada en evaluar el estado o rendimiento de la máquina individual ignorando por el momento su pila de aplicación y servicios. Ejemplo Uso de CPU, Memoria, Espacio de disco, uso de memoria de intercambio
  • Métricas de aplicación:[4]​ son métricas que determinan si una aplicación está funcionando correctamente y con eficiencia. Las métricas a este nivel son indicadores de la salud, rendimiento o carga de una aplicación. Muchas aplicaciones como servidores web, bases de datos proveen sus propias métricas que pueden ser pasadas a nuestro sistema de monitorización. Para aplicaciones propias se tendrá que añadir código o interfaces para exponer las métricas que se quieren controlar. Ejemplos de métricas: Tasas de error y éxito, fallos de servicio y reinicios, rendimiento y latencia de las respuestas, uso de recursos.
  • Métricas de conectividad y red. Métricas relacionadas con indicadores de red y conectividad. Son muy importantes para evaluar la conectividad desde el exterior y para asegurar que los servicios son accesibles a otras máquinas del sistema. Ejemplos de métricas: conectividad, tasa de error y paquetes perdidos, latencia, utilización del ancho de banda.
  • Métricas de pool de servidores. Las métricas sobre servidores individuales son importantes. Sin embargo en sistemas grandes es mejor evaluar la habilidad de una colección de máquinas para desarrollar un trabajo y responder adecuadamente a las peticiones. Ejemplos: uso de los recursos del pool, indicadores de ajuste de escala, instancias degradadas.
  • Métricas de dependencias externas. Es frecuente que los servicios provean páginas de estado o APIs para detectar problemas. El seguimiento de esta información desde nuestro sistema, junto con el registro de las interacciones con el servicio, puede ayudar a identificar problemas con los proveedores que puede afectar a las operaciones. Ejemplos de este tipo de métricas: Estado del servicio y disponibilidad, tasas de error y éxito, agotamiento de recursos, tasa de ejecución y costes operacionales

Tipos de comportamiento de métricas

[editar]

Atendiendo a sus características se pueden distinguir los siguientes tipos de métricas:[5]

  • Contador. Es una métrica acumulativa que representa un valor numérico que solo puede subir. Por ejemplo un contador de peticiones servidas, tareas completadas, errores ocurridos, etc.
  • Calibrador. Es una métrica que representa un valor numérico que puede arbitrariamente subir o bajar. Por ejemplo una medida de la temperatura, una medida de la memoria usada o el número de procesos en ejecución.
  • Histograma. Muestra observaciones (normalmente cosas con duraciones de peticiones o tamaños de respuesta) y las cuenta en tipos base previamente configurados. Se suele proporcionar una suma de todos los valores observados y de cada uno de los tipos
  • Resumen. De forma similar a los histogramas, muestra observaciones (normalmente cosas como duración de peticiones y tamaños de respuestas). Provee el número total de observaciones, una suma de todos los valores observados y calcula cuantiles configurables sobre una ventana de tiempo deslizante.

Monitorización

[editar]

Las métricas obtenidas desde varias partes del sistema son recopiladas dentro del sistema de monitorización el cual es responsable de:[1]

  • Almacenamiento tanto de los valores actuales con de los datos históricos. Debido a la naturaleza de los datos que gestionan usan bases de datos de series históricas que son un tipo de bases de datos no relacionales.
  • Análisis de la información para realizar muestreos e información agregada sobre las métricas (Frecuencias de suceso, tiempo medio).
  • Visualización para un mejor entendimiento e interacción (listas de valores, tablas, gráficos, panel de control)
  • Organización para correlación de entradas. Por ejemplo para descubrir si un evento está relacionado con que cierta métrica tenga valores muy altos
  • Inicio de respuestas automatizadas (alertas) cuando los valores cumplen ciertas condiciones. Cuando los valores obtenidos en las métricas caen fuera de los rangos esperados, los sistemas de monitorización envía notificaciones para avisar a un operador para que revisen la situación. El sistema de monitorización asistirá a dicho operador, haciendo disponible la información que gestiona, para que pueda identificar la(s) causa(s). La definición de las alertas tiene dos componentes: una condición basada en las métricas y una acción a desarrollar cuando los valores caen fuera de condiciones aceptables.[6]​ La notificación de alerta debería contener suficiente información para diagnosticar que es lo que está pasando. Dependiendo de la importancia de las alertas se puede usar un sistema distinto de notificación (correo electrónico, llamadas, etcétera). Las alertas permiten a los operadores no estar tan pendiente de la monitorización del sistema.


Véase también

[editar]

Referencias

[editar]
  1. a b c d e Ellingwood, Justin (5 de diciembre de 2017). «An Introduction to Metrics, Monitoring, and Alerting». DigitalOcean (en inglés). Consultado el 15 de noviembre de 2018. 
  2. Ellingwood, Justin (5 de diciembre de 2017). «An Introduction to Metrics, Monitoring, and Alerting». DigitalOcean (en inglés). Consultado el 15 de noviembre de 2018. 
  3. a b «DATA MODEL» (html). Prometheus (software) (en inglés). Archivado desde el original el 12 de agosto de 2017. Consultado el 15 de noviembre de 2018. «Prometheus fundamentally stores all data as time series: streams of timestamped values belonging to the same metric and the same set of labeled dimensions. Besides stored time series, Prometheus may generate temporary derived time series as the result of queries.» 
  4. «Métricas TI ¿Cuáles son las que verdaderamente importan?» (html). Pandora FMS. 18 de abril de 2016. Archivado desde el original el 3 de mayo de 2016. Consultado el 15 de noviembre de 2018. 
  5. «METRIC TYPES» (html). Prometheus (software) (en inglés). Archivado desde el original el 6 de enero de 2017. Consultado el 15 de noviembre de 2018. «The Prometheus client libraries offer four core metric types. These are currently only differentiated in the client libraries (to enable APIs tailored to the usage of the specific types) and in the wire protocol.» 
  6. «Principios básicos de los sistemas de monitorización: Clase 101» (html). Pandora FMS. 31 de agosto de 2018. Archivado desde el original el 15 de noviembre de 2018. Consultado el 15 de noviembre de 2018. «Las alertas son un mecanismo planificado: de acuerdo a los valores observados durante cierto tiempo (una semana al menos) podremos establecer que, cuando algunos valores sean alcanzados por más de un tiempo predeterminado, se envíe un mensaje al responsable del área. Las alertas pueden ser directas, por ejemplo por correo electrónico, o delegadas en un tercero, por ejemplo Twitter, Slack, Telegram o Whatsapp.»