Archives mensuelles : septembre 2015

Zabbix et son api REST

Sans trop faire de teasing sur le prochain article, j’avais besoin de récupérer de façon dynamique une liste de serveurs. Je me suis dis que Zabbix pouvait être une bonne solution sachant qu’il est possible de regrouper différent serveur sous la forme de host groups.

J’ai pu découvrir l’API rest de zabbix qui est plutôt simple à utiliser et très bien documenter.

Mon cas d’utilisation va se décomposer en 3 étapes:

  1. Authentification
  2. Récupération du host groups
  3. Récupération des hosts

Authentification

La première étape est de récupéré un token d’authentification. Pour cela,il faut poster une requête JSON de la forme :

avec auth.dat contenant:

Cela nous renvoie une réponse la forme:

La partie importante est la chaîne de caractère qui suit result. Il s’agit du token que l’on va réutiliser pour les appels suivants.

Récupération du host groups

Avant de pouvoir récupérer les serveurs d’un groupe, je dois récupérer l’id de ce groupe. Pour l’instant je ne connais que le nom toto.

On va donc refaire une interrogation. Mais avec le json suivant:

 

On retrouve bien le token d’authentification dans la valeur du champ auth et le nom toto dans la valeur du champ name. Il s’agit d’un filtre sur les hostgroups.

Le résultat va être de la forme:

La partie à conserver est la valeur du groupid. C’est que nous allons utiliser pour la suite.

Récupération des hosts

Maintenant que nous avons l’id du hostgroup, nous pouvons interroger zabbix pour avoir la liste des serveurs de ce groupe:

Le résultat est de la forme:

Et voila, en quelques appels, on peut utiliser zabbix comme un catalogue et récupérer de façon dynamique les différents éléments qui constitue le réseau (domestique ou professionnel).

Mais pourquoi je loggue autant?

La semaine dernière, j’ai trouvé un problème intéressant. Lors de la mise à jour d’une application, celle-ci a commencé à logguer en mode DEBUG de façon aléatoire. Sur certains serveurs tout marchait correctement, mais sur d’autres, non. En apparence, tout semblait normal, le fichier log4j.properties n’avait pas changé.

En regardant les logs, un message à attiré mon attention:

Chose intéressante, sur les serveurs à problème le message était plutôt de ce type:

SLF4j va prendre la première implémentation qu’il trouve. Dans notre cas ce sera logback-classic sur certains serveurs (cela va dépendre du chargement des classes dans le classloader).

Là où le problème arrive c’est que nous ne sommes pas supposés utiliser logback mais plutôt log4j. Nous n’avons pas de fichier de configuration de logback.

En suivant la documentation, voici ce qui se passe:

Nous n’avons aucun de ces fichiers,  donc logback va écrire dans la console. Mais avec quel niveau de logs ? Et bien c’est écrit dans la doc :

C’était donc ca. Un manque de fichier de configuration et notre serveur passe en mode DEBUG.

Mais pourquoi avoir rajouter une telle librairie (logback-classic)?

Ce n’était pas volontaire, c’est une dépendance transitive qui est remontée en ajoutant une autre dépendance à un projet.

conclusion 1: toujours surveiller les dépendances remontées par les librairies

conclusion 2: toujours prêter attention aux messages dans les logs

PS: dans la version 1.6.6, slf4j va indiquer en plus dans les logs, la classe StaticLoggerBinder qu’il utilise. Cela permet de contrôler encore mieux ce qu’il se passe réellement sur le serveur.