Este tema siempre me ha encantado: la monitorización de tus aplicaciones para ver si se están comportando como es debido o no.

Esto en su sentido más amplio incluye todo tipo de información: desde contadores de operaciones y rendimiento personalizados hasta gestión automática de notificaciones ante ciertos sucesos y registro de todo lo importante que haya.

MonitorizaciónLa API de ASP 3.0 que usábamos en Krasis ya tenía integrado un sistema de Log automático y explotación del mismo, así como algunas utilidades para gestionar errores de forma automática. En .NET la cosa mejora mucho porque podemos crear contadores de rendimiento personalizados y crear facilmente entradas en el registro de sucesos del sistema.

En ASP.NET 2.0 los chicos de Microsoft se han superado también en este aspecto introduciendo lo que se ha dado en llamar "ASP.NET 2.0 Health Monitoring" o lo que yo llamaría en castellano a falta de una traducción mejor "Servicios de notificación y registro de ASP.NET 2.0".

El sistema ofrece, por un lado, una jerarquía de clases de notificación de eventos y por otro un sistema de proveedores de captura y registro de dichos eventos. Todo esto nos permite obtener muchísima información y estar al día de ella sin necesidad de escribir código.

Notificación de eventos

El sistema de notificación de eventos notifica automáticamente de cuestiones como arranques y paradas de la aplicación, logins fallidos de usuarios, errores de compilación o de configuración, excepciones no gestionadas, etc... Para cada uno de estos eventos hay una clase específica derivada de WebBaseEvent que nos informa de los datos concretos del evento (como por ejemplo el motivo de un error o un reinicio, o los datos de un login fallido).

Lo mejor de todo es que podemos crear nuestros propios eventos creando una clases derivada de la clase mencionada, y así los gestionaremos del modo común, en igualdad de condiciones con los de ASP.NET.

Para notificar un evento "a mano" sólo hay que instanciar la clase apropiada y llamar a su método Raise, que todas ellas poseen.

Registro de eventos

Vale, ya hemos visto que hay eventos, que podemos crear eventos propios y que se pueden lanzar con Raise. ¿Y ahora qué? Pues de poco nos servirá lanzarlos si no los gestionamos de algún modo. Para ello disponemos del sistema de captura y registro de eventos. Éste se basa, como todo en ASP.NET 2.0, en una arquitectura de proveedores que permite aislar la gestión del evento del medio con el que se gestiona. Así, existen de serie algunos proveedores que ya hacen la mayor parte de las cosas que podemos necesitar: un proveedor para enviar por e-mail notificaciones, otro para anotar los eventos generados en una base de datos de SQL Server, otro para anotar en el registro de sucesos del sistema, otro para exponerlos a la instrumentación de Windows (WMI), e incluso uno para mostrarlos en la traza de la página si ésta se encuentra activada (útil para depurar).

Por supuesto podemos crear nuestro propio proveedor de gestor de eventos para hacer lo que necesitemos (por ejemplo que lo anote en un simple archivo de texto con ciertos datos o que lo envíe a una cola de mensajería MSMQ, o lo que sea...).

Se pueden combinar varios proveedores para que gestionen un mismo evento o eventos, de modo que podemos hacer por ejemplo que los anoten en SQL Server y que nos manden un e-mail al mismo tiempo.

También existen reglas de monitorización que definen qué eventos se gestionan y en qué condiciones.

Mañana más...

Uff!, últimamente se me da por escribir de temas más bien largos y siempre necesito varias partes. Mañana tengo intención de continuar con esto y explicar cómo se usa en la práctica todo esto que acabo de contar. ¡Sigue sintonizado!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor