¿Dónde medir la salud de una aplicación?

0

En un post anterior ya os conté que el objetivo de la monitorización es saber si las cosas van bien o mal. Es decir, sacar información valiosa del estado de nuestro servicio. Por lo tanto, ya no se trata de medir CPU, peticiones por segundo, ratios de conversión y métricas similares, sino de combinar todos esos datos para obtener información. Y lo queremos en tiempo real. Una de esas informaciones básicas es saber si nuestras aplicaciones están funcionando bien. Es decir, un indicador de salud de la misma.

Un indicador de salud de una aplicación no es más que una métrica, como un número del 0 al 10, que nos dice lo “sana” que está. Si nos dice 10, es que todo va estupendamente. Si nos da una métrica baja, es que algo le pasa y le tenemos que prestar atención. Puede ser un nivel de alterta (OK, Warning, Critical), un porcentaje o cualquier otro tipo de métrica. Al final es saber si la aplicación necesita que alguien la revise, y lo urgente que es esa revisión.

Lo normal es que este indicador sea la combinaciones de montones de métricas, cada una de las cuales puede indicar un mal funcionamiento. Por ejemplo, 10 minutos con la CPU por encima del 95% podría bajar esta métrica a un 2. Un espacio en disco menor a 100 MB, podría poner la métrica en 7. Un ratio entre peticiones procesadas y CPU consumida bajo, podría indicar un problema de rendimiento. Así, estamos ante un escenario en el que tenemos multitud de métricas que tenemos que procesar para sacar la información que queremos.

Pero, ¿dónde se calcula ese indicador? Aquí, hablando con compañeros veo dos grandes tendencias, que veo apoyadas a partes iguales. Yo tengo mi opinión, que os diré al final. Pero no tengo por qué tener razón yo, ya que veo que mucha gente me da argumentos del otro lado.

Opciones

Las dos opciones son dos:

  1. Mandar las métricas a algún repositorio externo, y que un sistema las procese y obtenga la métrica de salud.
  2. Que la propia aplicación calcule su salud y sea lo que envíe.

En el primer escenario los desarrolladores se preocupan de generar métricas de lo que sucede en la aplicación y de mandarlas a algún sistema, o de crear algún end-point que pueda consultar algún sistema externo. Por otro lado los encargados de la explotación que ven las métricas día a día, ven lo que es normal y definen, en el sistema de procesado de la monitorización, las métricas de salud adecuadas.

En el segundo escenario los desarrolladores ya programan la métrica de salud. Esto evita a los encargados de la explotación tener que conocer al detalle las interioridades de la aplicación, y les permite tener métricas más sencillas.

Empieza la lucha, ventajas de cada opción

Los defensores del primer escenario, procesar las métricas fuera de la aplicación, pueden argumentar las siguientes ventajas:

  • Separas perfectamente la lógica de la aplicación de la lógica de monitorización.
  • Minimizas la huella de la monitorización en las aplicaciones.
  • Puedes cambiar o ajustar la monitorización sin necesidad de crear nuevas versiones y tener que hacer releases, que pueden poner en riesgo el sistema.
  • Disminuyes, por consiguiente, los puntos de fallo de la aplicación.
  • Puedes crear reglas complejas, que involucren datos de varias aplicaciones.

Los defensores del segundo escenario, que la propia aplicación calcule su estado de salud, argumentan:

  • Los que mejor pueden definir la salud de la aplicación son los desarrolladores.
  • Obligas a los desarrolladores a preocuparse de la monitorización, fomentando un acercamiento a DevOps.
  • No es necesario sacar tanta métrica fuera de la aplicación.
  • Permites una explotación más sencilla, ya que pueden saber si va bien, sólo con variables procesadas.
  • Tienes todos los datos en crudo disponibles, porque se calcula en el origen de esos datos, no como cuando se procesan, que sólo tienes disponible lo que se ha monitorizado.

¿Tú tienes claro de qué lado estás? ¿Qué camino se sigue en tu organización?

Mi opinión personal

Bueno, lo prometido es deuda, así que aquí os dejo mi opinión. Yo creo que lo mejor es mandar las métricas a un sistema externo y allí generar las métricas de salud. Son muchos los motivos pero creo que el mejor es que es mucho más fácil cambiar ese cálculo en los sistemas de motorización, que en la propia aplicación. Cada día se ajustan los valores. Lo que hoy era válido para medir la salud, mañana no lo es. Además, cada vez más, los cálculos para medir esos indicadores son más complejos. Primero se empieza por medias en un intervalo de tiempo, luego son medias móviles, luego medias exponenciales móviles y cuando te das cuenta estás metido de cabeza en sistemas de machine learning. Querer que la aplicación genere ese tipo de métricas avanzadas es prácticamente imposible.

¿Opinas diferente? Pues me encantaría oir tu opinión.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios