Archive for category Monitoring
Monitorer simplement et efficacement des flux réseau avec Dartware InterMapper
Publié par Aurélien dans Monitoring le 22 janvier 2010
InterMapper fait partie de ces logiciels indispensables tant les possibilités de tuning qu’il offre ne se limitent qu’à l’imagination de l’administrateur réseau qui le configure. Même si les fonctionnalités sont très complexes dès que l’on rentre dans les arcanes du produit, quelques réglages de bon sens vous feront gagner beaucoup de temps dans l’analyse réseau quotidienne. C’est ce que l’on va tenter de voir avec quelques astuces concernant le monitoring de deux serveurs de test.
Pour commencer, créez une map vierge (File > New Map) à partir de la fenêtre Map List
Choisissez la méthode Manual Entry pour pouvoir ajouter vos serveurs tests comme bon vous semble. Bien évidemment, pour vos besoins vous pourrez choisir Autodiscovery afin de scanner automatiquement vos sous-réseaux ou Import a file pour récupérer des maps déjà créées (via des fichiers séparés par tabulation ou XML) .
Une fois dans votre map, ajoutez des serveurs au choix. Pour l’exemple, on en ajoute deux (Red Hat Linux) dans le réseau 192.168.100.0 et on clique sur le bouton Choose… pour sélectionner la façon de communiquer avec ces serveurs.
La sélection d’une sonde InterMapper reprend des éléments connus tels que le ping ou le SNMP, mais également des sondes spécifiques constructeurs (Apple, Juniper etc…) et des objets WMI Windows. Le choix est vaste, je vous invite à vous pencher dessus pour affiner vos remontées. Ici, on s’attèlera à choisir SNMP Traffic vu que c’est un protocole très bavard qui nous aidera facilement à monitorer les flux. Pour débuter, choisissez SNMPv1 sur le port 161 (v2 et v3 sont plus contraignantes mais si savez vous en servir vous y gagnerez)
Après quelques secondes, voilà vos devices ajoutés et un sous-réseau automatiquement créé. Le logiciel est développé afin d’avoir une information visuelle rapide. C’est immédiatement vérifiable par l’illustration ci-dessous dans laquelle un des serveurs ne répond pas en SNMP, très probablement à cause d’une mauvaise configuration du daemon.
En faisant un clic droit > Status Window sur l’objet, vous obtiendrez plus d’informations, dont la mention du problème tout en bas de la fenêtre.
A présent, cliquez droit > Set Link Speed sur le lien réseau de vos objets respectifs et ajustez les valeurs TX/RX à 100M. A l’heure où les connexions des serveurs se font au minimum en gigabit Ethernet, vous vous demandez sûrement pourquoi régler la vitesse aussi bas ? Eh bien tout simplement parce-qu’il y a très peu de serveurs capables de consommer 1Go en permanence, loin de là ! L’idée sous-jacente est de monitorer les liens avec des valeurs assez basses pour déterminer si elles suffisent ou si la consommation est telle qu’il faut augmenter le seuil. C’est également un moyen très basique de déterminer un potentiel problème de charge sur vos serveurs.
Pour continuer l’analyse, vous pouvez également utiliser les charts (des graphiques) qui permettent l’historisation de la charge réseau grâce au SNMP. Créer un chart est très facile. Retournez dans la fenêtre Status Window d’un serveur dont le SNMP fonctionne et dans la partie Interface Statistics cliquez sur la valeur du champ Utilization. Cela a pour effet de créer un chart générique qui remonte l’utilisation de l’interface vswif0 pour le serveur SRV-TEST2 (carré rouge).
A partir de là, choisissez les valeurs qui vous intéressent en faisant un glisser/déposer de ces valeurs directement dans le graph. Ce qui nous intéresse ici, c’est le pourcentage d’utilisation de Transmit Statistics et Receive Statistics. On va donc les faire glisser dans le graphique. L’illustration ci-dessous montre que la valeur Transmit Statistics a déjà été glissée et se matérialise par un carré bleu.
Ensuite, pour personnaliser le chart, cliquez sur le triangle en bas à gauche du graph et choisissez le menu contextuel Chart Options… Notez au passage le carré jaune qui signifie que la valeur Receive Statistics a à son tour été ajoutée.
La personnalisation du chart peut être assez fine mais pour cet exemple-ci, nous nous astreindrons seulement à décocher la case Auto-adjust donc le but est d’écrêter les valeurs.
Vous êtes maintenant prêt à analyser la charge de vos serveurs, le tout en quelques clics. Ne reste plus qu’à laisser tourner le polling SNMP (par exemple toutes les 5 minutes) et à suivre l’évolution du chart. Ci-dessous, une illustration d’une charge ayant entraîné une crête à 1h10 du matin. A vous d’analyser si elle est ponctuelle ou non, quelle a été la bande passante maximale utilisée, etc etc…
Augmenter le timeout SNMP dans ManageEngine OpManager
Publié par Aurélien dans Monitoring le 14 octobre 2009
Prenons l’exemple d’un problème que vous pouvez rencontrer sur un ESX : votre serveur héberge 20 machines virtuelles mais seules 14 remontent dans le Dashboard ESX Server. Pourtant, vous ne rencontrez aucun problème de configuration SNMP sur les 6 machines que vous monitorez par ailleurs individuellement. C’est à ce moment précis qu’on émet l’hypothèse d’un timeout SNMP trop court dans OpManager.
Pour changer les valeurs du timeout, arrêtez les services OpManager puis rendez-vous dans le répertoire HOME (généralement C:Program FilesAdventNetMEOpManager) de votre installation. Ensuite, repérez le fichier confNmsProcessesBE.conf puis éditez-le en prenant au préalable le soin d’en faire une copie de sauvegarde.
Recherchez la ligne concernant le PROCESS com.adventnet.nms.poll.Collector puis modifiez la ligne suivante de manière à remplacer la valeur de fin de ligne GENERATE_DATACOLL_EVENT false par DATA_COLLECTION_SNMP_TIMEOUT 50.
Avant :
ARGS POLL_OBJECTS_IN_MEMORY 25 POLL_JDBC true MAX_OIDS_IN_ONE_POLL 15
AUTHORIZATION true DATA_COLLECTION_QUERY_INTERVAL 120000
PASS_THRO_ALL_POLLING_OBJECTS true CLEAN_DATA_INTERVAL 999999
GENERATE_DATACOLL_EVENT false
Après :
ARGS POLL_OBJECTS_IN_MEMORY 25 POLL_JDBC true MAX_OIDS_IN_ONE_POLL 15
AUTHORIZATION true DATA_COLLECTION_QUERY_INTERVAL 120000
PASS_THRO_ALL_POLLING_OBJECTS true CLEAN_DATA_INTERVAL 999999
DATA_COLLECTION_SNMP_TIMEOUT 50
Cela aura pour effet de régler le timeout par défaut à 50 alors qu’il est normalement réglé à 5. Il ne vous restera alors plus qu’à redémarrer les services puis, de retour dans la page de gestion de l’hôte ESX, à cliquer sur Actions puis Rediscover now. Tout devrait rentrer dans l’ordre !
Configurer le service SNMP sous Microsoft Windows Server 2003
Publié par Aurélien dans Monitoring, Windows le 7 octobre 2009
Configuration des informations relatives à l’agent SNMP
Dans la gestion des services Windows, on repère le service Service SNMP. Dans l’onglet Agent, il faut activer les cases à cocher nécessaires à l’utilisation du poste. La plupart du temps, la configuration par défaut suffit :
- Physique : indique si l’ordinateur gère les périphériques physiques, tels qu’une partition de disque dur
- Applications : indique si l’ordinateur utilise des programmes qui envoient des données via le protocole TCP/IP
- Liaison de données et sous-réseau : indique si cet ordinateur gère un sous-réseau ou une liaison de données TCP/IP, par exemple un pont
- Internet : indique si cet ordinateur tient lieu de passerelle IP (routeur)
- Bout en bout : indique si cet ordinateur tient lieu d’hôte IP

Configuration des communautés et des interruptions SNMP
Dans l’onglet Interruptions, on ajoute le nom de la communauté (la plupart du temps ce sera public) puis, dans la partie Destinations des interruptions, l’adresse IP du serveur de monitoring.

Configuration de la sécurité SNMP
Pour configurer la sécurité SNMP pour une communauté, on clique sur l’onglet Sécurité et on s’assure que la case Envoyer une interruption d’authentification est cochée. Ensuite, on ajoute la communauté voulue en LECTURE ECRITURE et on n’oubliera pas d’accepter les paquets SNMP provenant de n’importe quel hôte.

Une mise en garde pour finir. N’oubliez pas de passer en mode maintenance tout serveur SQL Server pour lequel vous voudriez installer SNMP. En effet, dans le cas contraire, l’installation du produit provoquerait une micro-coupure liée à la gestion mémoire de SQL Server qui serait assez néfaste pour votre production.










