Debug en producción con OverOps

En este post (escrito por Andrei Guchín, de Abstracta, ¡gracias por compartir!) te contamos un poco para qué sirve la herramienta OverOps (quizá conocías a Takipi por su blog sobre performance de aplicaciones Java). En resumen, se puede hacer debug en producción con OverOps, pudiendo ver el código y el valor de las variables para las excepciones lanzadas, tanto las capturadas como las no capturadas. La herramienta la conocí cuando estuve en la Velocity Conf, en junio, y recién en estos días tuvimos la chance de probarla más a fondo.


OverOps es una herramienta que captura errores y excepciones en cualquier aplicación que funcione sobre la Java Virtual Machine, como Java, Scala, Closure, etc., (piensan agregar más lenguajes en el futuro, a fin de año estará listo para .NET) y registra información que facilita la reproducción y solución del problema (entre otras cosas, registra la línea de código donde se reproduce el error, los valores que tenían las variables y atributos en ese momento, etc.).

Este video de dos minutos muestra un resumen de lo que hace la herramienta:

Instalación de OverOps

Varía dependiendo de cada sistema operativo, pero en general es bastante fácil. Hay que hacerse una cuenta en el sitio de OverOps y seguir los pasos de la instalación.

Por ejemplo, para Windows:

  1. Se baja el instalador (un ejecutable) y se instala bastante rápido, hay que poner una secret key para linkear el server de OverOps con la máquina donde se aloja la aplicación a monitorizar.
  2. Conectar la JVM. Para eso hay que agregar “-agentlib:TakipiAgent” a los argumentos de Java al levantar la aplicación.

Luego de realizar estos dos pasos debería quedar funcionando la herramienta. En la ventana de instalación de la herramienta (en el paso 2) hay un botón para verificar la conectividad de OverOps con la aplicación a monitorizar.

Si después de realizar estos pasos aún no funciona, revisar si la JVM tomó el argumento -agentlib:TakipiAgent al levantar (con JConsole por ejemplo o línea de comandos) o ver que haya quedado instalado el programa descargado.

 

Monitorización con OverOps

La página principal de la herramienta presenta una grilla donde se muestran todas las excepciones registradas hasta el momento, agrupando todas la veces que ocurre la misma excepción en un solo elemento. Se pueden ordenar según varios criterios, los más útiles son:

  • Cantidad de veces que ocurrió el error
  • Porcentaje de error frente a la cantidad total de llamadas de ese código

También se pueden agrupar los errores según:

  • El server
  • La aplicación
  • El deployment realizado

Si se ingresa a uno de los errores en particular, se puede ver información útil para corregirlos, entre la que se encuentra:

  • El call stack donde se muestra la traza de métodos ejecutados hasta llegar al error.
  • El código ejecutado. En particular se destaca la línea donde ocurre el error.
  • El estado y el valor de las variables en el momento del error.
  • Estado de la JVM (memoria, threads, etc.).
  • Las últimas líneas del output log, que seguramente estarán relacionadas con lo que sucedió.

 

Lo interesante también es que permite generar alertas para los desarrolladores.

 

¿Se puede usar en producción?

Es importante destacar que todo esto lo hace con bajo costo, no es intrusiva, entonces se puede tener en producción. Ellos aseguran que no agrega más de un 1% de overhead. En caso que detecte que va a consumir más, cancela el almacenamiento de la información.

La herramienta es similar a Intellitrace de Microsoft, pero con un mecanismo más eficiente para la instrumentación. El problema de Intellitrace queda planteado en lo que dice este post:

With either plan, we recommend that you start IntelliTrace data collection, reproduce the problem, and then stop collection. You can take resulting log that IntelliTrace creates, open it in Visual Studio 11 Ultimate, and analyze it.

O sea, recomiendan solo activarlo para obtener los datos para analizar luego en Visual Studio. OverOps en cambio sí está pensado para producción, pudiendo analizar los problemas en la consola web (no es necesario hacer el análisis en un IDE de desarrollo).

 

Conclusión para testers

Es una herramienta de monitorización interesante, diferente a las que estamos acostumbrados a usar en pruebas de performance y que puede aportar valor en proyectos en donde haya que solucionar alguna emergencia en producción. Al tener la información de estado de las variables relacionadas al problema, la necesidad de reproducir se reduce y pueden resolverse errores directamente del código.

Si bien para aprovecharla al máximo debe ser utilizada en conjunto con desarrolladores, ya que la información más relevante refiere al código de la aplicación, creo que es una forma más de involucrar al tester en tareas cercanas al código, lo cual está asociado a lo que hablábamos del rol del Quality EngineerTambién podría ser muy útil en la etapa de testing para corregir bugs funcionales.

Si la quieres probar, podemos dar una mano e incluso contactarte con el equipo de OverOps.

Leave a Reply

Your email address will not be published. Required fields are marked *