Quand vous developpez une application ou un service, vous aurez inévitablement besoin d’une façon de pouvoir sauvegarder de l’information sur le déroulement de ce dernier. Par exemple:

• Un authentification qui a réussie ou qui a échoué dans votre programme
• Un erreur innattendu survient
• Bref, tout événements qui a besoin d’être enregistré dans un journal d’événement

Vous pourriez bien sur créer votre propre système d’archivage d’événement dans un fichier ou une base de donnée, mais il faut réaliser que le Journal d’événement fait beaucoup de travail, et donc que de « recoder » toutes les même fonctionnalitées pourrait s’avérer une tâche ardue.

Votre application doit s’enregistrer auprès du journal d’événement de Windows afin de pouvoir l’utiliser. On dis alors que votre application enregistre donc une Source auprès du journal d’événements. Imaginez la Source étant comme une carte d’identité nécessaire pour pouvoir écrire dans le journal d’événements. Une fois la Source enregistrée auprès du journal d’événement, votre application pourra écrire dans celui-ci, au nom de cette Source.

Durant l’utilisation d’un journal d’événement, il est important de comprendre que ce dernier contient plusieurs types d’événements, et que ceux-ci peuvent usuellement être regroupé en trois (3) grandes parties: les événements d’applications, les événements du système et les événements personnalisés. Par défault, Windows enregistre les événements de votre Source (application) dans le Log (fillière) Application. En générale, vous voulez que votre Source (application) enregistre ses événements dans un Log (filière) personnalisée, par exemple « MyAppLog » pour que les événements de votre applications ne soit pas mélangé avec les autres événements des autres applications et services. Ceci facilite grandement la vie des utiliseurs.

Pour enregistrer une Source (application) et créer un Log (fillière) personnalisé pour celle-ci, vous pouvez par exemple:

EventLog.CreateEventSource("MyAppSource", "MyAppLog");

(*) Il est préférable de ne pas utilisé le même nom pour la Source (application) ainsi que le Log (fillière)
(**) Il est possible que la création d’une fillière personnalisé ne soit pas immédiate. Toutefois, en redémarrant l’ordinateur, cela assure que les filières personnalisé en attente d’écriture ont bien été créés. Cela peut arriver par exemple lorsque vous créer un projet d’installation pour un service, et que le projet d’installation configure votre Source (application) pour écrire dans le Log (fillière) par défaut, mais que plus tard lorsque votre service s’exécute, vous créez votre propre Log (fillière) et ré-enregistrer votre Source (application) pour pointer vers ce nouveau Log (fillière). À défaut d’avoir une meilleur façon d’assurer la cohérance du journal des événements, je vous suggerais de redémarrer la machine en question dans un cas similaire.

Le journal d’événements de Windows offres plusieurs fonctionnalitées comme:

• Centralise les logs et les événements des applications et services de votre ordinateur dans un endroit centralisé
• Il est possible de faire en sorte que votre application, qui roule sur plusieurs ordinateurs, archive les événements sur un ordinateur à distance et donc de regrouper les événements sur un seul et unique ordinateur pour une gestion encore plus centralisée
• Il est possible d’utiliser les filières Application, Système ou de créer sa propre filière « Log ou Log Folder » afin d’y archiver des événements pour une consultation plus rapide et un archivage qui permet une rétention sur un jeu d’événement précis.
• Un système de rétention efficace qui, vous permet de bien controller la façon donc Windows gère et écrit les événements, ainsi que les situations ou l’espace disque pourrait être manquant.

Une application qui utilise le journal d’événement de Windows peut facilement remplir ce dernier et causer des problèmes. C’est pourquoi nous désirons pouvoir effacer le journal.

Par exemple:

using (EventLog el = new EventLog{ Log = "MyEventLogTag" })
{
    el.Clear();
    el.Close();
    el.Dispose();
}

Le problème avec cette appel est que vous ne pouvez pas garder un certain nombre d’événements, c’est tout ou rien. Donc c’est à utiliser avec précaution dans un environnement de production.

Une solution consiste à utiliser l’attribut OverflowAction. C’est une énumération qui dit à Windows quoi faire quand le journal d’événements est plein. Les valeurs possible sont:

• OverflowAction.DoNotOverwrite
  Cette option indique à Windows que dès que le journal d’événement est plein, d’arrêter d’écrire les événements dans celui-ci. Tous les nouveaux événements sont perdu et non sauvegardés.
• OverflowAction.OverwriteAsNeeded
  Cette option indique à Windows que dès que le journal d’événement est plein, de supprimer les plus anciennes entrées, pour pouvoir insérer les nouvelles entrées. Cette option représente la solution la plus sûr.
• OverflowAction.OverwriteOlder
  Cette option indique à Windows que dès que le journal d’événement est plein, de vérifier s’il existe des événements qui serait plus vieux que le nombre de jours de rétention préalablement défini par l’attribut MinimumRetentionDays. Si dès événements sont trouvés, ceux-ci sont écrasés par les nouveaux événements, sinon, les nouveaux événements sont perdu et non sauvegardés.

Comme mentionné, l’attribut MinimumRetentionDays indique le nombre de jours que le système doit retenir les événements dans le journal. Dans le mode DoNotOverwrite la valeur est -1. Dans le mode OverwriteAsNeeded la valeur est 0. Dans le mode OverwriteOlder, la valeur doit être entre 1 et 365 jours.

Pour changer la politique de rétention, utilisez la méthode ModifyOverflowPolicy. Celle-ci prend deux paramètres, l’énumérateur OverflowAction et un nombre (int/Int32) indiquant le nombre de jours de rétention. Si vous n’utilisez pas le mode OverwriteOlder, la valeur de MinimumRetentionDays est ignoré.
Par exemple:

using (EventLog el = new EventLog{ Log = "MyEventLogTag" })
 {
    el.ModifyOverflowPolicy(OverflowAction.OverwriteAsNeeded, 0);
    el.Close();
    el.Dispose();
 }

Finalement, pour terminé, il existe un dernier attribut que vous devriez regarder. Si votre application génère beaucoup d’événements et que ces derniers se génèrent plus rapidement que prévue. La solution consiste à aggrandir la taille alloué au journal en utilisant l’attribut MaximumKilobytes.
Par exemple:

using (EventLog el = new EventLog{ Log = "MyEventLogTag" })
 {
    el.MaximumKilobytes = 1024;
    el.Close();
    el.Dispose();
 }

Donc maintenant vous disposez des connaissances nécessaire pour faire la gestion et le nettoyage des journal d’événements dans vos applications .NET.