Concevoir des critères d’alerte

vous devez prendre les choses en main. La création de critères d’alerte est semblable à l’élaboration des rapports, décrite précédemment. Mais il faut être encore plus sélectif quant à ceux qu’il convient d’envoyer à votre pager ou à votre boîte de réception comme une alerte. La plupart des programmes d’alerte permettent d’écrire des filtres Exclude et Include puis de les classer dans un ordre qui élimine les événements mineurs. Si vous utilisez WMI comme je l’ai décrit, vous pouvez utiliser la clause Where pour éliminer par filtrage la plupart des événements indésirables. Si la clause Where de WMI vous impose quelques limites, vous pouvez effectuer un filtrage supplémentaire dans le script VBScript.

Je recommande d’utiliser Log Parser pour créer vos critères d’alerte plutôt que d’établir vos alertes et de les régler constamment jusqu’à ce que votre pager se calme. En utilisant les données d’événements déjà collectées dans vos journaux, commencez avec les mêmes critères que ceux déjà utilisés dans vos rapports et affinez-les de manière à éliminer par filtrage les événements les moins importants qui ne justifient pas une alerte. Si vous avez des données de journalisation pour une période d’un mois environ, cette méthode permet de procéder à des simulations ou à un traitement d’alertes sur une longue période, pour voir si vous risquez d’être submergés d’alertes. Dès lors que vos critères d’alerte vous satisfont sous la forme de rapports de Log Parser (ou d’un autre outil de reporting), vous pouvez convertir les critères en requêtes WMI à l’intérieur des scripts VBScript. Si vous voulez que les scripts d’alerte soient toujours actifs, vous pouvez les configurer comme des scripts de démarrage qui seront lancés automatiquement à l’initialisation. Vous pouvez configurer les scripts de démarrage dans tout GPO (Group Policy Object) sous Computer Configuration\Windows Settings\Startup and Shutdown Scripts. En tant que scripts de démarrage, les alertes s’exécutent dans le contexte du compte System local, ce qui leur confèrera l’autorité nécessaire.

Pour instaurer de bons critères de rapport et d’alerte, il faut appliquer un principe simple : éliminer par filtrage ce que l’on ne veut pas voir dans le rapport ou dans les alertes, et pas ce que l’on veut voir. En raison du grand nombre de sources d’événements et de la médiocre documentation qui accompagne la plupart des applications et des appareils de réseau, il n’est pas possible d’énumérer tous les événements ou messages importants. Si l’on se contente de rechercher les événements critiques connus, le risque est grand de voir un appareil ou un système défectueux signaler un événement étranger à vos critères de recherche. Mais, pour établir un bon équilibre, il faut créer quelques alertes ou rapports qui recherchent des critères spécifiques. En partant des problèmes qui vous sont familiers, vous pourrez construire les alertes et les rapports appropriés. D’une manière générale, quand on crée des critères, il faut penser exclusion plutôt que inclusion.