Una problemática común para aquellos que trabajamos en el mundo del software es la disponibilidad de nuestras aplicaciones. En primera instancia es imprescindible entender las necesidades de disponibilidad que debe cumplir nuestra aplicación. Esto es una definición que viene dada por una restricción del negocio. En ese sentido hay aplicaciones que solo deben están disponibles en horario de oficina (de lunes a viernes a 9 a 18), mientras que hay otras que puede que solo requieran estar disponibles ciertos días por mes. Y obviamente también están aquellas aplicaciones que tienen que estar disponibles 7 x 24. Esta es una cuestión de negocio que tiene un impacto enorme en las cuestiones técnicas. Desde el punto de vista de desarrollo tenemos que tomar cierta precauciones en el diseño y codificación de nuestra solución. Al mismo tiempo también debemos observar ciertas cuestiones en lo que respecta a la arquitectura física de la solución. Finalmente debemos tener presente una serie de cuestiones operacionales como ser backups, failover, escalamiento, etc. Como consecuencia de varias de estas cuestiones surge la necesidad de ser capaces de detectar una interrupción del servicio ANTES que se entere el usuario final. Más aún, lo ideal es detectar en forma anticipada una posible interrupción para intentar evitarla. Esto implica implementar una estrategia de monitoreo.
Cuando hablamos de monitoreo tenemos distintos niveles:
- Capa 1: hardware / sistema operativo, aquí miramos cpu, memoria, disco, red, etc.
- Capa 2: middleware, aqui miramos métricas particulares del midddleware como ser métricas de la JVM, del web server, la DB, etc
- Capa 3: aplicación, aquí miramos cuestiones más concretas cercanas al dominio de nuestra app. Incluyo aquí tiempo de respuesta, tiempo de carga de las páginas, y también cuestiones como cantidad de usuarios con sesión activa, etc.
Para monitorear cada una de estas capas hay distintas alternativas. Cuando uno corre con una infraestructura de cloud, el proveedor de cloud típicamente provee monitoreo de capa 1. El monitoreo a este nivel es transparente para la aplicación.
Para capa 2 el monitoreo también puede hacerse de forma transparente, y las herramientas para hacerlo dependen en gran medida de cual sea nuestro middleware, o sea, no es lo mismo monitorear tomcat que nginx. Una herramienta de uso común aquí es Nagios (aunque Nagios también puedeusarse en capa 1).
Para capa 3 implementar monitoreo requiere algunos ajustes a nivel de aplicación, o sea, las soluciones tienen cierto grado de intrusión en nuestra aplicación y suelen requerir algunos cambios en nuestro código. Las soluciones son diversas y pueden mezclase. Un caso típico es utilizar Google Analytics para medir tiempos de respuesta y permanencia de los usuarios en ciertas páginas.
Obviamente existen algunas soluciones que proveen la posibilidad de monitorear las 3 capas de manera unificada. A mi parecer la solución más popular a en este segmento es New Relic.
Por otro lado el monitoreo implica 2 cuestiones centrales:
- Recolección de datos
- Ejecución de acciones ante determinadas situaciones. De mínima tenemos el envió de alertas, pero también podríamos activar acciones de escalamiento.
Lo mencionado anteriormente sobre los niveles de monitoreo aplica a la recolección. Respecto de la acciones a ejecutar, ahí también tenemos diferencia en la solución de monitoreo elegida. En este sentido, si la aplicación va a estar disponible 7×24, es posible que el envío de mails no sea suficiente y tengamos que echar mano de mensajes a directos a un teléfono de guardia.
Continuará…
Blog de NicoPaez 