Flux XMLLe HealthMonitoring d'ASP.NET 2.0
Par amethyste le Mar 24, 2007 | Dans focus | 3 retours »
Présentation de HealthMonitoring
ASP.NET 2.0 s'est accompagné d'une avalanche de nouveautés. Je connaissais le HealthMonitoring depuis un moment, mais ce n'est que cette semaine que j'ai eu l'occasion de l'explorer un peu plus en détails.
Un blog est un cadre trop restreint pour faire le tour de la question, mais je peux au moins essayer de vous faire découvrir quelque chose de nouveau et vous donner l'envie d'aller y regarder de près.
HealthMonitoring ne vous dit peut être rien, mais en fait votre application l'implémente déjà en silence.
Faites l'expérience suivant:
<html xmlns="http://www.w3.org/1999/xhtml" > <body> <form id="form1" runat="server"> <div> <asp:button ID="Button1" runat="server" OnClick="Button1_Click" Text="Button" /> </div> </form> </body> </html>
Côté code behind:
protected void Button1_Click(object sender, EventArgs e) { throw new ApplicationException("une grosse erreur"); }
Lancez donc l'application, cliquez sur le bouton, le fameux écran jaune qui signale une exception non interceptée s'affiche. Courrez ensuite vers l'observateur d'événements.
Un avertissement lancé par ASP vous y attend. Il contient toute une quantité d'informations sur la nature de l'exception.
Complétez maintenant le fichier de configuration avec les lignes suivantes dans la section <system.web>:
<healthMonitoring enabled="false">
Recommencez l'expérience, cette fois rien de particulier n'apparaît dans l'observateur d'événements.
C'est cela HealthMonitoring. Un mécanisme qui va en silence surveiller votre application et loguer divers événements.
ASP est livré avec une série d'événements standards, il s'agit de classes qui héritent de WebBaseEvent. Rien ne vous interdit donc de développer les vôtre ou de puiser dans ceux existants.
Vous pouvez ainsi loguer les événements système de l'application (démarrage, arrêt…), les exceptions non interceptées, l'échec ou le succès d'une tentative de connexion, un signal périodique émis par l'application (chien de garde)…
La beauté de ce mécanisme est qu'il est hautement paramétrable entièrement depuis le fichier de configuration. Pas une ligne de code n'apparaît dans l'application.
Mise en oeuvre
HealthMonitoring est piloté depuis la section <healthMonitoring> du fichier de configuration.
Tout comme machine.config depuis ASP 1.X, ASP 2.0 fournit maintenant un fichier de configuration web.config par défaut au niveau machine dans lequel vous pourrez lire les valeurs par défaut retenues pour <healthMonitoring>.
Vous pouvez évidemment les surclasser dans votre application en redéfinissant une des 5 sous sections suivantes:
<bufferModes>
<providers>
<eventMappings>
<rules>
<profiles>
Providers associe un nom convivial à un conteneur qui enregistre l'événement. On a vu le cas de l'observateur d'événement, citons aussi le mail, une base de données, WMI, le fichier de trace ASP, ou un fournisseur personnalisé.
Le fichier par défaut expose:
<providers> <add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" /> <add connectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823" buffer="false" bufferMode="Notification" name="SqlWebEventProvider" type="System.Web.Management.SqlWebEventProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" /> <add name="WmiWebEventProvider" type="System.Web.Management.WmiWebEventProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" /> </providers>
On définit par exemple l'observateur d'événement comme le fournisseur EventLogProvider.
EventMappings associe lui aussi un nom convivial, mais à un événement.
<eventMappings> <clear /> <add name="All Errors" type="System.Web.Management.WebBaseErrorEvent" startEventCode="0" endEventCode="2147483647" /> </eventMappings>
L'événement dont il est question est les erreurs non interceptées dont le code est compris entre 0 et 2147483647.
On fait quoi avec nos noms conviviaux? On les associe!
C'est le boulot de <rules>:
<rules> <clear /> <add name="All Errors Default" eventName="All Errors" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" /> </rules>
Vous pouvez donc avoir des conteneurs différents selon la nature de l'événement.
Evidemment loguer massivement des événements cela peut avoir un coût et donc fragiliser votre site face à une attaque par déni de service.
HealthMonitoring offre tout de même des gardes fous.
Par exemple minInterval définit la durée minimale entre deux événements pour être logués.
minInstances demande que l'événement surveillé se produise au moins un certain nombre de fois pour être logué. On peut aussi placer un plafond avec maxLimit. Pourquoi maxLimit plutôt que maxInstances? Je ne sais pas, probablement pour faire une question dans un examen…
Ces paramètres peuvent également être déclarés dans une section <profiles>.
Une autre sécurité est que vous pouvez mettre dans un tampon les logs avant de les enregistrer effectivement. C'est le rôle dédié à <bufferModes>:
<bufferModes> <add name="Critical Notification" maxBufferSize="100" maxFlushSize="20" urgentFlushThreshold="1" regularFlushInterval="Infinite" urgentFlushInterval="00:01:00" maxBufferThreads="1" /> <add name="Notification" maxBufferSize="300" maxFlushSize="20" urgentFlushThreshold="1" regularFlushInterval="Infinite" urgentFlushInterval="00:01:00" maxBufferThreads="1" /> </bufferModes>
Vous pouvez définir le nombre d'événements dans le tampon (maxBufferSize), l'intervalle de temps par vidage (regularFlushInterval), le seuil qui déclenche le vidage (urgentFlushThreshHold), la durée minimale entre deux vidages (urgentFlushInterval)…
Comme toujours, name est le nom convivial donné au jeu de paramètre. Ce nom est reporté dans l'attribut bufferMode de la déclaration du fournisseur (notez aussi l'attribut buffer qui active/désactive la mise en tampon).
J'ai fais une (rapide) inspection du code de HealthMonitoring avec Reflector.
Le point intéressant est qu'en fait HealthMonitoring semble être une façade pour les compteurs de performance livrés avec ASP. La différence est qu'il offre une interface plus conviviale que Perfmon pour les mettre en œuvre et afficher les informations de suivit.
Bibliographie
• Une FAQ d'Eric Reitan:
http://blogs.msdn.com/erikreitan/archive/2006/05/22/603586.aspx
• Un excellent tutoriel de manuel Abadia:
http://www.manuelabadia.com/blog/PermaLink,guid,77dd4e93-e052-4b65-9b9d-81a17f0e2b6e.aspx
• Un tout aussi excellent tutoriel de Scott Mitchel. Il est en fait en cours d'écriture, à la date de rédaction de ce blog on en était à 2 parties:
http://aspnet.4guysfromrolla.com/articles/031407-1.aspx
3 commentaires
Merci pour le tip !
Laisser un commentaire
| « Evénements ASP: un petit quizz | Débogage sous Vista » |
