Realidad IT

Poder capturar las alarmas de nuestras aplicaciones desde una herramienta de soporte

Uno de los problemas típicos de los desarrolladores es qué hacer cuando algo no anda bien con nuestra aplicación que está corriendo en producción, todos aprendimos a usar el famoso try-catch, algunos mas expertos hasta aprendieron a usar el try-catch-finally, pero la pregunta es ¿dónde van a parar estas alarmas?. Muchas veces terminan en un log que nadie mira hasta que se llena el disco o la otra alternativa es hacer spam a alguna casilla de mail del personal de soporte que seguramente ya puso una regla en su lector de correos para que no le ensucie la bandeja de entrada.
Una muy buena práctica que suelo utilizar frente a dicha situación es incorporar en el código una clase que se ocupe del logueo pero que permita configurar la salida dinámicamente, lo cual permite que no tengamos que recompilar cada vez que queremos hacer un cambio de donde queremos guardar la información de logueo. En .NET particularmente el componente mas famoso es Log4Net (de Apache Fundation), también está para que puedan elegir NLOG que no es de una empresa tan reconocida en el medio pero tiene características muy potentes.

El siguiente paso es armar bien la estructura de try-catch, lo mas importante es que solo la clase de nivel superior llame al objeto de Log4Net para generar la salida, y que los try-catch de las clases mas bajas en el stack de llamados eleven una excepción mas detallada del problema a la clase superior, como pueden ver en el ejemplo.

Ejemplo:

//clase superior
try
{
     subclass.dosomething();
}
catch(MyException ex)
{
     Logger.Error(ex);
}
catch(Exception ex)
{
     Logger.Error(ex);
}

//subclass - Method dosomething()
try
{
     Todo.Something();
}
catch(Exception ex)
{
     throw new MyException("estamos en el horno", ex);
}

Luego hay que elegir bien que hacer con cada alarma, si usan Log4Net tienen 5 niveles de logueo:

• Debug: Usarlo para todo lo que necesita un programador para buscar un bug escondido.
• Informacion: Usarlo como log de transaccion del servicio/aplicacion.
• Advertencias: Usarlo cuando ocurrio un error pero que el servicio puede seguir, por ejemplo, suspender esa tarea y seguir con otro tema.
• Error: Cuando el error no te deja seguir hasta que se solucione.
• Fatal: Errores de memoria, cosas realmente feas.

Como dije, cada uno de estos niveles de error por archivo de configuracion puedo decir si se loguean o no, también puedo decir a donde va a parar el log, en el caso de Log4Net  pueden ir a parar a los siguientes lugares:

• Archivo de file system
• DB
• Mail
• Consola
• Event Log: El que se lee con el Event Viewer de Windows
• Syslog: Mensajes de registros de entornos Linux/Unix
• Telnet
• Trace System
• A una memoria compartida

Nagios: Vista táctica de los servicios que se estan monitoreando

Y si no te alcanza podes crear tu propio lugar de logueo (tenes que crear lo que le llaman un Appender).

Ok, ya sabemos como disparar alarmas y a donde dirigirlas.
Ahora lo interesante es poder capturarlo con alguna herramienta de soporte.
En mi caso utilizo una herramienta que corre en Linux conocida en el mercado como Nagios, que recibe eventos de todos los equipos y dispara alarmas al personal adecuado para tratar el problema a tiempo.

Por lo tanto mi configuracion de logueo en produccion quedaría como la que detallo a continuacion:

• Debug: En produccion deshabilitado!
• Informacion: Lo guardo en archivo de file system
• Advertencias: Lo guardo en Syslog
• Error: Syslog
• Fatal: Syslog

En mi server  Linux activo el Syslog para recibir eventos externos (ojo, conviene limitar el acceso desde algun firewall ya que si está publicado en internet pueden recibir muchos eventos maliciosos que generen deny of service en el equipo).  Y por último configuran el Nagios que para cada tipo de error dispare una alarma diferente.

Este artículo no pretende ser un paso a paso de como realizar este tipo de configuración sino entender conceptualmente como organizar nuestros desarrollos para que pueda integrarse a la estructura de operaciones de la organización.

Espero sus comentarios!
Santiago