Message d'erreur dans le log

Bonjour

Une idée sur l’origine probable de ce genre de message qui revient régulièrement dand le log du moteur ? : « webserver_1 | AttributeError: ‹ HeartBeat › object has no attribute ‹ name › »

Pourquoi n’y t-il pas de date sur l’erreur ? (ce n’est pas le seul message du moteur non daté). Je n’arrive pas à retrouver où il pourrait y avoir un objet nommé « HeartBeat » avec cette orthographe et où on ferait appel à un attribut « name »
Au passage, j’ai mis ce sujet dans le moteur heartbeat mais il correspond plus à webserver, mais la catégorie n’existe pas (enfin il ne me semble pas mais je l’ai peut-être râtée), serait-il possible de la créer ?

Bonjour,
peux tu nous dire quelle action provoque ce log ?

Bizarrement des tests que j’ai réalisé ces messages ne sont pas liés à une action particulière mais plutôt un intervalle régulier. J’ai essayé de jouer avec l’interface mais cela ne provoque pas l’erreur. Et je dirai que l’intervalle est d’environ 3 à 5 minutes.

Dans ce cas, peux tu fournir le contenu des règles de heartbeat que tu as configurées ?
Pense à anonymiser si nécessaire.

Je n’ai pas configuré de règles, par contre, j’ai plus de 50 règles qui se sont ajoutées « toutes seules ». C’est celles là que tu as besoin ? Elles contiennent toutes :

  • Un id avec un nom aléatoire
  • un connector, dans notre cas, nagios
  • un connector_name qui corresponds aux noms de nos hosts configurés sur nagios
  • un expected_interval qui est pour quelques unes 360s, deux à 6m et tous les autres à 0s

Tu as besoin de les voir ? (car il faut que j’enlève tous les noms de host dans ce cas là, du coup, elles ne serviront plus à grand chose)

Euh « toutes seules », j’ai comme un doute, permets moi :wink:
Si tu es surpris de voir des règles de heartbeats, j’imagine qu’elles ne te sont pas utiles.
Je te propose éventuellement de dumper la collection et de supprimer ensuite ces règles.
Tu me diras si c’est OK ensuite

Bah ces règles je ne vois pas à quoi elles servent, et on a jamais eu de script qui les renseignent automatiquement, donc du coup c’est pour cela que je pense qu’elles sont apparues à un moment, mais pourquoi ? En tout cas je les ai toutes supprimées, et je vais voir si elles reviennent auquel cas je le mentionnerai sur ce post. Et autre chose, depuis qu’elles sont supprimées, j’ai toujours l’erreur de webserver sur HeartBeat et attribut name… On parle bien de « Heartbeats » sous Exploitation ? et collection « heartbeat » dans mongo ?

Le comportement décrit me fait penser à quelque chose qui tente de créer, via l’API heartbeat, des nouvelles règles de heartbeat. L’erreur dans le log ferait écho au fait que la structure d’une config de heartbeat attend maintenant (entre autres) un attribut « name ».

Dans tous les cas je confirme, comme le dit Mikaël, que les règles de heartbeat n’arrivent certainement pas « toutes seules » dans une instance Canopsis. Installons une instance vierge : il n’y a aucun heartbeat créé, et cela reste ainsi tant que personne ne décide d’en créer !

Il y a obligatoirement, dans votre environnement, un utilisateur ou bien un automatisme quelconque via l’API qui essaye de créer des configs heartbeats au moment où tu as l’erreur dans le log de webserver.

Les règles heartbeat ne reviennent pas donc il a du y avoir quelque chose et ces règles étaient restées, pour rien. Par contre, comme l’erreur revient au niveau de webserver, faudrait-il que je redémarre webserver peut-être. Je vais tenter cela.

Pas mieux après redémarrage de webserver. Par contre, dans le paquet de log de webserver avec l’erreur j’ai tout cela :
webserver_1 | Traceback (most recent call last):
webserver_1 | File « /opt/canopsis/bin/bottle.py », line 868, in _handle
webserver_1 | return route.call(**args)
webserver_1 | File « /opt/canopsis/bin/bottle.py », line 1748, in wrapper
webserver_1 | rv = callback(*a, **ka)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/auth/authkey.py », line 49, in decorated
webserver_1 | return callback(*args, **kwargs)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/auth/ldap.py », line 50, in decorated
webserver_1 | return callback(*args, **kwargs)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/webcore/apps/bottle/app.py », line 79, in decorated
webserver_1 | return callback(*args, **kwargs)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/bottle_swagger/init.py », line 285, in wrapper
webserver_1 | return self._swagger_validate(callback, route, *args, **kwargs)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/bottle_swagger/init.py », line 331, in _swagger_validate
webserver_1 | return callback(*args, **kwargs)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/webcore/services/heartbeat.py », line 71, in create_heartbeat
webserver_1 | heartbeat_id = manager.create(model)
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/heartbeat/manager.py », line 90, in create
webserver_1 | heartbeat = heartbeat.to_dict()
webserver_1 | File « /opt/canopsis/local/lib/python2.7/site-packages/canopsis/models/heartbeat.py », line 70, in to_dict
webserver_1 | self.NAME_KEY: self.name,
webserver_1 | AttributeError: ‹ HeartBeat › object has no attribute ‹ name ›

Ce qui est intéressant c’est juste avant l’erreur et le fichier /opt/canopsis/local/lib/python2.7/site-packages/canopsis/models/heartbeat.py qui contient justement la classe « HeartBeat » et le fameux « name » pour NAME_KEY.

Tu as bien supprimé les règles heartbeat ?

Oui oui il n’y en a plus du tout et rien ne revient, donc c’est bien cela, elles n’étient pas arrivé toutes seules. Par contre, j’ai un gros doute : n’y avait-il pas une règle d’enrichissement pour les heartbeat ce qui expliquerait ces fameuses règles heartbeat, comme j’ai fait du ménages dans les règles d’enrichissement, je n’ai pas de règle heartbeat.

J’ai du mal à te suivre la.
Les règles d’enrichissement n’ont à priori rien à voir avec des règles de heartbeat dans Canopsis.

As tu encore les messages d’erreur coté webserver malgré le « ménage » réalisé ?

Ok je pensais que cela pouvait avoir un rapport, donc ce n’est pas cela. Oui j’ai toujours le message d’erreur dans le log webserver.

La comme ça je parie sur un script externe qui tente d’ajouter des règles heartbeat par l’API et qui ne respecte pas le fait que le « name » soit obligatoire (c’est récent que ce soit obligatoire).

Avec ce pari on explique :

  • Pourquoi tu avais plein de règles heartbeat dont tu n’avais pas connaissance
  • Les logs du webserver

A toi de trouver la source potentielle (tcpdump, accesslog du webserver, etc)

J’ai identifié le problème quand tu as parlé de script qui posterait sur les règles heartbeat, j’ai trouvé la portion de code incriminée (connecteur nagios). Et effectivement, elle n’envoie pas de champs name (ce champs existait dans les versions précédentes ?). D’ailleurs, ce n’est pas le seul champs qui n’étaient pas envoyé. Je pense que des champs ont été ajoutés aux heartbeat au fur et à mesure des sorties de versions. J’ai remis les bons champs conformément à ce qui est attendu par l’api et désormais cela fonctionne bien et les règles de heartbeat sont correctement insérées comme ça devait l’être (besoins internes pour nos satellites nagios d’avoir des règles heartbeat de positionnées sur non réception d’évenement afin de déclencher une alarme). Donc ce sujet est clos. Merci pour votre aide, car ce n’était pas évident à diagnostiquer à la base…

Bonjour,
je poursuis la conversation car je n’ai pas bien saisi une chose.

Tu publies des règles de heartbeat par l’intermédiaire d’un connecteur Nagios ?

De ce fait, avant de publier la règle, vérifies tu son existence ? Si tu as retrouvé > 100 règles dans ton instance, j’imagine que tu ne fais pas cette vérification et que tu insères une règle à chaque lancement peut-être ?

Le mieux serait surement de décrire ton souhait fonctionnel et d’expliquer ce que tu as mis en place pour y parvenir

PS : Le champ « name » a été rendu obligatoire il y a quelques versions

Bonjour

Oui c’est bien cela et oui je vérifie son existence (heureusement… ;-)). Non mais le fait qu’il y en ai eu des tonnes, c’était simplement du à un oubli (un test) à un moment pour ne pas publier des règles sur les hosts, il y a eu une erreur à un moment et les règles étaient restées c’est pour cela qu’il y en avait autant, désormais, il n’y a que quelques règles, pour tout te dire, une par satellite, qui permet de générer une alarme quand un satellite a un soucis et ne renvoie plus d’événements, on utilise déjà depuis fort longtemps ce mécanisme dans BEM :wink: Donc désormais, ce fonctionnement est ok, par contre, la seule chose, c’est qu’actuellement la publication des règles se fait en http et non en amqp, d’ailleurs, je ne suis pas sure que ce soit possible ne amqp mais j’imagine que si je n’ai pas regardé encore.

Les règles sont à publier via HTTP uniquement dans l’API prévue à cet effet.
Le protocole AMQP n’est utilisé que pour publier des événements.

Ah ok, bon donc je n’ai rien à modifier du coup, merci.