Définir et personnaliser les seuils d’alerte dans Dartware InterMapper

Lorsque vous monitorez un serveur, vous voulez probablement pouvoir avoir plusieurs compteurs personnalisés qui reflètent les services installés sur la machine. Par exemple, le monitoring d’un serveur SQL Server sera optimisé si l’on n’oublie pas de monitorer le port 1433 (par défaut) et tous les services relatifs à ce SGBD.

Pour cet article, on décide de monitorer des instances Tomcat réparties sur les ports 8080, 9990 et 8181 via les probes HTTP fournies. Vous pourrez personnaliser ces probes en indiquant une URL bien précise et vérifier la présence d’une chaîne de caractère (par exemple pour déterminer un uptime…) ainsi que le port utilisé, donc.

Ici, on constate le monitoring de deux instances Tomcat qui servent trois sites. Si InterMapper ne nous le dit pas directement, une rapide connexion au serveur nous informe que xitim (8080) et Dev (9990) utilisent Tomcat 4.1 et Preprod (8181) Tomcat 5. La raccourci est facile à faire : apparemment, Tomcat 4.1 charge plus que Tomcat 5…

L’intérêt de cette illustration réside dans le fait que deux des trois triggers répondent assez mal au poll. En effet, un temps de réponse supérieur à 3 secondes pour une application intranet locale semble déraisonnable. Ce qu’il y a de bien avec InterMapper, c’est que vous pouvez le monitorer mais surtout le chiffrer et le grapher dans le temps. Ainsi, vous pourrez par exemple aller voir votre pôle développement et lui argumenter que tous les jours à partir de 14h, les applications montent en charge. Trop de connexions simultanées ? Une machine sous-dimensionnée pour deux instances Tomcat servant trois sites ? Quelle que soit la cause du mauvais temps de réponse au poll, vous aurez les premiers éléments indispensables pour espérer résoudre votre problème. En tous cas, le rôle d’InterMapper s’arrête là.

Maintenant, vous pouvez personnaliser les seuils d’alerte de vos triggers. Imaginez que vos alarmes associées – quand bien même vous leur demanderiez une répétition toutes les demi-heures seulement – vous abreuvent de nombreuses alertes e-mail ou SMS, ne serait-il pas préjudiciable d’être noyé sous ces alarmes “maîtrisées” qui vous feraient peut-être louper d’autres problèmes plus critiques ? La réponse est probablement si, c’est pour cela qu’on peut customiser les seuils (thresholds) et affiner un trigger pour qu’il corresponde avec l’évolution de notre connaissance du parc et des services installés.

Personnaliser un seuil d’alerte

L’opération est très simple. Cliquez droit sur la probe monitorée (par exemple HTTP 8080) puis naviguez dans le menu Set Info > Set Thresholds…

Ne reste plus qu’à décocher la case Use Map defaults et renseigner les valeurs que vous avez empiriquement constatées. Les deux instances de test Tomcat qui nous intéressent ne répondent apparemment jamais au-dessus de 3500 msec. Il est donc intéressant de mettre la première échelle d’alertes (Warning) à la valeur 3500 et ainsi constater que notre sensation est bonne, mais aussi qu’elle n’omet pas un problème plus grave où le temps de réponse monterait à 4500 msec 1h par jour. Bref, on peut imaginer tous les soucis, vous l’avez compris, le tout étant de ne rien laisser au hasard et ainsi d’éviter les surprises.

Il faut également savoir que chaque trigger que l’on place possède ses particularités propres. Ainsi, les options de personnalisation qui existent pour la probe HTTP sont assez différentes de celles d’une probe SNMP standard comme illustré ci-dessous.

Importer des probes spécifiques dans Dartware InterMapper

Le logiciel InterMapper est livré avec bon nombre de probes (sondes) qui vous permettent de monitorer la plupart de vos équipements. Pour des besoins plus spécifiques, vous pouvez soit développer vos propres probes, soit vous servir de celles envoyées par des utilisateurs sur la page internet de l’éditeur. Pour cela, rendez-vous sur le site et naviguez dans le menu Support > User Contributed Probes. Vous y trouverez des probes aussi pratiques que variées. Pour illustrer cet article, nous téléchargerons une probe de stockage Dell EqualLogic qui permet d’avoir une vue optimale des baies de stockage SAN iSCSI.

Une fois votre probe téléchargée, dézippez-la. Vous obtenez un fichier com.mindshift.snmp.dell.equallogic.ps que vous aurez simplement à importer dans InterMapper via le menu File > Import > Probe. Une fois l’import terminé, un message vous confirmera la réussite (ou pas) de l’opération. Comme toujours avec InterMapper, chaque événement est loggué dans le journal des événements de l’application si vous voulez connaître plus en détail ce que fait le backoffice.

Notez que nous aurions très bien pu aller glisser-déposer la probe directement dans le répertoire Probes du logiciel. C’est une souplesse assez appréciable…

Maintenant que votre nouvelle probe est installée, vous pouvez observer qu’elle apparaît dans la liste des sondes disponibles.

Quelques réglages sont proposés. Comme toujours, SNMPv1 sera le plus accessible. Les baies Dell EqualLogic disposant de l’authentification SNMPv3, vous pourrez également choisir ce paramétrage selon votre politique de sécurité.

L’information qui nous intéresse surtout concerne le SAN ID que toute baie EqualLogic possède. Si vous ne le remplissez pas, votre baie renverra des informations partielles et l’intérêt de la probe sera réellement limité. Voici une baie dans laquelle le SAN ID n’a pas été renseigné. Remarquez toutes les informations manquantes.

Comment connaître le SAN ID alors ? Faites pour cela un clic droit sur votre trigger préalablement ajouté dans InterMapper puis choisissez SNMPWalk. Tapez l’OID suivant : 1.3.6.1.4.1.12740.2.1.1.1.9.1

Cela aura pour effet de collecter les données qui nous intéressent sur la baie. En l’occurrence, repérez la suite de chiffres accolée à l’OID que vous venez de taper.

Retournez à présent dans la configuration de votre probe et renseignez la suite de chiffre correspondant au SAN ID de votre baie. Immédiatement, les informations retournées prennent une toute autre allure.

Vous pouvez maintenant tirer pleinement parti de votre User Contributed Probe. N’hésitez pas à régulièrement consulter les ajouts des utilisateurs de la communauté InterMapper pour obtenir de nouvelles probes !

Personnaliser la remontée automatique des serveurs dans ManageEngine OpManager

Les équipements que vous pouvez être amené à monitorer dans OpManager disposent chacun de leur spécificités. Néanmoins, des éléments communs essentiels tels que le type d’OS des serveurs permettent de créer des modèles pour lesquels vous n’aurez plus à créer de fastidieuses remontées manuelles. Dans OpManager donc, cliquez sur le menu Admin > Device Templates. Ensuite, trouvez les périphériques qui existent en nombre suffisamment conséquent pour nécessiter la création d’un modèle (template). Ici, on remarque que 30 serveurs Linux sont remontés dans le logiciel, c’est suffisant pour créer un template.

Vous venez de cliquer sur le template Linux, cela vous permet de le modifier. A partir de là, vous pourrez d’office assigner une catégorie à tout nouveau serveur Linux ajouté à OpManager (ici on a choisi Server). De même, vous pouvez personnaliser assez finement le template de base : intervalle de monitoring, icône, ajout d’OID SNMP, de compteurs spécifiques etc…

Dans la capture écran ci-dessus, vous avez pu observer que la politique définie pour les objets Linux sera de relever l’utilisation CPU toutes les 15 minutes, ainsi que le remplissage des disques toutes les heures. On peut aussi ajouter un Threshold (seuil) qui changera l’état du serveur si la valeur est dépassée.

Bien évidemment, les paramètres présentés ici servent uniquement à vous donner quelques idées de remontées automatiques. Reste désormais à vous creuser la tête pour déterminer une pertinence qui correspondra à vos besoins de production.

Enfin, une dernière opération bien pratique consiste à pousser le template ainsi créé à vos objets déjà ajoutés à OpManager. De retour dans la modification du template, cliquez le bouton Modify. Vous aurez alors la liste de vos serveurs. Sélectionnez ceux qui vous intéressent et cliquez le bouton Apply & Overwrite pour remplacer le template existant par celui que vous venez de définir.