La estrategia de la monitorización la he querido diferenciar en dos aspectos fundamentales:
- Tipos de monitorización; Definiendo como se va ha llevar a cabo la monitorización de nuestros sites. Dependerá de las capacidades y las necesidades que tenga y lógicamente la orientación a la cual esté definida nuestra web.
- Formas de monitorización; A nivel teórico los métodos o formas en las que podemos llevar a cabo la monitorización de las webs. Contemplando tanto acciones manuales como automáticas en base a los resultados que se quieran obtener.
Lógicamente otras bibliografías dividen la estrategia en otras características, no por ello mejores o peores a las identificadas en este artículo, pero me ha parecido interesante dividirlas y describirlas para posteriormente identificar los parámetros a monitorizar independientemente de la estrategia escogida.
Tipos de monitorización
1) Monitorización Interna/Externa
Básicamente la monitorización interna o externa hace referencia desde donde se lanzan los agentes de monitorización o desde donde se lleva a cabo la misma: a nivel local de las máquinas o desde un acceso remoto como si de un usuario “externo” se tratara.
Lógicamente los resultados serán muy diferentes debido a que estamos eliminando una serie de elementos, como DNSs públicos, elementos de red, … cuando llevamos a cabo una monitorización interna, pero perfectamente válida si estamos hablando de una intranet corporativa con un gran número de accesos en local.
Hace unos años (muchos) el acceso remoto se simulaba mediante modems que se conectaban cuando se lanzaban los agentes o robots de monitorización. Actualmente una buena solución es lanzar agentes desde máquinas en cloud en caso de no tener otras localizaciones desde donde poder hace las pruebas.
En todo caso y siempre hablando de Webs públicas, es muy recomendable llevar a cabo una estrategia que contemple tanto agentes locales, para confirmar que los servidores responden correctamente, como remotos para confirmar que los elementos externos están trabajando correctamente.
Este tipo de monitorización puede llevarnos a conclusiones como la necesidad de contratación de servicios CDN como Akamai o similares para la mejora de tiempo de respuesta en los accesos.
2) Monitorización de la arquitectura
He querido referenciar la monitorización de la arquitectura o máquinas que conforman la infraestructura Web dentro de tipos de monitorización para no tener críticas conforme, aparte de la navegación propia de los usuarios, un aspecto importante es el propio consumo de recursos de las máquinas.
Lógicamente este es un aspecto fundamental para la navegación y sobre todo para conocer las capacidades de los sistemas pudiendo referencia la misma como parte de la monitorización básica de los sistemas.
Para dar un punto de valor añadido a la monitorización de la arquitectura, haremos un breve guiño a como garantizar que lo que estamos monitorizando es correcto. Lógicamente hacer prueba de cargar antes de poner nuestros entornos en producción nos garantizarán posteriormente una monitorización óptima y preventiva. Estos test nos dará la línea base que permitirá conocer nuestros sistemas para que una vez se estén monitorizando podamos definir correctamente los umbrales en los cuales tenemos riesgo de pérdida de servicio.
Entre estas pruebas existe podemos identificar las definidas a continuación:
- Test de Rendimiento; Aumentando los usuarios gradualmente para conocer los tiempos de respuesta de nuestro sistema hasta llegar al porcentaje de peticiones fallidas que consideremos inaceptable.
- Test de Capacidad; Una vez conocidos los máximos usuarios concurrentes, se revisa la capacidad del sistema para garantizar cuantos pueden trabajar de forma óptima y sin degradación de la calidad del servicio. Al igual que el test de rendimiento se irán subiendo los usuarios paulatinamente, pero en este caso nos interesa conocer el punto en el cual comienza a degradarse el sistemas.
- Test de estrés; Cada sistema tiene una capacidad límite en base a su arquitectura, independientemente del rendimiento que se persiga. Con este tipo de test, el objetivo es encontrar el límite de los sistemas y una vez finalizado el test de estrés, que nuestra arquitectura vuelva a un estado de reposo que permita seguir funcionando correctamente. Estos tipos de test permiten garantizar que aplicaciones, por ejemplo realizadas en java, no dejan los sistemas totalmente inoperativos incluso después de la finalización de las pruebas.
- Test de volumen; Se realizan generalmente para poner a prueba el back-end del sistemas, ejecutando transacciones complejas para ver que reacciones tienen las bases de datos y la cantidad de carga que soportan en caso de consultas de larga duración o complejas. En este tipo de pruebas se puede ver lo óptimo de las queries de los programadores.
- Test de Resistencia; También denominado “soak Test” se lleva a cabo para garantizar que nuestros sistemas pueden trabajar durante un largo periodo de tiempo al máximo de su capacidad y no se van degradando con el tiempo. O bien determinar cuanto tiempo pueden aguantar al máximo de su capacidad.
- Test de Regresión; Básicamente es la realización de las mismas pruebas de estrés de forma regular y en base al cambio de versión de la aplicación analizada. Esto nos permite garantizar que las nuevas versiones que se van desplegando son igual de optimas que las anteriores. Lógicamente las pruebas deben ser exactamente las mismas para garantizar su correcta comparativa.
Mediante la realización de las pruebas de carga, garantizaremos que nuestra posterior monitorización es correcta y que los parámetros monitorizados están dentro de los umbrales óptimos de los sistemas.
Formas de monitorización
Una vez definidos los tipos de monitorización, debemos conocer como vamos a realizar los mismos. Lógicamente algunos de ellos nos parecerán obvios, pero en muchos casos el tipo de web a la que queremos llevar a cabo las pruebas no nos dejará otra alternativa.
- Monitorización Manual; Cuando me refiero a una monitorización manual, concretamente es eso. Definir una serie de pasos, parámetros o supuestos que deberemos ir siguiendo cada vez que queremos comprobar el estado de nuestro Web site. Mediante una check-list correctamente definida se analizará el resultado de los componentes de la web, tanto a nivel de resultado como de grado de respuesta. Aunque pueda parecer algo arcaico, cuando un cliente se nos queja de que un servicio funciona incorrectamente, este será el primer diagnostico que deberemos ejecutar para comprobar que esta pasando y los sistemas no han detectado nada incorrecto. Así mismo hay infraestructura que debido a su desarrollo no permiten (o es complejo) la monitorización automática de los mismos. Así que nunca descartéis generar procedimientos de pruebas en vuestros sistemas monitorizados durante un arranque de servicio.
- Monitorización con Robots / Herramientas; Es la forma más común de realizando. En la parte de herramientas defino algunos de estos elementos que deben facilitarnos la existencia o, al menos, no hacérnosla tan aburrida como ejecutar cada N horas una revisión manual.
- Monitorización mediante páginas internas de la aplicación; Este procedimiento también es muy óptimo y práctico. Una vez realizar la Web, se especifica a los programadores realizar una página de pruebas que nos devuelva OK+ o ERR+ si las acciones realizadas en la aplicación (consulta a la BD, acceder a otros servicios, …) no actúan correctamente. Realmente es una solución sencilla y muy efectiva. Aparte puede ser lo compleja que queramos incluso devolviendo tiempos de respuesta en consultas para definir si realmente están dentro de los parámetros tolerables de la aplicación.
Durante los siguientes puntos bajaremos de nivel estos conceptos mediante parámetros reales de monitorización así como herramientas que nos permitirán llevar a la práctica todos estos conceptos.
Enjoy!!!
jotaerre.net 