Menta

Blog

Cuidando la salud de tu aplicación Web

​¿Sabes qué tan bien está funcionando tu aplicación web? Ojo, no estoy preguntando si está funcionando—si puedes acceder a ella y te responde en tiempo razonable—, lo que pregunto es si está sana.

Es fácil notar que tu aplicación ya falló y tienes que tomar acciones inmediatas para revivirla. Te das cuenta porque es viernes en la noche, estás a punto de salir de la oficina y comienza a sonar tu teléfono.

Lo difícil es saber si tu aplicación está en mal estado antes de que falle, percibir las señales de alerta y prevenir los incidentes antes de que ocurran. Curarse en salud es el sueño de todo administrador de sistemas que quiere irse temprano a casa.

Pero en este contexto ¿qué significa que una aplicación esté sana? ¿cuáles serían las señales de alerta que me indicarían que algo podría estar mal?.

Los cuatro signos vitales

Cuando vas al doctor, te revisan tus signos vitales: temperatura corporal, frecuencia cardiaca, tensión arterial, frecuencia respiratoria.

Los signos vitales le indican al doctor el estado de los principales órganos del cuerpo. Aunque en sí mismos no son suficientes para producir un diagnóstico, le dan al facultativo una idea de lo que está funcionando bien y dónde hay problemas.

De la misma forma podríamos decir que hay cuatro indicadores de la salud tu aplicación: la latencia, el porcentaje de errores, el tráfico y la saturación. A continuación explicaré cada uno y cómo puedes monitorearlos.

Latencia

¿Qué es?

También llamada tiempo de respuesta: los milisegundos que tarda tu servidor en responder cada petición. El reloj comienza a correr cuando lees los primeros bytes que envió el usuario y se detiene cuando terminaste de enviar la respuesta.

¿Qué nos indica?

Nada… en principio. La latencia de UNA única petición no nos da mucha información. Es hasta que empezamos a acumular y examinar grupos de peticiones que patrones interesantes comienzan a emerger:

Finalmente, es posible definir la salud de nuestra aplicación en términos de la latencia. Esto variará de servicio a servicio, pero podemos decir, por ejemplo: si el 95% de nuestras peticiones tienen una latencia de 1500 milisegundos o menos y ninguna petición excede los 5 segundos, entonces el sistema está funcionando bien.

¿Cómo medirla?

Tu servidor normalmente registra la latencia, pero seguramente tendrás que configurar tus logs para incluir esta medida en tus registros:

Tráfico

¿Qué es?

El número de peticiones que se reciben en cierto intervalo de tiempo. Las medidas más comunes son RPM (peticiones por minuto) y RPS (peticiones por segundo).

¿Qué nos indica?

Generalmente tener una mayor demanda es una buena señal para nuestro sistema (¡Aleluya, somos populares!) pero una mayor demanda puede afectar nuestro desempeño, por eso es importante monitorear de cerca nuestro tráfico, por ejemplo:

¿Cómo medirlo?

Normalmente tu servidor guarda una entrada en el log por cada petición recibida. Agruparlas por intervalos de tiempo es algo que puedes hacer con un Analizador De Logs (que revisaremos en una próxima entrada). Adicionalmente:

Capacidad de Respuesta o Throughput

Aunque estamos midiendo el tráfico, lo que en realidad quieres mejorar es la capacidad de respuesta (throughput) de tu aplicación. Esto es, la cantidad de peticiones que tu sistema puede procesar simultáneamente.

Determinar cuál es la capacidad de respuesta de tu sistema va más allá de medir el tráfico y mejorar tu throughput suele ser un problema que va más allá de aumentar los recursos del servidor, en entradas posteriores ahondaremos más en este tema.

 

Porcentaje de errores

¿Qué es?

La proporción de peticiones recibidas que terminan en error.

¿Qué nos indica?

Aún una aplicación que funciona bien producirá cierto porcentaje de errores. Pero si identificamos qué porcentaje de errores es “normal” para nuestra aplicación podemos intuir problemas si ese porcentaje cambia.

¿Por qué medir el porcentaje de errores en lugar del total de errores?

Porque el total de errores va a variar en proporción a nuestro tráfico, nuestra aplicación puede lanzar 100 errores un lunes y 300 errores el sábado, eso es normal si sabemos que los fines de semana se triplica nuestro tráfico. Pero a veces pequeños cambios en el porcentaje de error pueden indicar problemas mayores. Por ejemplo:

¿Cómo medirlo?

Como pudiste ver en los ejemplos, los errores pueden tener diversas fuentes (servidor, aplicación, base de datos, etc.) así que quieres monitorear cada fuente por separado. Una revisión de cómo recopilar errores en todas las combinaciones de servidor-aplicación-base de datos va más allá del alcance del presente artículo, pero confiamos en que sabes cómo obtener los reportes de errores de tu aplicación.

Saturación

¿Qué es?

El porcentaje de los recursos del sistema que estamos usando. Agrupa el uso vs. disponibilidad de varios recursos. Los más importantes son: procesador, memoria, disco.

¿Qué nos indica?

La interpretación de estas estadísticas depende del sistema y su relación con las otras métricas, por ejemplo:

¿Cómo medirlo?

Sencillo: conéctate remotamente a tu servidor y abre la aplicación de monitoreo provista por tu sistema operativo (htop, Windows Performance Monitor, etc). Pero realmente, no te interesa tanto saber cuál es la situación actual, tanto como ser alertado cuando tus recursos alcancen niveles críticos.

Para servidores Linux puedes usar una herramienta como Monit que te alerte cuando el sistema supere cierto umbral de saturación.

Para Windows Server puedes crear alertas en el Monitor de Desempeño y asociarla a una acción de envío de correo creada desde el Programador de tareas.

Conclusión

Ahora ya conoces los cuatro signos vitales de tu aplicación y puedes responder a la pregunta ¿está funcionando bien mi aplicación?

Pero conocer estos indicadores es únicamente el primer paso en el proceso de conocer mejor tu aplicación y hacerla más confiable. En posteriores entradas hablaremos más sobre monitoreo de aplicaciones, alertas, optimizaciones y otras herramientas que puedes usar para mejorar el rendimiento de tu aplicación.

Un tema recurrente cuando hablamos de monitoreo, es que la información que necesitamos para entender nuestra aplicación y tomar mejores decisiones de negocio y desarrollo… muchas veces es información que tenemos a la mano en nuestro servidor, pero es información que no estamos usando o que revisamos únicamente cuando ocurre un error grave.

Por eso vale la pena acercarse a un experto que te oriente en el uso de metodologías formales que produzcan resultados predecibles. En Menta estamos disponibles para atenderte.