Como técnico de soporte de aplicaciones web he utilizado muchas y diversas aplicaciones de motorización. En mis inicios algunas opensource como Zabbix o Nagios eran de las más comunes.

Los motivos, a parte del hecho de ser “gratis”, eran su uso extendido y las comunidades de soporte que contribuían con numerosos plugin y documentación. Pero todo tiene un precio, el mantenimiento y desarrollo de este tipo de sistemas, sobre todo cuando se usan en entornos grandes y variados, es caro en fuerza de trabajo y hardware.

Recientemente en Enimbos comenzamos a trabajar con New Relic, un sistema de monitorización SaaS muy completo en tiempo real. Las siguientes características sobresalen a primera vista:

  • La facilidad de uso: se configura e instala en unos 15 minutos, el interfaz es bastante intuitivo y existe mucha documentación. Además también cuenta con una comunity de gente bastante activa.
  • El casi inexistente overhead que causa en los recursos incluso con la instrumentalización estándar la sobrecarga es mínima. Por otro lado, también cuenta con el “circuit breaker” que nos protege en situaciones de stress.
  • La cantidad de datos recogida y las herramientas que facilitan el análisis de dichos datos.

Las ventajas del modelo de SaaS también son evidentes:

  • El coste del mantenimiento es prácticamente cero, algo que no pasa con las herramientas on premise, no te tienes que ocupar de hardware ni de parches o actualizaciones.
  • Puedes utilizar la misma herramienta sea donde sea que corra tu aplicación.
  • Escalabilidad y velocidad para el análisis de los datos recogidos por los monitores.
  • Seguridad.

Nosotros usamos sobre todo el módulo APM y los dashboards de Insight, aunque es cierto que tanto Browser como Synthetics son también muy útiles en los diagnósticos de Web.

APM nos ha ayudado mucho en la más temida incidencia que nos puedan reportar en el mundo web: “la aplicación va lenta”.  Para un técnico de sistemas esto es el talón de Aquiles, los síntomas habituales:

  • se dispara el consumo de memoria
  • o se dispara el consumo de CPU
  • o los dos
  • o ninguno…

Al final  se toma la decisión de reiniciar, y aunque la cosa mejora, no te puedes relajar porque volverá a suceder al no haberse resuelto el problema.

A pesar de que estos síntomas en el 90% de las situaciones, se deben a algún cuello de botella o a algún leak en el código, estas incidencias normalmente continúan en el tejado de sistemas, ya que, sin más datos, desarrollo no puede localizar el problema. En definitiva, terminan por enquistarse.

Generalmente se termina teniendo que tomar medidas paliativas como reinicios periódicos y solo tras laboriosos análisis de volcados de hilos y heapdumps se puede intuir por dónde van los tiros.

Con New Relic esto no ocurre, ya que nos facilita mucho el análisis al aportar la información de, que está pasando, en tiempo real. Veámoslo con un ejemplo:

Supongamos que nos avisan de lentitud en una aplicación web: el primer paso sería  ir a la pantalla Overview, donde se ofrece un resumen del rendimiento general de la aplicación. Esta pantalla sirve para orientarnos en la dirección correcta pero no para diagnosticar problemas específicos:

 

Aquí encontramos información de tiempo de respuesta web, Apdex, throughtput, tiempo de respuesta de transacciones, porcentaje de error y métricas de la máquina virtual Java.

En caso de que alguno de estos apartados esté mostrándonos algo fuera de lo normal, simplemente pinchando nos llevaría a una página con datos más detallados de ese aspecto de la aplicación.

Me centrare en este caso en la parte de análisis de transacciones que en este tipo de incidencias nos ha resultado especialmente útil.  En la pantalla Overview:

 

Como se puede ver hay algunas transacciones que están tardando más de un minuto, pinchamos directamente en ella y esto nos llevara a una pantalla con todos los detalles de esta transacción en particular:


La cantidad de detalle es muy elevada, podemos ver desde en que hosts se ha ejecutado, cuanto ha tardado y una lista ordenada de la duración de las ejecuciones de cada componente. En nuestro caso parece que lo más pesado ha sido una select a una BBDD Oracle. Aparecen además dos pestañas donde observamos trazas detalladas de la ejecución y si… las queries que han provocado la lentitud:

 



Como se puede observar en cuestión de minutos hemos descubierto exactamente cuál es el problema y ya solo nos queda mandarles la info a nuestros compañeros de desarrollo que a buen seguro le darán un buen uso.

Algunos al llegar a este punto me acusaran de haber seleccionado un caso muy sencillo…. Reto aceptado…. más difícil todavía:

Incidencia entrante: la aplicación va extraordinariamente lenta y la monitorización tradicional nos muestra incremento de CPU.  Si siguiésemos el procedimiento tradicional de debug deberíamos realizar los siguientes pasos:

  • Sacar volcado de hilos java (para obtener los stack trace).
  • Simultanemente ejecutar un listado de consumo de CPU por cada thread de proceso linux.
  • Coversion de los TID de los hilos de linux a hexadecimal para establecer la correspondencia entre hilos java e hilos de sistema.
  • Analizar el stack trace de los hilos que mas CPU consumen para intentar saber que parte del código es la que lo causa.
  • Realizar pruebas de carga sobre esa parte del código para analizar su rendimiento.
  • Etc, etc,..

Análisis del problema con New Relic, como el caso anterior vemos que ciertas transacciones están tardando de más:

 

Veamos con más detalle las más lentas en la pestaña de transacciones:


Esto sigue más pantallas, a primera vista podemos asegurar que , aunque las consultas que se producen son rápidas son exageradamente numerosas:

 

El problema llegado a este punto está claro, hay alguna transacción que hace numerosas llamadas concurrentes a la BBDD y eso es lo que está consumiendo la CPU. Por tanto, la solución es una optimización de esa parte del código.

Evidentemente no solo hemos ahorrado tiempo en el diagnostico (semanas de hecho), sino que este es más preciso que los métodos tradicionales.

Para verlo aún más claro y confirmar el problema podemos usar otro modulo: Insight, este módulo recoge datos del resto de módulos como APM, Browser, etc para mediante gráficos poder relacionarlos y hacer un análisis más profundo.

En nuestro caso vamos a ver la gráfica de número de llamadas a BBDD:

 

El problema se aprecia en un vistazo: incremento de llamadas concurrentes a la BBDD.

Tras ver esto decidimos añadir esta gráfica al dashboard de nuestra aplicación, de esta manera podemos tener bajo el ojo el problema recién descubierto.  Otras formas de estar al tanto es marcar esta transacción como key transaction, de esta manera podremos seguir de cerca y analizar más profundamente:

 

Es un overview pero solo de esa transacción con lo cual se puede aislar la parte que queremos estudiar e incluso comparar los datos con los de días anteriores.

Por ultimo podemos usar estas métricas para configurar alertas y que New Relic nos avise en caso de ocurrir de nuevo.

Para terminar comentar que lo aquí explicado es la punta del iceberg, me he dejado en el tintero apartados como la pantalla de database, el análisis de errores, los reports…  pero esto va ya muy largo,  seguiremos contando nuestras experiencias y aprendizaje en próximos post.

About María Angeles Gil

Cloud Technical Manager. Mª Ángeles studied a Bachelor’s Degree in Physical Science at Complutense University, and she has these certifications: BEA 8.1 Certified Administrator. System Administration; Puppet Certified Professional and Mirantis Certified Administrator for Openstack – Professional Level. She has worked as Developer, Java & JEE system admin, App Server Admin, Middleware team leader, JEE system admin & Devops eng, Puppet Deployment Eng, Technical Consultant - Web services, and finally as Cloud Technical Manager at Enimbos, which joined in 2017.