Partager via

Journalisation des détails des erreurs avec ELMAH (VB)

  • Article

par Scott Mitchell

Les modules et gestionnaires de journalisation des erreurs (ELMAH) offrent une autre approche de la journalisation des erreurs d’exécution dans un environnement de production. ELMAH est une bibliothèque de journalisation des erreurs gratuite open source qui comprend des fonctionnalités telles que le filtrage des erreurs et la possibilité d’afficher le journal des erreurs à partir d’une page web, en tant que flux RSS, ou de le télécharger en tant que fichier délimité par des virgules. Ce tutoriel décrit le téléchargement et la configuration d’ELMAH.

Introduction

Le tutoriel précédent a examiné ASP. Le système de surveillance de l’intégrité de NET, qui offre une bibliothèque prête à l’emploi pour l’enregistrement d’un large éventail d’événements web. De nombreux développeurs utilisent la surveillance de l’intégrité pour consigner et envoyer par e-mail les détails des exceptions non gérées. Toutefois, ce système présente quelques difficultés. Tout d’abord, il n’y a pas d’interface utilisateur pour afficher les informations sur les événements journalisés. Si vous souhaitez afficher un résumé des 10 dernières erreurs ou afficher les détails d’une erreur qui s’est produite la semaine dernière, vous devez soit parcourir la base de données, analyser votre boîte de réception de courrier, soit créer une page web qui affiche des informations à partir de la aspnet_WebEvent_Events table.

Un autre point douloureux est lié à la complexité de la surveillance de l’intégrité. Étant donné que la surveillance de l’intégrité peut être utilisée pour enregistrer une pléthore d’événements différents et qu’il existe diverses options pour indiquer comment et quand les événements sont consignés, la configuration correcte du système de surveillance de l’intégrité peut s’avérer une tâche coûteuse. Enfin, il existe des problèmes de compatibilité. Étant donné que la surveillance de l’intégrité a été ajoutée au .NET Framework dans la version 2.0, elle n’est pas disponible pour les applications web plus anciennes créées à l’aide de ASP.NET version 1.x. De plus, la SqlWebEventProvider classe, que nous avons utilisée dans le tutoriel précédent pour enregistrer les détails des erreurs dans une base de données, fonctionne uniquement avec les bases de données Microsoft SQL Server. Vous devez créer une classe de fournisseur de journaux personnalisé si vous devez consigner les erreurs dans un autre magasin de données, tel qu’un fichier XML ou une base de données Oracle.

Une alternative au système de surveillance de l’intégrité est le système ELMAH (Error Logging Modules And Handlers), un système gratuit et open source de journalisation des erreurs créé par Atif Aziz. La différence la plus notable entre les deux systèmes est la capacité d’ELAMH à afficher une liste d’erreurs et les détails d’une erreur spécifique à partir d’une page web et sous la forme d’un flux RSS. ELMAH est plus facile à configurer que la surveillance de l’intégrité, car il ne consigne que les erreurs. En outre, ELMAH prend en charge les applications ASP.NET 1.x, ASP.NET 2.0 et ASP.NET 3.5, et est fourni avec divers fournisseurs de sources de journaux.

Ce tutoriel décrit les étapes de l’ajout d’ELMAH à une application ASP.NET. C’est parti !

Notes

Le système de surveillance de l’intégrité et ELMAH ont tous deux leurs propres ensembles d’avantages et de inconvénients. Je vous encourage à essayer les deux systèmes et à choisir celui qui correspond le mieux à vos besoins.

Ajout d’ELMAH à une application web ASP.NET

L’intégration d’ELMAH à une application ASP.NET nouvelle ou existante est un processus simple et simple qui prend moins de cinq minutes. En résumé, il s’agit de quatre étapes simples :

  1. Téléchargez ELMAH et ajoutez l’assembly Elmah.dll à votre application web,
  2. Inscrire le gestionnaire et les modules HTTP d’ELMAH dans Web.config,
  3. Spécifiez les options de configuration d’ELMAH, et
  4. Créez l’infrastructure source du journal des erreurs, si nécessaire.

Passons à travers chacune de ces quatre étapes, une à la fois.

Étape 1 : Téléchargement des fichiers projet ELMAH et ajoutElmah.dllà votre application web

ELMAH 1.0 BETA 3 (build 10617), la version la plus récente au moment de la rédaction de cet article, est inclus dans le téléchargement disponible avec ce tutoriel. Vous pouvez également visiter le site web ELMAH pour obtenir la version la plus récente ou pour télécharger le code source. Extrayez le téléchargement ELMAH dans un dossier sur votre bureau et recherchez le fichier d’assembly ELMAH (Elmah.dll).

Notes

Le Elmah.dll fichier se trouve dans le dossier du Bin téléchargement, qui contient des sous-dossiers pour différentes versions du .NET Framework et pour les builds Release et Debug. Utilisez la build Release pour la version d’infrastructure appropriée. Par instance, si vous créez une application web ASP.NET 3.5, copiez le Elmah.dll fichier à partir du Bin\net-3.5\Release dossier.

Ensuite, ouvrez Visual Studio et ajoutez l’assembly à votre projet en cliquant avec le bouton droit sur le nom du site web dans le Explorateur de solutions et en choisissant Ajouter une référence dans le menu contextuel. La boîte de dialogue Ajouter une référence s’affiche. Accédez à l’onglet Parcourir et choisissez le Elmah.dll fichier. Cette action ajoute le Elmah.dll fichier au dossier de Bin l’application web.

Notes

Le type Projet d’application web (WAP) n’affiche pas le Bin dossier dans le Explorateur de solutions. Au lieu de cela, il répertorie ces éléments sous le dossier Références.

L’assembly Elmah.dll inclut les classes utilisées par le système ELMAH. Ces classes appartiennent à l’une des trois catégories suivantes :

  • Modules HTTP : un module HTTP est une classe qui définit les gestionnaires d’événements pour HttpApplication les événements, tels que l’événement Error . ELMAH comprend plusieurs modules HTTP, les trois les plus germaniques étant :

    • ErrorLogModule - journalise les exceptions non gérées d’une source de journal.
    • ErrorMailModule - envoie les détails d’une exception non prise en charge dans un e-mail.
    • ErrorFilterModule - applique des filtres spécifiés par le développeur pour déterminer quelles exceptions sont enregistrées et celles qui sont ignorées.

  • Gestionnaires HTTP : un gestionnaire HTTP est une classe chargée de générer le balisage pour un type particulier de requête. ELMAH inclut des gestionnaires HTTP qui affichent les détails de l’erreur sous la forme d’une page web, d’un flux RSS ou d’un fichier délimité par des virgules (CSV).

  • Sources du journal des erreurs : ELMAH peut enregistrer les erreurs en mémoire, dans une base de données Microsoft SQL Server, dans une base de données Microsoft Access, dans une base de données Oracle, dans un fichier XML, dans une base de données SQLite ou dans une base de données Vista DB. Comme le système de surveillance de l’intégrité, l’architecture d’ELMAH a été créée à l’aide du modèle de fournisseur, ce qui signifie que vous pouvez créer et intégrer en toute transparence vos propres fournisseurs de sources de journaux personnalisés, si nécessaire.

Étape 2 : Inscription du module ET du gestionnaire HTTP d’ELMAH

Bien que le Elmah.dll fichier contienne les modules HTTP et le gestionnaire nécessaires pour enregistrer automatiquement les exceptions non gérées et afficher les détails d’erreur à partir d’une page web, ceux-ci doivent être inscrits explicitement dans la configuration de l’application web. Une ErrorLogModule fois inscrit, le module HTTP s’abonne à l’événement HttpApplicationde Error . Chaque fois que cet événement est déclenché, le ErrorLogModule journalise les détails de l’exception dans une source de journal spécifiée. Nous verrons comment définir le fournisseur de source de journaux dans la section suivante, « Configuration d’ELMAH ». La ErrorLogPageFactory fabrique du gestionnaire HTTP est responsable de la génération du balisage lors de l’affichage du journal des erreurs à partir d’une page web.

La syntaxe spécifique pour l’inscription des modules et gestionnaires HTTP dépend du serveur web qui alimente le site. Pour le serveur de développement ASP.NET et les versions IIS 6.0 et antérieures de Microsoft, les modules et gestionnaires HTTP sont inscrits dans les <httpModules> sections et <httpHandlers> , qui s’affichent dans l’élément <system.web> . Si vous utilisez IIS 7.0, ils doivent être inscrits dans les sections et <handlers> de l’élément.<modules><system.webServer> Heureusement, vous pouvez définir les modules et gestionnaires HTTP aux deux emplacements, quel que soit le serveur web utilisé. Cette option est la plus portable, car elle permet d’utiliser la même configuration dans les environnements de développement et de production, quel que soit le serveur web utilisé.

Commencez par inscrire le ErrorLogModule module HTTP et le ErrorLogPageFactory gestionnaire HTTP dans la <httpModules> section et <httpHandlers> dans <system.web>. Si votre configuration définit déjà ces deux éléments, incluez simplement l’élément pour le <add> module HTTP et le gestionnaire d’ELMAH.

<?xml version="1.0"?>
<configuration>
  ...
  
  <system.web>
  ...

  <httpHandlers>
  ...

  <add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
  </httpHandlers>
  
  <httpModules>
  ...
  
  <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
  </httpModules>

  ...
  </system.web>

  ...
</configuration>

Ensuite, inscrivez le module HTTP et le gestionnaire d’ELMAH dans l’élément <system.webServer> . Comme précédemment, si cet élément n’est pas déjà présent dans votre configuration, ajoutez-le.

<?xml version="1.0"?>
<configuration>
  ...

  <system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  <modules>
  ...

  <add name="Elmah.ErrorLog" type="Elmah.ErrorLogModule, Elmah" preCondition="managedHandler" />
  </modules>
  <handlers>
  ...

  <add name="Elmah" path="elmah.axd" verb="POST,GET,HEAD" type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode" />
  </handlers>
  </system.webServer>
</configuration>

Par défaut, IIS 7 se plaint si les modules et gestionnaires HTTP sont inscrits dans la <system.web> section . L’attribut validateIntegratedModeConfiguration de l’élément <validation> indique à IIS 7 de supprimer ces messages d’erreur.

Notez que la syntaxe d’inscription du ErrorLogPageFactory gestionnaire HTTP inclut un path attribut, qui est défini sur elmah.axd. Cet attribut informe l’application web que si une demande arrive pour une page nommée elmah.axd , la demande doit être traitée par le ErrorLogPageFactory gestionnaire HTTP. Nous verrons le ErrorLogPageFactory gestionnaire HTTP en action plus loin dans ce tutoriel.

Étape 3 : Configuration d’ELMAH

ELMAH recherche ses options de configuration dans le fichier du Web.config site web dans une section de configuration personnalisée nommée <elmah>. Pour pouvoir utiliser une section personnalisée dans Web.config celle-ci, vous devez d’abord la définir dans l’élément <configSections> . Ouvrez le Web.config fichier et ajoutez le balisage suivant au <configSections>:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
  ...

  <sectionGroup name="elmah">
  <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah"/>
  <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
  <section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
  <section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah"/>
  </sectionGroup>
  </configSections>

  ...
</configuration>

Notes

Si vous configurez ELMAH pour une application ASP.NET 1.x, supprimez l’attribut requirePermission="false" des <section> éléments ci-dessus.

La syntaxe ci-dessus inscrit la section personnalisée <elmah> et ses sous-sections : <security>, <errorLog>, <errorMail>et <errorFilter>.

Ensuite, ajoutez la <elmah> section à Web.config. Cette section doit apparaître au même niveau que l’élément <system.web> . À l’intérieur de la <elmah> section, ajoutez les <security> sections et <errorLog> comme suit :

<?xml version="1.0"?>
<configuration>
  ...

  <elmah>
  <security allowRemoteAccess="0" />
  
  <errorLog type="Elmah.SqlErrorLog, Elmah" connectionStringName="ReviewsConnectionString" />
  </elmah>

  ...
</configuration>

L’attribut <security> de la allowRemoteAccess section indique si l’accès à distance est autorisé. Si cette valeur est définie sur 0, la page web du journal des erreurs ne peut être consultée que localement. Si cet attribut a la valeur 1, la page web du journal des erreurs est activée pour les visiteurs distants et locaux. Pour l’instant, nous allons désactiver la page web du journal des erreurs pour les visiteurs distants. Nous autoriserons l’accès à distance ultérieurement une fois que nous aurons l’occasion de discuter des problèmes de sécurité liés à cette opération.

La <errorLog> section définit la source du journal des erreurs, qui détermine où les détails de l’erreur sont enregistrés; elle est similaire à la <providers> section dans le système de surveillance de l’intégrité. La syntaxe ci-dessus spécifie la SqlErrorLog classe comme source du journal des erreurs, qui consigne les erreurs dans une base de données Microsoft SQL Server spécifiée par la valeur d’attributconnectionStringName.

Notes

ELMAH est fourni avec des fournisseurs de journaux d’erreurs supplémentaires qui peuvent être utilisés pour enregistrer les erreurs dans un fichier XML, une base de données Microsoft Access, une base de données Oracle et d’autres magasins de données. Reportez-vous à l’exemple Web.config de fichier inclus dans le téléchargement ELMAH pour plus d’informations sur l’utilisation de ces autres fournisseurs de journaux d’erreurs.

Étape 4 : Création de l’infrastructure source du journal des erreurs

Le fournisseur d’ELMAH SqlErrorLog consigne les détails de l’erreur dans une base de données Microsoft SQL Server spécifiée. Le SqlErrorLog fournisseur s’attend à ce que cette base de données dispose d’une table nommée ELMAH_Error et de trois procédures stockées : ELMAH_GetErrorsXml, ELMAH_GetErrorXmlet ELMAH_LogError. Le téléchargement ELMAH inclut un fichier nommé SQLServer.sql dans le db dossier qui contient le T-SQL pour la création de cette table et de ces procédures stockées. Vous devez exécuter ces instructions sur votre base de données pour utiliser le SqlErrorLog fournisseur.

Les figures 1 et 2 montrent l’Explorer de base de données dans Visual Studio après l’ajout des objets de base de données requis par le SqlErrorLog fournisseur.

Capture d’écran montrant la table d’erreurs ELMAH avec les erreurs de journal du fournisseur de journaux d’erreurs DU QD.

Figure 1 : Le SqlErrorLog fournisseur enregistre les erreurs dans la ELMAH_Error table

Capture d’écran montrant comment le fournisseur de journaux d’erreurs QD utilise trois procédures stockées.

Figure 2 : Le SqlErrorLog fournisseur utilise trois procédures stockées

ELMAH en action

À ce stade, nous avons ajouté ELMAH à l’application web, inscrit le ErrorLogModule module HTTP et le ErrorLogPageFactory gestionnaire HTTP, spécifié les options de configuration d’ELMAH dans Web.configet ajouté les objets de base de données nécessaires pour le fournisseur de SqlErrorLog journaux d’erreurs. Nous sommes maintenant prêts à voir ELMAH en action! Visitez le site web Book Reviews et visitez une page qui génère une erreur d’exécution, telle que Genre.aspx?ID=foo, ou une page inexistante, telle que NoSuchPage.aspx. Ce que vous voyez lorsque vous visitez ces pages dépend de la <customErrors> configuration et de votre visite locale ou à distance. (Reportez-vous au didacticiel Affichage d’une page d’erreur personnalisée pour une actualisation sur cette rubrique.)

ELMAH n’affecte pas le contenu affiché à l’utilisateur lorsqu’une exception non gérée se produit ; il enregistre simplement ses détails. Ce journal des erreurs est accessible à partir de la page elmah.axd web à partir de la racine de votre site web, par http://localhost/BookReviews/elmah.axdexemple . (Ce fichier n’existe pas physiquement dans votre projet, mais lorsqu’une demande est envoyée pour elmah.axd le runtime, il est distribué au ErrorLogPageFactory gestionnaire HTTP, qui génère le balisage renvoyé au navigateur.)

Notes

Vous pouvez également utiliser la elmah.axd page pour indiquer à ELMAH de générer une erreur de test. La visite elmah.axd/test (comme dans, http://localhost/BookReviews/elmah.axd/test) provoque la levée d’une exception de type Elmah.TestExceptionpar ELMAH, qui contient le message d’erreur : « Il s’agit d’une exception de test qui peut être ignorée en toute sécurité ».

La figure 3 montre le journal des erreurs lors de la visite elmah.axd à partir de l’environnement de développement.

Capture d’écran montrant le journal des erreurs à partir d’une page web.

Figure 3 : Elmah.axd Affiche le journal des erreurs à partir d’une page web
(Cliquez pour afficher l’image en taille réelle)

Le journal des erreurs de la figure 3 contient six entrées d’erreur. Chaque entrée inclut le code status HTTP (404 ou 500, pour ces erreurs), le type, la description, le nom de l’utilisateur connecté lorsque l’erreur s’est produite, ainsi que la date et l’heure. Le fait de cliquer sur le lien Détails affiche une page qui contient le même message d’erreur que celui affiché dans l’écran jaune détails de l’erreur de la mort (voir la figure 4) ainsi que les valeurs des variables serveur au moment de l’erreur (voir la figure 5). Vous pouvez également afficher le code XML brut dans lequel les détails de l’erreur sont enregistrés, qui inclut des informations supplémentaires telles que les valeurs de l’en-tête HTTP POST.

Capture d’écran montrant que vous pouvez afficher les détails de l’erreur SSO.

Figure 4 : Afficher les détails de l’erreur YSOD
(Cliquez pour afficher l’image en taille réelle)

Capture d’écran montrant comment explorer les valeurs de la collection de variables de serveur au moment de l’erreur.

Figure 5 : Explorer les valeurs de la collection de variables serveur au moment de l’erreur
(Cliquez pour afficher l’image en taille réelle)

Le déploiement d’ELMAH sur le site web de production implique :

  • Copie du fichier dans Elmah.dll le dossier en Bin production,
  • Copie des paramètres de configuration spécifiques à ELMAH dans le Web.config fichier utilisé en production, et
  • Ajout de l’infrastructure source du journal des erreurs à la base de données de production.

Nous avons exploré les techniques de copie de fichiers du développement vers la production dans les tutoriels précédents. Le moyen le plus simple d’obtenir l’infrastructure source du journal des erreurs sur la base de données de production consiste peut-être à utiliser SQL Server Management Studio pour se connecter à la base de données de production, puis exécuter le SqlServer.sql fichier de script, ce qui crée la table et les procédures stockées nécessaires.

Affichage de la page Détails de l’erreur en production

Après avoir déployé votre site en production, visitez le site web de production et générez une exception non gérée. Comme dans l’environnement de développement, ELMAH n’a aucun effet sur la page d’erreur affichée lorsqu’une exception non gérée se produit ; au lieu de cela, il enregistre simplement l’erreur. Si vous tentez de visiter la page du journal des erreurs (elmah.axd) à partir de l’environnement de production, vous serez accueilli avec la page Interdit présentée dans la figure 6.

Capture d’écran montrant comment, par défaut, les visiteurs distants ne peuvent pas afficher la page web du journal des erreurs.

Figure 6 : Par défaut, les visiteurs distants ne peuvent pas afficher la page web du journal des erreurs
(Cliquez pour afficher l’image en taille réelle)

Rappelez-vous que dans la section de <security> la configuration ELMAH, nous avons défini l’attribut allowRemoteAccess sur 0, ce qui empêche les utilisateurs distants d’afficher le journal des erreurs. Il est important d’interdire aux visiteurs anonymes d’afficher le journal des erreurs, car les détails de l’erreur peuvent révéler des failles de sécurité ou d’autres informations sensibles. Si vous décidez de définir cet attribut sur 1 et d’activer l’accès à distance au journal des erreurs, il est important de verrouiller le elmah.axd chemin afin que seuls les visiteurs autorisés puissent y accéder. Pour ce faire, ajoutez un <location> élément au Web.config fichier.

La configuration suivante permet uniquement aux utilisateurs du rôle Administration d’accéder à la page web du journal des erreurs :

<?xml version="1.0"?>
<configuration>
  ...

  <elmah>
  <security allowRemoteAccess="1" />
  
  ...
  </elmah>

  ...

  <location path="elmah.axd">
  <system.web>
  <authorization>
  <allow roles="Admin" />
  <deny users="*" />
  </authorization>
  </system.web>  
  </location>
</configuration>

Notes

Le rôle Administration et les trois utilisateurs du système (Scott, Jisun et Alice) ont été ajoutés dans le didacticiel Configuration d’un site web qui utilise des services d’application. Les utilisateurs Scott et Jisun sont membres du rôle Administration. Pour plus d’informations sur l’authentification et l’autorisation, reportez-vous aux didacticiels sur la sécurité de mon site web.

Le journal des erreurs dans l’environnement de production peut désormais être consulté par les utilisateurs distants ; Reportez-vous aux figures 3, 4 et 5 pour obtenir des captures d’écran de la page web du journal des erreurs. Toutefois, si un utilisateur anonyme ou non Administration tente d’afficher la page du journal des erreurs, il est automatiquement redirigé vers la page de connexion (Login.aspx), comme le montre la figure 7.

Capture d’écran montrant que les utilisateurs non autorisés sont automatiquement redirigés vers la page de connexion.

Figure 7 : Les utilisateurs non autorisés sont automatiquement redirigés vers la page de connexion
(Cliquez pour afficher l’image en taille réelle)

Erreurs de journalisation par programmation

Le module HTTP d’ELMAH ErrorLogModule enregistre automatiquement les exceptions non gérées dans la source de journal spécifiée. Vous pouvez également enregistrer une erreur sans avoir à déclencher une exception non gérée à l’aide de la ErrorSignal classe et de sa Raise méthode. La Raise méthode est passée à un Exception objet et le journalise comme si cette exception avait été levée et avait atteint le runtime ASP.NET sans être gérée. La différence, toutefois, est que la requête continue à s’exécuter normalement après l’appel de la Raise méthode, tandis qu’une exception levée et non gérée interrompt l’exécution normale de la requête et provoque l’affichage de la page d’erreur configurée par le runtime ASP.NET.

La ErrorSignal classe est utile dans les situations où une action peut échouer, mais que son échec n’est pas catastrophique pour l’opération globale en cours d’exécution. Par instance, un site web peut contenir un formulaire qui accepte les entrées de l’utilisateur, les stocke dans une base de données, puis envoie à l’utilisateur un e-mail l’informant qu’il a traité ses informations. Que se passe-t-il si les informations sont correctement enregistrées dans la base de données, mais qu’une erreur se produit lors de l’envoi du message électronique ? Une option consiste à lever une exception et à envoyer l’utilisateur à la page d’erreur. Toutefois, cela peut faire penser à l’utilisateur que les informations qu’il a entrées n’ont pas été enregistrées. Une autre approche consiste à journaliser l’erreur liée à l’e-mail, mais à ne pas modifier l’expérience de l’utilisateur de quelque manière que ce soit. C’est là que la ErrorSignal classe est utile.

' ... Save user's information to the database ...
...
' Attempt to send the user a confirmation email
    ' ... Send an email ...
Try
Catch e As Exception
' Error in sending email. Log it!
ErrorSignal.FromCurrentContext().Raise(e)
End Try

Notification d’erreur via Email

En plus de la journalisation des erreurs dans une base de données, ELMAH peut également être configuré pour envoyer par e-mail les détails de l’erreur à un destinataire spécifié. Cette fonctionnalité est fournie par le ErrorMailModule module HTTP ; par conséquent, vous devez inscrire ce module Web.config HTTP dans afin d’envoyer les détails de l’erreur par e-mail.

<?xml version="1.0"?>
<configuration>
  ...
  
  <system.web>
  ...

  <httpModules>
  ...
  
  <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
  <add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
  </httpModules>
  </system.web>

  <system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  <modules>
  ...

  <add name="Elmah.ErrorLog" type="Elmah.ErrorLogModule, Elmah" preCondition="managedHandler" />
  <add name="Elmah.ErrorMail" type="Elmah.ErrorMailModule" preCondition="managedHandler" />
  </modules>
  
  ...
  </system.webServer>
</configuration>

Ensuite, spécifiez des informations sur l’e-mail d’erreur dans la section de <errorMail> l’élément<elmah>, en indiquant l’expéditeur et le destinataire de l’e-mail, l’objet et si l’e-mail est envoyé de manière asynchrone.

<?xml version="1.0"?>
<configuration>
  ...

  <elmah>
  ...

  <errorMail from="support@example.com"
  to="support@example.com"
  subject="Book Reviews Runtime Error"
  async="true" />
  </elmah>

  ...
</configuration>

Une fois les paramètres ci-dessus en place, chaque fois qu’une erreur d’exécution se produit, ELMAH envoie un e-mail à support@example.com avec les détails de l’erreur. L’e-mail d’erreur d’ELMAH inclut les mêmes informations que celles affichées dans la page web des détails de l’erreur, à savoir le message d’erreur, la trace de la pile et les variables du serveur (reportez-vous aux figures 4 et 5). L’e-mail d’erreur inclut également le contenu De l’écran jaune des détails de l’exception en tant que pièce jointe (YSOD.html).

La figure 8 montre l’e-mail d’erreur d’ELMAH généré par la visite de Genre.aspx?ID=foo. Alors que la figure 8 montre uniquement le message d’erreur et la trace de la pile, les variables de serveur sont incluses plus bas dans le corps de l’e-mail.

Capture d’écran montrant comment configurer ELMAH pour envoyer les détails de l’erreur par e-mail.

Figure 8 : Vous pouvez configurer ELMAH pour envoyer les détails de l’erreur via Email
(Cliquez pour afficher l’image en taille réelle)

Uniquement les erreurs de journalisation intéressantes

Par défaut, ELMAH consigne les détails de chaque exception non gérée, y compris 404 et d’autres erreurs HTTP. Vous pouvez demander à ELMAH d’ignorer ces types d’erreurs ou d’autres types d’erreurs à l’aide du filtrage des erreurs. La logique de filtrage est effectuée par le module HTTP d’ELMAH ErrorFilterModule , dans lequel vous devez vous inscrire Web.config pour utiliser la logique de filtrage. Les règles de filtrage sont spécifiées dans la <errorFilter> section .

Le balisage suivant indique à ELMAH de ne pas consigner les erreurs 404.

<?xml version="1.0"?>
<configuration>
  ...

  <elmah>
  ...

  <errorFilter>
  <test>
  <equal binding="HttpStatusCode" value="404" type="Int32" />
  </test>
  </errorFilter>
  </elmah>

  ...
</configuration>

Notes

N’oubliez pas que pour utiliser le filtrage des erreurs, vous devez inscrire le ErrorFilterModule module HTTP.

L’élément <equal> à l’intérieur de la <test> section est appelé assertion. Si l’assertion prend la valeur true, l’erreur est filtrée à partir du journal d’ELMAH. D’autres assertions sont disponibles, notamment : <greater>, <greater-or-equal>, <lesser><not-equal>, , <lesser-or-equal>, et ainsi de suite. Vous pouvez également combiner des assertions à l’aide des <and> opérateurs booléens et <or> . De plus, vous pouvez même inclure une expression JavaScript simple en tant qu’assertion, ou écrire vos propres assertions en C# ou Visual Basic.

Pour plus d’informations sur les fonctionnalités de filtrage des erreurs d’ELMAH, reportez-vous à la section Filtrage des erreurs dans le wiki ELMAH.

Résumé

ELMAH fournit un mécanisme simple, mais puissant pour la journalisation des erreurs dans une application web ASP.NET. À l’instar du système de surveillance de l’intégrité de Microsoft, ELMAH peut enregistrer les erreurs dans une base de données et envoyer les détails de l’erreur à un développeur par e-mail. Contrairement au système de surveillance de l’intégrité, ELMAH inclut une prise en charge prête à l’emploi d’un plus large éventail de magasins de données de journal des erreurs, y compris : Microsoft SQL Server, Microsoft Access, Oracle, fichiers XML et plusieurs autres. En outre, ELMAH offre un mécanisme intégré pour afficher le journal des erreurs et des détails sur une erreur spécifique à partir d’une page web, elmah.axd. La elmah.axd page peut également afficher les informations d’erreur sous la forme d’un flux RSS ou d’un fichier de valeurs séparées par des virgules (CSV), que vous pouvez lire à l’aide de Microsoft Excel. Vous pouvez également demander à ELMAH de filtrer les erreurs du journal à l’aide d’assertions déclaratives ou programmatiques. Et ELMAH peut être utilisé avec ASP.NET applications version 1.x.

Chaque application déployée doit disposer d’un mécanisme permettant de journaliser automatiquement les exceptions non gérées et d’envoyer une notification à l’équipe de développement. Que cela soit effectué à l’aide de la surveillance de l’intégrité ou d’ELMAH est secondaire. En d’autres termes, il n’est pas vraiment important que vous utilisiez la surveillance de l’intégrité ou ELMAH; évaluer les deux systèmes, puis choisir celui qui répond le mieux à vos besoins. Ce qui est fondamentalement important, c’est qu’un mécanisme soit mis en place pour journaliser les exceptions non gérées dans l’environnement de production.

Bonne programmation!

En savoir plus

Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :

PrécédentSuivant