Bueno, al final he tardado un poco más de lo que pensaba en sacar algo de tiempo para poner una segunda parte del anterior "post" sobre eventos y monitorización de aplicaciones (y ahora no es que tenga mucho tiempo tampoco), pero es que con el lanzamiento del "Pack Certificación" he estado realmente liado...

Bien, sigamos...

Para configurar elementos de notificación en nuestra aplicación Web ASP.NET 2.0, sólo tenemos que incluir algunos parámetros en el archivo de configuración de la misma, bajo el nodo <healthMonitoring>.

De hecho ASP.NET 2.0 ya viene con algunos de ellos preconfigurados y funcionando. Por ejemplo, todos los errores no gestionados que se produzcan en la aplicación quedan automáticamente guardados en el registrode eventos del sistema, sin que tengamos que hacer nada especial:

Esto es de extrema utilidad porque en caso de producirse un error en la aplicación que no hayamos controlado no tenemos que preocuparnos de pedirle a los usuarios que nos guarden los detalles de lo que ocurreió, como en qué página estaban, qué hacían o qué mensaje de error se produjo (en caso de mostrarlo, cosa que tampoco debiéramos). Basta con comprobar el registro de vez en cuando y ver qué errores se están produciendo. En la ventana como la del ejemplo tendremos todo tipo de detalles del error: petición que se había hecho, tipo de error, nivel de confianza de seguridad, proceso que falló, usuario que se estaba suplantando, si estaba autenticado en Membership o no, dirección IP, traza de la pila, etc... Es decir, todo lo que necesitamos para determinar con cierto éxito el origen del error.

¿Cómo elegimos qué eventos se van a notificar y cómo lo harán?

Como ya he comentado para configurar qué eventos queremos sólo tenemos que incluir en nuestro web.config los ajustes necesarios para ello dentro del nodo <healthMonitoring>.

Ello implica la definición de diversos sub-nodos, algunos de los cuales son opcionales y otros no. Dado que en el archivo web.config global de ASP.NET 2.0 ya vienen incluidas las definiciones de diversos tipos de eventos, no será necesario en la mayor parte de los casos que nosotros los re-definamos. Se incluyen "de serie" los siguientes:

<eventMappings>
  <add name="All Events" type="System.Web.Management.WebBaseEvent, ..." />
  <add name="HeartBeats"
    type="System.Web.Management.WebHeartBeatEvent, ..." />
  <add name="Application Lifetime Events"
    type="System.Web.Management.WebApplicationLifetimeEvent, ..." />
  <add name="Request Processing Events"
    type="System.Web.Management.WebRequestEvent, ..." />
  <add name="All Errors"
    type="System.Web.Management.WebBaseErrorEvent, ..." />
  <add name="Infrastructure Errors"
    type="System.Web.Management.WebErrorEvent, ..." />
  <add name="Request Processing Errors"
    type="System.Web.Management.WebRequestErrorEvent, ..." />
  <add name="All Audits" type="System.Web.Management.WebAuditEvent, ..." />
  <add name="Failure Audits"
    type="System.Web.Management.WebFailureAuditEvent, ..." />
  <add name="Success Audits"
    type="System.Web.Management.WebSuccessAuditEvent, ..." />
</eventMappings>

Es decir, hay una definición ya hecha para todos los tipos de eventos (los que hereden de WebBaseEvent, o sea todos), "latidos" de la aplicación, ciclo de vida de ésta (inicio y fin, reciclajes...), peticiones de recursos, errores, etc... Si definiésemos nuestra propia clase de evento específica podríamos crear una entrada en nuestro web.config análoga a estas para definir el evento.

Además de los propios eventos en el archivo de configuración hay también un área para los proveedores que gestionan los eventos. En concreto los que están defnidos por defecto son estos:

<providers>
 <add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider,System.Web..." />
 <add connectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823"
    buffer="false" bufferMode="Notification" name="SqlWebEventProvider"
   type="System.Web.Management.SqlWebEventProvider,System.Web,..." />
 <add name="WmiWebEventProvider" type="System.Web.Management.WmiWebEventProvider,System.Web,..." />
</providers>

Esto, al igual que lo anterior, está copiado y pegado del web.config global.

Como vemos se definen gestores de eventos que los anotan en el registro de sucesos del sistema, en una base de datos SQL Server o en el sistema de instrumentación de Windows (WMI).

Podemos agregar otros tipos de gestores de eventos. Por ejemplo, si añadimos este nodo:

<providers>
   <add name="Proveedor_eMail" type="System.Web.Management.Simple-mailWebEventProvider"
     to="
[email protected]" from="[email protected]" maxMessagesPerNotification="1" maxEventsPerMessage="10"
     buffer="true" bufferMode="Critical Notification" subjectPrefix="Web Events"/>
</providers>

De este modo estamos definiendo que queremos usar el proveedor de correo simple que ofrece ASP.NET 2.0 (hay otro más avanzado que nos permite definir cuál será el aspecto y contenido de los mensajes enviados). Le indicamos a qué direcci´no deben llegar las notificaciones, desde qué dirección se envían, cuántos eventos se notificarán por cada mensaje y otra serie de parámetros más avanzados que no voy a tocar ahora.

Ahora definamos las reglas

Bien, una vez que tenemos definidos los eventos que se pueden producir así como los posibles gestores de los mismos, lo único que nos hace falta es definir de qué manera se gestionarán. Para ello empleamos las reglas de notificación. Éstas se definen también con nodos en web.config, dentro de la misma sección, y simplemente relacionan los eventos que tengamos definidos con los gestores/proveedores de esos eventos.

Así, por ejemplo, si queremos que todos los errores no gestionados que se produzcan nos lleguen por correo electrónico de manera automática podemos escribir lo siguiente:

<rules>
    <add name="Todos los errores por e-mail" eventName="All Errors" provider="Proveedor_eMail"/>
</rules>

Esta es la forma más sencilla de definirla. Si nos fijamos lo único que se hace es otorgarle un nombre e indicar el nombre del tipo de eventos que queremos gestionar (en este caso uno de los que vienen por defecto en ASP.NET) y el nombre del proveedor que se quiere usar para gestionarlo (en este caso el que hemos definido manualmente).

Cuestiones más avanzadas

Esta es la punta del iceberg. Se pueden controlar muchos más aspectos a la hora de definir las reglas, como por ejemplo con qué frecuencia queremos que nos lleguen esos mensajes, cuántos eventos queremos que se nos notifiquen (uno de cada 10, como máximo uno cada 5 minutos, etc...), si queremos que se nos notifique sólo cuando se junten, por ejemplo, 5 de eventos deun tipo determinado, per no de uno en uno, y otros muchos aspectos interesantes que evitan que se saturen los recursos de la aplicación, nuestra base de datos o, en el caso del ejemplo, nuestra ya de por si colapsada bandeja de entrada.

Además existe la posibilidad de definir perfiles de comportamiento para las reglas de forma que, en lugar de ir estableciendo muchos parámetros en cada una se le indica qué perfil queremos usar y así se reutilizan éstos entre diversas reglas, lo cual puede resultar muy útil.

en fin, que el sistema de monitorización automática es un mundo en si mismo, y además muy interesante.

Mi intención al escribir este par de 'post's era presentar brevemente el tema y dar unas ideas generales, así como alguna recetilla (como la de notificar por correo electrónico) que los lectores podáis usar de inmediato. El analizar en profundidad todo lo que contiene el sistema de monitorización de ASP.NET 2.0 se sale de lo que me permite el tiempo hoy (y las ganas, la verdad). Tengo intención de escribir un artículo pronto que profundice en todos estos temas, enseñe a crear proveedores propios, etc.. y que saldría publicado en dotNetMania dentro de poco. Si tienes interés en el tema permanece atento y verás lo que da de si este interesante tema.

 

💪🏻 ¿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

Escrito por un humano, no por una IA