intive Argentina Blog

Los 3 objetivos del monitoreo de aplicaciones

Nuestras aplicaciones suelen estar disponibles para el usuario final, funcionando a una velocidad que le brinda una excelente experiencia. Pero, ¿qué pasa cuando el Product Owner está interminables segundos esperando o simplemente no logra acceder? ¿Qué podemos contestarle cuando nos llama por esa situación? ¿Qué acción futura somos capaces de prometer?

Para saber si una aplicación está funcionando, nuestro mejor aliado es el monitoreo. Es indispensable medir su rendimiento. Así, el análisis que podamos obtener nos habilita a responder los siguientes interrogantes:

Como pudimos ver en el cuadro anterior, al monitorear nuestra aplicación, los objetivos que perseguimos abarcan conocer su disponibilidad, rendimiento y capacidad. Veamos cada uno de ellos en detalle.

Los 3 objetivos del Monitoreo de Aplicaciones

1) Disponibilidad

La disponibilidad nos indica si la aplicación funciona y si está brindando servicio. No significa sólo que el servidor y los servicios estén funcionando, sino también que tenemos clientes consumiéndola. Por lo tanto, vamos a necesitar no solamente monitorear los servicios, sino también los componentes que soportan la posibilidad de que los clientes se conecten.

Para comprobar la disponibilidad, deberíamos:

  • Saber si los componentes de la aplicación están funcionando en todas las capas. Al menos verificar uno por capa, para saber que damos servicio de punta a punta.
  • Conocer si el tráfico de la aplicación es menor que lo habitual. Si esto sucede, posiblemente signifique que los usuarios no están pudiendo acceder, o al menos no todos los que lo intentan. Para esto, tenemos que conocer un baseline y por eso necesitamos el historial de las métricas leídas.
  • Realizar transacciones sintéticas, que pueden ayudarnos a corroborar que las funcionalidades estén dando servicio.

2) Rendimiento

El rendimiento nos va a decir cómo está corriendo la aplicación, respecto a la percepción del usuario. Por ejemplo, se pueden medir el uso de los recursos, y los tiempos de respuesta de lo que se entregue al usuario.

En el caso de los lenguajes que utilizan entornos de ejecución, como CLR o JVM (para .Net y Java respectivamente) la visibilidad del uso de los recursos es distinta si observamos la app o si prestamos atención al sistema operativo en sí mismo. Por ejemplo, hay un manejo de memoria que no es visible fuera de los entornos. Para solucionar esta dificultad, existen herramientas que nos ayudan a obtener esta información, para saber cuál es el estado en cada momento. En el caso de Java, por ejemplo, JConsole o VisualVM son herramientas que nos permiten explorar una JVM, quizás no en un ambiente productivo, pero sí para observar el comportamiento de una aplicación; luego mencionaremos más herramientas del mercado.

Por otro lado, conocer el rendimiento de la aplicación y de sus componentes, nos permitirá predecir futuros comportamientos. Por ejemplo, si tenemos un número creciente de objetos que no se cierran, podemos deducir que posiblemente agotemos recursos para crear otros nuevos, llegando a la instancia en algún momento de que la aplicación deje de funcionar. Esta previsión puede ayudarnos a tomar una acción preventiva para evitar que suceda o, lograr que suceda bajo control (por ejemplo, podemos reiniciar una instancia, evitando que caigan todas sin previo aviso). Para implementar este monitoreo hay diferentes enfoques:

  • Conocer cómo está trabajando cada componente de la arquitectura: tiempos de respuesta, uso de memoria, CPU utilizado, I/O, etc. Algunas herramientas nos pueden llegar a mostrar incluso cuántas veces se invocan y qué tiempo de respuesta tienen los métodos de las clases seleccionadas.
  • Saber cuánto demora la respuesta de una transacción de negocio en salir al cliente. Ya sea midiéndola desde el punto de vista del cliente (algún snippet en el browser, por ejemplo, u observando el tráfico en algún punto controlable de la red (de modo que veamos toda la interacción http entre ambos, y podamos deducir la duración total de las interacciones).

En una disciplina madura de monitoreo, se podrán analizar también las tendencias de rendimiento: cómo esperamos brindar servicio en un futuro próximo, conociendo el historial de comportamiento. De tal modo, sin necesidad de haber configurado previamente umbrales de rendimiento para n métricas, igual sabremos que hay una degradación en camino. Entonces implementaremos un monitoreo preventivo, tomaremos acciones y nos anticiparemos a posibles fallos.

3) Capacidad

¿Cuántos usuarios están utilizando la aplicación? ¿Cuántos de ellos usan la misma funcionalidad? ¿Qué impacto habrá en el próximo despliegue a producción, respecto a las funcionalidades más utilizadas?

El concepto de “Capacity” debe darnos respuesta a las preguntas anteriores. Puede también ayudarnos a calcular el crecimiento a futuro en infraestructura, o en cuanto a escalabilidad de nuestros servicios. Nos va a permitir:

  • Conocer el volumen de transaccionalidad
  • Conocer los recursos usados
  • Dimensionar y reestructurar recursos
  • Planificar releases

Riesgo

La variable “Riesgo” puede ser entendida como un corolario de los conceptos anteriores. Si está disponible menos de un 𝝰% de alguna capa de nuestra aplicación, podemos decir que nuestra aplicación tiene un riesgo alto de no brindar servicio.

El análisis de cada componente en la posibilidad de brindar servicio, le dará al mismo un peso específico dentro de la medida de Riesgo de la aplicación.

Análisis Vertical

Teniendo los objetivos anteriores analizados, y habiendo logrado monitorear las distintas capas de nuestra aplicación, podemos particularizar su estudio en funcionalidades específicas.

Es decir, conociendo los componentes involucrados en una transacción en particular, para cada capa de la arquitectura, podemos decir si una funcionalidad está brindando servicio, si está deteriorada, o tiene un determinado % de errores.

Por ejemplo: en un cierto período de tiempo, nuestro sitio ejecutó X intentos de ventas, de las cuales un 80% fueron exitosas, 10% fueron abortadas por el usuario y un 10% restante fallaron por timeout. Coincidentemente, el CPU estuvo en un umbral crítico por momentos y, los métodos involucrados en tales transacciones tomaron más tiempo del usual para ejecutarse.

¿A quién le interesan los resultados del monitoreo?

Esta visión del monitoreo tiene muchos beneficiados dentro del área de sistemas, ya que puede observar el comportamiento de las aplicaciones en producción, como también controlar los ambientes de homologación para saber si los nuevos releases resienten de algún modo al rendimiento de la aplicación.

A su vez los resultados de monitorear ambos ambientes, pueden ser muy útiles para que los desarrolladores entiendan en qué tipo de transacciones tiene baja performance la aplicación.

También la mesa de ayuda podrá anticiparse a un aluvión de reclamos cuando haya algún incidente, si ya sabemos que está por ocurrir.

Por último, el mismo Product Owner puede estar interesado en conocer qué capacidad operativa tiene con el presupuesto actual de TI, cómo sienten a la aplicación los clientes, e incluso en qué puntos hay que invertir.

El mercado ofrece herramientas de distinta complejidad y precios, para implementar algunos o todos los objetivos de los que hablamos. También existen aplicaciones de código abierto a las que podemos sumar componentes propios que brinden información de monitoreo, para así poder implementar el monitoreo que necesitemos. No nos olvidemos que teniendo cubiertos los objetivos que necesitamos, aunque sea con unas pocas métricas, ya es suficiente para mejorar nuestros resultados.

Herramientas de monitoreo

Líderes del mercado (herramientas “world class”)

https://www.ca.com/us/products/ca-application-performance-management.html

https://newrelic.com/products/application-monitoring

https://www.dynatrace.com/capabilities/

https://www.appdynamics.com/solutions/unified-monitoring/

Estas herramientas, en general son parte de una suite de monitoreo integral. La mayoría tiene componentes (agentes) que exploran internamente JVMs, CLRs, e incluso frameworks de runtimes, como es el caso de PHP + Zend. Están evolucionando a las nuevas tecnologías, pudiendo tomar datos de salud de Docker, VMWare ESX y demás.

Siendo las líderes y referentes del cuadrante mágico de Gartner, suelen tener costos altos, y niveles de soporte acordes al mismo, por lo que suelen estar presentes en grandes empresas y bancos.

Herramientas de Código Abierto

Las herramientas de código abierto más importantes que permiten crear una suite de monitoreo están lideradas por las dos siguientes. Cada una tiene un fuerte y hay muchos análisis de las mismas en la web (por ejemplo: https://geekflare.com/best-open-source-monitoring-software/ )

https://www.zabbix.com/

https://www.nagios.org/

Una característica de estas aplicaciones es que quizás requiriendo algo más de trabajo de configuración y de generación de una solución personalizada de monitoreo, pueden brindarnos información similar a las “world class”, dándonos la oportunidad de perseguir nuestros objetivos.

Rogelio Di Pasquale

Rogelio Di Pasquale es ingeniero DevOps en intive-FDV desde noviembre de 2017. Ingeniero en Sistemas graduado de la Pontificia Universidad Católica Argentina (UCA), Roger es profesor de la misma casa de estudios y de la Universidad de Ciencias Empresariales y Sociales (UCES). Siempre interesado en aprender, fue desarrollador, consultor y hoy, además, es miembro de la brigada DevOps. Bajista aficionado y padre, busca todos los días transmitir su pasión por la música y la tecnología a sus hijos.

Deja un comentario