Blog

Nuestras herramientas de monitorización

21/02/2014

En ASPgems hacemos aplicaciones web. Esto quiere decir que, entre otras cosas, desarrollamos, diseñamos… y monitorizamos. Porque en el mundo del desarrollo web necesitas monitorizar sí o sí. No es una opción. Y no sólo para medir rendimiento y detectar cuellos de botella, queries lentas… sino para hacer una gestión proactiva de las incidencias.

Hay que asumir que nuestras aplicaciones tendrán fallos: ya sea debido a un mal código, a un aumento no previsto del tráfico, a que un proveedor de terceros se cae… puede suceder que tu aplicación deje de funcionar bien en parte, o bien por completo. Y es importante darte cuenta de ello cuanto antes. Antes incluso que los usuarios o el propio cliente. Si haces esto vas a conseguir minimizar la tasa de abandono de tus usuarios por errores en tu aplicación o incluso localizarlos para explicarles cuáles han sido los problemas, ofrecer algún tipo de solución si se ha producido algún tipo de perjuicio, etc. También vas a conseguir que tu cliente no se tenga que preocupar por los posibles fallos, porque si te das cuenta antes incluso que él mismo de que algo ha fallado inesperadamente, lo que le estás dando es seguridad de que estás con el control de la aplicación, que estás al tanto de los posibles fallos que puede haber, y que si los hay, estás preparado para minimizar el coste asociado al mismo. En definitiva, que tienes el proyecto bajo control.

A continuación voy a resumir qué herramientas y técnicas utilizamos para minimizar los daños causados por un mal funcionamiento de nuestras aplicaciones.

 

Gestión de excepciones

Las excepciones no llegan a ser el enemigo natural del desarrollador (ése es la impresora), pero sí son un compañero de trabajo incómodo. La gestión de excepciones es incómoda, ensucia tu código y no siempre se tienen en cuenta. En ASPgems solíamos utilizar el envío al correo de los desarrolladores  de las excepciones que se producían durante el funcionamiento de la aplicación, pero recientemente comenzamos a utilizar Rollbar para esto.

 

Gestión de recursos de las máquinas

Nuestro código corre en máquinas, que tienen unos recursos finitos de memoria y, dependiendo del uso que se le dé, podemos llegar a dejarlas sin memoria, se pueden caer procesos que hay que levantar para que funcione la aplicación…. Para hacer esta gestión de forma proactiva, utilizamos monit. Monit es una solución de software libre que sirve para monitorizar procesos, ficheros, programas, directorios… de forma que puedes establecer una serie de reglas según las cuales si un proceso se detiene por cualquier razón, se levante automáticamente, o si un proceso consume más de cierta memoria, se reinicie liberando memoria

 

¿Está la aplicación levantada?

¿Qué pasa si el servidor se ha caído? ¿Cómo detectar esto sin que sea el cliente o, peor, un usuario el que nos avise? Para esto utilizamos pingdom. Pingdom hace una petición http cada cierto tiempo a la url a la que le digamos, y si ésta no responde nos envía una notificaicón por mail y por sms.

 

DDM (Devop driven monitoring)

¿Y es todo esto suficiente? La respuesta es simple y llanamente no. Porque igual que en un coche tenemos sistemas de seguridad pasivos y activos, en nuestras aplicaciones web ocurre lo mismo. Hasta ahora hemos visto qué herramientas utilizamos para recuperarnos o  enterarnos ante fallos ya producidos (como el airbag de un coche que salta una vez se ha producido el impacto), pero ¿qué pasa mientras no se producen fallos? Pues que deberíamos observar tendencias y detectar posibles cuellos de botella en el rendimiento de nuestra aplicación de forma que podamos saber qué partes del sistema son más proclives a sufrir fallos: base de datos, código, memoria, cpu, etc. Para esto nos servimos de dos herramientas: munin y newrelic.

Munin nos sirve tanto para observar tendencias como para poder hacer análisis postmortem tras una caída de un sistema. Podemos medir parámetros como volumen de acceso a Apache, uso de la memoria de la cpu, del disco, de la red, número de hilos… Así que mediante gráficas podemos observar, por ejemplo, si el aumento en el tráfico de nuestra aplicación se ve reflejado en un aumento en el uso de los recursos del sistema antes de que se produzca una falla o cuál es la tendencia del consumo de la memoria en el tiempo para poder prepararnos y aumentar la memoria de una máquina antes de que ésta empiece a dar problemas.

Newrelic nos sirve para optimizar nuestro código, para saber cómo de eficiente es nuestro código o si tenemos un cuello de botella en nuestro acceso de base de datos o en nuestra integración con terceros. Si tenemos código ruby lento o si hay un proceso que se ejecuta en background que deberíamos afinar. De esta forma sabemos qué partes de nuestra aplicación deberíamos revisar y refactorizar a medida que nuestra aplicación vaya teniendo más uso y evitar que se produzcan fallos, y mejorar la experiencia del usuario.

También te puede gustar…

Caso de éxito: Fronda

Caso de éxito: Fronda

Fronda, es una cadena de centros de jardinería que cuenta con una tienda online que opera por toda España con la que hemos colaborado.

ASPgems icon
C/ Sextante, 9
28023 Madrid,
España

Hablemos.

A %d blogueros les gusta esto: