trap snmp -> revenir à l'état normal

[kuroro]

Bonjour,

J'ai configurer tout ce qu'il fallait pour recevoir les traps (franchement, c'est une sacrée opération...)
Donc je génère une trap, et dans mon interface l'état de mon service test-trap passe à Warning, avec la description de la trap.


Maintenant, j'aimerai bien qu'à un moment ou à un autre, l'état de mon service repasse à OK....
J'ai essayer un truc :
j'ai passé Controle de validité des données (check_freshness) à Oui
,Seuil de controle de validité (check_interval_freshness) à 600,
et check_command à check_passive_missing

check_passive_missing exécute la commande check_dummy 0

Si j'ai tout compris, normalement ceci devrait forcer un controle actif avec la commande check_passive_missing des que l'état est vieux de plus de 600 secondes.

Pourtant, l'état de mon service ne change jamais, et cette commande de check n'est jamais éxécuté.

Mais qu'ai-je bien donc pu oublié?

[surcouf]

Bonjour,

J'ai configurer tout ce qu'il fallait pour recevoir les traps (franchement, c'est une sacrée opération...)
Donc je génère une trap, et dans mon interface l'état de mon service test-trap passe à Warning, avec la description de la trap.


Maintenant, j'aimerai bien qu'à un moment ou à un autre, l'état de mon service repasse à OK....
J'ai essayer un truc :
j'ai passé Controle de validité des données (check_freshness) à Oui
,Seuil de controle de validité (check_interval_freshness) à 600,
et check_command à check_passive_missing

check_passive_missing exécute la commande check_dummy 0

Si j'ai tout compris, normalement ceci devrait forcer un controle actif avec la commande check_passive_missing des que l'état est vieux de plus de 600 secondes.

Pourtant, l'état de mon service ne change jamais, et cette commande de check n'est jamais éxécuté.

Mais qu'ai-je bien donc pu oublié?

As-tu activé cette fonctionnalité avec le modèle de ton service ? Au sein de Nagios ?
As-tu activé la rétention d'informations non-status ?

[kuroro]

As-tu activé cette fonctionnalité avec le modèle de ton service ? Au sein de Nagios ?
En fait, j'ai activé ces fonctionnalité dans le modèle de service. DAns mon service à proprement parlé, ces paramètres sont à "vide".
Je pense l'avoir fait au sein de Nagios. C'est dans le fichier nagios.cfg, n'est ce pas?
Dans la config de nagios.cfg sous oreon, j'ai Service Freshness Checking Option et Host Freshness Checking Option, Service Freshness Check Interval et Host Freshness Check Interval à 3600.

As-tu activé la rétention d'informations non-status ?
Dans mon modèle de service, retain_nonstatus_information est à 1.
Faut-il le désactiver?
Dans nagios.cfg, je ne vois pas si il y a un paramètre de ce type, donc s'il existe il n'est pas activé.


Merci en tout cas de t'intéresser à mon problème.

[surcouf]

En fait, j'ai activé ces fonctionnalité dans le modèle de service. DAns mon service à proprement parlé, ces paramètres sont à "vide".
Je pense l'avoir fait au sein de Nagios. C'est dans le fichier nagios.cfg, n'est ce pas?

Les paramètres propres à Nagios sont en effet consignés dans le fichier nagios.cfg.

Dans la config de nagios.cfg sous oreon, j'ai Service Freshness Checking Option et Host Freshness Checking Option, Service Freshness Check Interval et Host Freshness Check Interval à 3600.

Quelle est la question exacte ?

Dans mon modèle de service, retain_nonstatus_information est à 1.
Faut-il le désactiver?
Dans nagios.cfg, je ne vois pas si il y a un paramètre de ce type, donc s'il existe il n'est pas activé.

Oui, il faut le désactiver car dans le cas présent, Nagios va prendre les directives du service à partir du fichier de rétention de données et non plus depuis les fichiers de configuration. Ceci a pour but de permettre aux CGI de modifier certains paramètres depuis les CGI sans toucher aux fichiers.

[kuroro]

J'ai désactivé la retention de données, mais il n'y a toujours aucun changement.
Par contre, peut etre faut-il modifier quelquechose dans le nagios.cfg?

Voici mon service modèle :

define service{
name generictrap-service-serveur
service_description generictrap-service-serveur
is_volatile 1
check_command passive_check_missing
max_check_attempts 1
normal_check_interval 1
retry_check_interval 1
active_checks_enabled 0
passive_checks_enabled 1
check_period none
parallelize_check 1
obsess_over_service 0
check_freshness 1
freshness_threshold 600
event_handler_enabled 0
flap_detection_enabled 0
process_perf_data 0
retain_status_information 0
retain_nonstatus_information 0
notification_interval 10
notification_period 24x7
notification_options w,u,c,r
notifications_enabled 1
contact_groups admins
register 0
}


Vois tu quelque chose qui expliquerai qu'aucun active_check ne soit effectué après la fin de l'intervalle de "freshness" ?

[surcouf]

J'ai désactivé la retention de données, mais il n'y a toujours aucun changement.
Par contre, peut etre faut-il modifier quelquechose dans le nagios.cfg?

Voici mon service modèle :


Vois tu quelque chose qui expliquerai qu'aucun active_check ne soit effectué après la fin de l'intervalle de "freshness" ?

Il n'y a rien qui l'explique dans ton modèle.
Vérifie toutefois que la fonctionnalité soit bien activé du côté de Nagios.

[kuroro]

Oui, elle est bien activé il me semble. Je te balance tout mon nagios.cfg, au cas ou...


cfg_file=/usr/local/nagios/etc/hosts.cfg
cfg_file=/usr/local/nagios/etc/services.cfg
cfg_file=/usr/local/nagios/etc/misccommands.cfg
cfg_file=/usr/local/nagios/etc/checkcommands.cfg
cfg_file=/usr/local/nagios/etc/contactgroups.cfg
cfg_file=/usr/local/nagios/etc/contacts.cfg
cfg_file=/usr/local/nagios/etc/hostgroups.cfg
cfg_file=/usr/local/nagios/etc/servicegroups.cfg
cfg_file=/usr/local/nagios/etc/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/escalations.cfg
cfg_file=/usr/local/nagios/etc/dependencies.cfg
cfg_file=/usr/local/nagios/etc/hostextinfo.cfg
cfg_file=/usr/local/nagios/etc/serviceextinfo.cfg
resource_file=/usr/local/nagios/etc/resource.cfg
log_file=/usr/local/nagios/var/nagios.log
temp_file=/usr/local/nagios/var/nagios.tmp
status_file=/usr/local/nagios/var/status.log
aggregate_status_updates=0
status_update_interval=15
nagios_user=nagios
nagios_group=nagios
enable_notifications=1
execute_service_checks=1
accept_passive_service_checks=1
execute_host_checks=1
accept_passive_host_checks=1
enable_event_handlers=1
log_rotation_method=d
log_archive_path=/usr/local/nagios/var/archives/
check_external_commands=1
command_check_interval=1s
command_file=/usr/local/nagios/var/rw/nagios.cmd
downtime_file=/usr/local/nagios/var/downtime.log
comment_file=/usr/local/nagios/var/comment.log
lock_file=/usr/local/nagios/var/nagios.lock
retain_state_information=1
state_retention_file=/usr/local/nagios/var/status.sav
retention_update_interval=60
use_retained_program_state=1
use_syslog=1
log_notifications=1
log_service_retries=1
log_host_retries=1
log_event_handlers=1
log_initial_states=1
log_external_commands=1
sleep_time=1
service_interleave_factor=s
max_concurrent_checks=20
service_reaper_frequency=10
interval_length=60
use_agressive_host_checking=1
enable_flap_detection=0
low_service_flap_threshold=25.0
high_service_flap_threshold=50.0
low_host_flap_threshold=25.0
high_host_flap_threshold=50.0
soft_state_dependencies=0
service_check_timeout=60
host_check_timeout=60
event_handler_timeout=60
notification_timeout=60
ocsp_timeout=1
perfdata_timeout=5
obsess_over_services=0
process_performance_data=1
check_for_orphaned_services=0
check_service_freshness=1
service_freshness_check_interval=3600
check_host_freshness=1
host_freshness_check_interval=3600
date_format=euro
illegal_object_name_chars=~!$%^&*"|'<>?,()=
illegal_macro_output_chars=`~$^&"|'<>

[kuroro]

Dans le monitoring, les services pour les traps j'ai :
Ce Service est Volatile ? No

J'ai vérifié, dans le services.cfg , is_volatile est bien à 1.

J'en doute, mais le problème pourrait venir de la.
Ca dis quelquechose à quelqu'un?

[surcouf]

Dans le monitoring, les services pour les traps j'ai :
Ce Service est Volatile ? No

J'ai vérifié, dans le services.cfg , is_volatile est bien à 1.

J'en doute, mais le problème pourrait venir de la.
Ca dis quelquechose à quelqu'un?

Non, au contraire, cela n'a rien de surprenant comme options pour un service passif.

[kuroro]

non, non, je crois que tu ne m'a pas compris.

Le monitoring m'indique que le service n'est pas volatile, alors qu'il devrait l'être, et que services.cfg indique bien que le service a été défini comme volatile.

[surcouf]

non, non, je crois que tu ne m'a pas compris.

Le monitoring m'indique que le service n'est pas volatile, alors qu'il devrait l'être, et que services.cfg indique bien que le service a été défini comme volatile.

Il faut vider la ligne correspondante dans le fichier de rétention d'informations, en ce cas.

[kuroro]

c'est lequel le fichier de rétention d'informations?
Il retient les informations longtemps, parce que ca fait plusieurs jour que j'ai passé mes services à volatile, et que dans le monitoring ils apparaissent comme non volatile!

[surcouf]

c'est lequel le fichier de rétention d'informations?
Il retient les informations longtemps, parce que ca fait plusieurs jour que j'ai passé mes services à volatile, et que dans le monitoring ils apparaissent comme non volatile!

Voir le fichier de configuration de Nagios.
Il garde les informations ad vitam eternam.

[kuroro]

J'ai trouvé le fichier de rétention : /usr/local/nagios/var/status.sav.

J'ai désactivé la rétention d'information, j'ai supprimé puis recréé mon service "trap".

Résultat, mes services trap n'apparaissent plus dans status.sav.
Mais le problème reste le même, le monitoring m'indique toujours No pour la volatilité.
De plus, le check actif n'est toujours pas déclenché...

[kuroro]

JE modifie l'attribut is_flapping dans le status.sav
Mais quand je redémarre nagios, le status l'attribut revient à 0...
Vraiment incompréhensible...

[kuroro]

Je m'embrouille dans mon probleme.
Je crois que la première chose, c'est qu'il y a peut être une erreur dans l'interface Oreon.
Dans le monitoring, quand il est marqué "Ce service est-il volatile ?", cela correspond à la valeur is_flapping du fichier de rétention d'information.
Or, is_flapping n'a a mon avis rien à voir avec la volatilité d'un service.

Est ce une erreur??? Quelqu'un peu me confirmer?

Cela ne résout pas mon problème, mais il semblerait que la valeur de is_volatile ne soit pas enregistrée dans le fichier de rétention (ce qui est normal). Donc si mon active_check n'est pas effectué, c'est que soit il y a un problème dans nagios, soit que j'ai un truc pourri dans mes fichiers de conf.

Quelqu'un peut-il me fournir les fichiers de conf d'un service passif (avec volatile) qui fonctionne bien (donc active_check effectuées lorsque l'on dépasse le seuil de freshness), et le nagios.cfg correspondant?

Merci d'avance

[surcouf]

Je m'embrouille dans mon probleme.
Je crois que la première chose, c'est qu'il y a peut être une erreur dans l'interface Oreon.
Dans le monitoring, quand il est marqué "Ce service est-il volatile ?", cela correspond à la valeur is_flapping du fichier de rétention d'information.
Or, is_flapping n'a a mon avis rien à voir avec la volatilité d'un service.

Est ce une erreur??? Quelqu'un peu me confirmer?

Cela ne résout pas mon problème, mais il semblerait que la valeur de is_volatile ne soit pas enregistrée dans le fichier de rétention (ce qui est normal). Donc si mon active_check n'est pas effectué, c'est que soit il y a un problème dans nagios, soit que j'ai un truc pourri dans mes fichiers de conf.

Le « flapping » et la volatilité d'un service sont bien deux choses très distinctes.

[kuroro]

Le « flapping » et la volatilité d'un service sont bien deux choses très distinctes.

Donc il faudra corriger le libellé de "Service Volatile" dans les prochaines version d'Oreon.

[surcouf]

Donc il faudra corriger le libellé de "Service Volatile" dans les prochaines version d'Oreon.

Pense à ouvrir un bogue sur flyspray.

[artfakt]

Ce n'est peut etre pas ce que tu souhaites, mais pour revenir à la base du problème, une solution alternative serai de configurer ton équipement pour renvoyer une trappe OK quand le PB est résolu. C'est ce qui se fait habituellement.

[surcouf]

Ce n'est peut etre pas ce que tu souhaites, mais pour revenir à la base du problème, une solution alternative serai de configurer ton équipement pour renvoyer une trappe OK quand le PB est résolu. C'est ce qui se fait habituellement.

Tu ne dois pas connaître grand chose à SNMP.
Encore faut-il que l'agent soit conçu pour émettre une TRAP lorsque le problème est résolu mais cela reste rare.

[artfakt]

Quel acceuil pour les gens qui veulent apporter un peu d'aide, bravo surcouf, pire que mon caissier a carrouf

Je monitore pourant plusieurs types d'équipements, allant jusqu'a de très bon loadbalancers, et ils fonctionnent pourtant comme cela. désolé de ne pas connaitre tous les équipements du marché,

désolé pour le jour ou tu aurras besoin d'aide

fin

[surcouf]

Quel acceuil pour les gens qui veulent apporter un peu d'aide, bravo surcouf, pire que mon caissier a carrouf

Bonjour la rime et l'ad hominem.

Je monitore pourant plusieurs types d'équipements, allant jusqu'a de très bon loadbalancers, et ils fonctionnent pourtant comme cela. désolé de ne pas connaitre tous les équipements du marché,

Avec les SUN ILOM (Insight Light-Out Manager), qu'on trouve notamment sur les SunFire X4200, ont également un agent SNMP qui supporte une MIB nommée SUN-PET-ILOM-EVENTS-MIB et dans laquelle il est effectivement défini à la fois les alertes sur incidents mais également à la fin de l'alerte.
Le simple fait que ce ne soit pas un cas général ne te permet pas de supposer que tous les agents se comporteront de la même manière. Dans un tel cas, il vaut mieux définir une commande qui sera exécuté dans un délai dit « de fraîcheur (freshness) », qui n'est pas un check actif classique.
Personne ne connait tous les équipements et agents SNMP disponibles sur le marché mais avant mon actuelle régie, j'ai passé plus d'un an à réaliser des prestations de livraisons de plate-formes de supervision pour divers clients, grands comptes comme administrations. Je peux t'affirmer que ta solution alternative n'a rien d'habituel.

[artfakt]

Dans ce cas, désolé pour le :
C'est ce qui se fait habituellement.
Je ne connais que le premier type d'équippements, et souhaitais simplement apporté une solution alternative. sans plus

Coté acceuil, c'est mieux, avec moins d'arrogance et un peu d'explications

[kuroro]

Merci en tout cas à vous 2 pour votre aide et participation :

Surcouf : je vais ouvrir un bogue sur flyspray. Je suis quand même étonné que personne n'ai remarqué ça avant. Pour les utilisateurs confirmés, ça devrait sauter aux yeux ;)

Artfakt : Merci pour ta solution, mais il y a beaucoup trop d'équipements à monitorer, de type différents, et surtout, administrer par des personnes différentes. En plus, étant un noobs en SNMP, tout comme en Oreon/ Nagios, je ne vais pas me lancer dans des manipulations encore plus complexes :)

Autre chose qui n'a rien a voir : quelqu'un d'entre vous connait-il un document ou je trouverais les traps "intéressantes" à recevoir par type d'équipements? Quand je dis intéressantes, je veux dire indispensables, ou très utiles.

par exemple, j'ai fait un test sur un switch, ou je lui demande d'envoyer des traps pour tous les types d'évènements préconfigurés. Résultat, je suis bombardé de trap ! Donc j'aimerai affiner tout ça.

Encore merci pour votre aide.

[surcouf]

Merci en tout cas à vous 2 pour votre aide et participation :

Surcouf : je vais ouvrir un bogue sur flyspray. Je suis quand même étonné que personne n'ai remarqué ça avant. Pour les utilisateurs confirmés, ça devrait sauter aux yeux ;)

Artfakt : Merci pour ta solution, mais il y a beaucoup trop d'équipements à monitorer, de type différents, et surtout, administrer par des personnes différentes. En plus, étant un noobs en SNMP, tout comme en Oreon/ Nagios, je ne vais pas me lancer dans des manipulations encore plus complexes :)

Autre chose qui n'a rien a voir : quelqu'un d'entre vous connait-il un document ou je trouverais les traps "intéressantes" à recevoir par type d'équipements? Quand je dis intéressantes, je veux dire indispensables, ou très utiles.

par exemple, j'ai fait un test sur un switch, ou je lui demande d'envoyer des traps pour tous les types d'évènements préconfigurés. Résultat, je suis bombardé de trap ! Donc j'aimerai affiner tout ça.

Encore merci pour votre aide.

Malheureusement non, c'est à toi de définir la pertinence des TRAP émises.
Heureusement, les MIB peuvent te permettre de savoir à quoi elles correspondent.