Il faudrait voir ce que te retourne une interrogation SNMP avec snmpwalk. Quel est l’OS du serveur interrogé ?
il y a du Windows serveur 2008R2, du 2012R2, du 2016 ainsi que du 2019
le snmpwalk ( snmpwalk -v 2c -c <comu> 10.0.1.115 ) renvoie les info cependant les info, cependant les check type memory ( /usr/lib/centreon/plugins//centreon_windows_snmp.pl --plugin=os::windows::snmp::plugin --mode=memory --hostname=10.0.1.115 --snmp-version='2c' --snmp-community='<comu>' --warning-memory='80' --critical-memory='90' ) repond que de temps en temps sur la debian mais constament sur la centos6
Tu as essayé d’augmenter le timeout de ton check memory ?
>repond que de temps en temps sur la debian mais constament sur la centos6
Tu parles de l’OS du poller Centreon là où de celui du serveur interrogé ?
sur le poller centreon debian(nouveau serveur), le check du serv windows me retourne des valeur quelque fois, mais sur le poller centreon centos6(ancien serveur), les check retourne des valeur a chaque check donc reponse a chaque check (via check web et via check cli).
j’ai essaye d’allongé le timeout mais je croix qu’il me l’avais pas pris en compte il faudrai que je retest
en CLI, des lors que j’ai mis --snmp-timeout=’5’, il me retourne toujours les info
cependant je ne sais pas trop comment on peut mettre un timeout dans le check
Ce sont ces deux options qui entre en jeu pour le timeout des plugins Centreon basés sur SNMP :
--snmp-timeout
Timeout in secondes (default: 1) before retries.
--snmp-retries
Set the number of retries (default: 5) before failure.
Ce qui est bizarre avec ton problème c’est que malgré la différence de comportement du plugin entre ton Centreon Debian et ton Centreon CentOS, tu n’as aucune différence de comportement sur le snmpwalk, c’est bien ça ?
Si tu n’as pas de réponse ici tu peux p-e ouvrir une issue sur https://github.com/centreon/centreon-plugins
Quelle version de Centreon, et du plugin ? Les mêmes côté Debian que CentOS ?
le snmpwalk repond toujours enfin d’apres tout les cmd que je fait avec plusieur hote qui posais soucis avec les check.
sur centreon debian je suis en version 22.04.9 avec la base de plugin (pas de abo)
par contre sur centreon centos je suis en 2.8.32 avec base de plugin
Je sèche j’avoue. J’espère que tu auras une réponse de quelqu’un d’autre.
De mon expérience les régressions sont nombreuses avec les nouvelles versions de Centreon, c’est bien dommage. Le produit a perdu en qualité ces dernières années. 
d’accord, sit avec un timeout plus a 5 sa passe tant mieux par contre je le met ou dans les check de service ? dans le snmpextraoption ?
Si ça fonctionne avec --snmp-timeout=5 il suffit que tu l’ajoute au modèle de service ou à la commande. Voire directement au service si ça ne concerne qu’un seul serveur.
Même si tu n’utilises pas les plugin packs ton service a bien un modèle de service, non ?
EDIT: oui dans la macro SNMPEXTRAOPTIONS ça ira très bien. (Au niveau du service ou du modèle)
oui j’utilise le service du pack snmp windows
Si plusieurs serveurs sont concernés il faut l’ajouter à la macro au niveau du modèle (le *.custom).
Bonjour,
Sur certains windows pour les timeout, surtout 2k12 ou 2k19, j’ai du rajouté pour certains check, en général swap ou disk, mais pas que :
--snmp-force-getnext
--snmp-autoreduce, bien que beaucoup plus rarement pour celle là.
Bonjour,
Désolé de reposer la question mais j’aurais besoin de précisions sur l’utilisation de snmpwalk. Je suis en reconversion professionnelle et je ne suis pas à l'aise avec les requêtes snmp.
J’ai un serveur Centreon qui check mes différents serveurs. Depuis quelques temps mes checks sur un de mes serveurs physique retournent UNKNOWN: SNMP Table Request : Timeout.
J'ai installé snmpwalk sur mon poste et je voulais tester une requête sur le serveur qui pose problème mais j'ai vu un post sur internet qui dit qu'il ne faut pas lancer de requête snmpwalk sur la racine de l'arbre snmp ou sur un noeud de haut niveau sous peine de saturer l'agent snmp, le réseau et mon poste.
Du coup je n'ose pas trop lancer la requête que propose Sservais : snmpwalk -v 2c -c
Il y a -t-il un risque ? Quel OID dois je interroger pour voir l'utilisation de l'UC ?
Concernant les requêtes check Type Memory ( /usr/lib/centreon/plugins//centreon_windows_snmp.pl --plugin=os::windows::snmp::plugin --mode=memory --hostname=10.0.1.115 --snmp-version='2c' --snmp-community='<comu>' --warning-memory='80' --critical-memory='90' ) je suppose que je ne peux pas les faire de mon poste. Je suis obligé de les faire à partir du serveur Centreon ?
Merci d'avance pour vos réponses.
'il ne faut pas lancer de requête snmpwalk sur la racine de l'arbre snmp ou sur un noeud de haut niveau sous peine de saturer l'agent snmp, le réseau et mon poste.
Il faut éviter de le faire de manière régulière et fréquente mais à moins d’un hôte particulièrement sollicité par ailleurs, ou d’un réseau en carton, ça ne devrait pas poser de problème.
Si tu veux uniquement tester la conso mémoire depuis ton poste avec snmpwalk, puisque c’est le check mémoire qui semble de poser problème, tu peux cibler ta requête snmpwalk avec cette OID:
snmpwalk -v2c -c tacommunaute hotedistant 1.3.6.1.4.1.2021.4
ou plus simplement :
snmpwalk -v2c -c tacommunaute hotedistant memory
Merci pour vos réponses.
J’ai essayé la requête
snmpwalk -v2c -c <macommunauté> <IPHôte distant> memory
sur plusieurs hôtes et la réponse est toujours la même :
Timeout: No Response from <IPHôte>
