Surveillance de la temperature des disques avec Zabbix

Je cherchais un moyen de suivre la température de mes disques durs  et je suis tombé sur cet article.

http://virtuallyhyper.com/2013/10/monitor-smart-attributes-zabbix/

Dans l’ensemble, il est encore à jour. J’ai juste rencontré un souci avec le script perl qui doit renvoyer les informations sur les disques.

Le programme ne renvoyait pas une liste au format json.
J’ai dû modifier la ligne suivante:

par

Ce qui me permet de voir l’évolution de la température des disques dans Zabbix (Je le faisais déjà sous cacti et je trouvais que ça manquait sou Zabbix).

temp

L’article source permet aussi de surveiller le nombre de secteur ré alloué et lever une alerte préventive lorsque le disque commence à défaillir.

 

Netstat, a quoi ca sert

Je parle de netstat dans le dernier article mais à quoi ça sert ?

netstat permet d’avoir des informations sur les connexions réseaux dans un système linux.

ex : pour connaître les ports en écoute

On peut voir ici qu’un server ssh est lancé (22 est le port par defaut pour le ssh).

Un autre cas d’utilisation qui peut être utile, c’est de savoir qui occupe un port particulier.

Le résultat est sshd, il s’agit bien du process daemon pour un serveur ssh.
NB: pour utiliser cette dernière commande, il faut utiliser sudo ou etre root pour avoir accès à tous les processus.

Netstat a d’autres usages, il s’agit là des deux principaux que j’utilise au quotidien.

Mon disque est rempli de snapshots

En analysant l’espace disque d’un serveur, je me suis aperçu que sur notre nexus (repository manager) nous avions un historique assez impressionnant de snapshot. En effet, nous avions tous les builds depuis près de 4 ans à raison d’un build par jour. Cela occupait pas moins de 700Go.

Lire la suite

Une appli android pour le fun… mais pas seulement

Nous avons vu dans le précédent article (qui commence à daté un peu) que Zabbix nous permettait de catégoriser nos serveurs et de faire des interrogations facilement via son api REST.

Et si on s’en servait pour piloter des caméras vidéos de Rasperry Pi? On va enregistrer les serveurs sous Zabbix et créer une application android pour allumer et éteindre les caméras mais aussi voir le flux vidéo.

Pour configurer les caméras, je me suis basé sur cet article. Il est plutôt bien fait et encore à jour.

J’ai juste ajouté un agent zabbix sur la machine afin que la machine remonte dans l’inventaire.

Sur le serveur Zabbix, j’ai déclaré mes cameras dans un groupe « original » nommé cameras.

Il ne reste plus qu’a développer l’application mobile.

Dans un premier temps, je défini un écran de préférence qui permettra de renseigner l’adresse du serveur Zabbix (il faut bien un point de départ pour collecter l’information).

preference

Dans cette fenêtre, on peut aussi définir
– le login et le mot de passe pour se logguer aux caméras.
– Le nom du SSID du wifi de la maison. Cela permet de choisir le type de connexion pour se connecter aux serveurs.
– Les informations d’une passerelle pour se connecter aux caméras de l’extérieur.

Une fois ces informations renseignées, il ne reste plus qu’a interroger le serveur zabbix, pour récupérer les différents serveurs

list

Une fois la liste des serveurs établies, on peut cliquer sur un élément pour voir son détail:

détail

Sur cette fenêtre, on pourra connaître l’état de la caméra (On / OFF) et changer le statut si besoin. Dans ce cas, l’application lancera une commande ssh pour arrêter le service motion sur le rasperry PI.

Le bouton Voir permet de consulter le flux vidéo. Il va lancer firefox et afficher le flux de la caméra.

Il suffit juste de lancer un Intent avec la bonne url:

Le code source est ici si vous voulez approfondir le sujet.

J’ai volontairement laissé de côté l’aspect connections depuis l’extérieur. Cela fera peut être l’objet d’un prochain article.

 

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.

Zabbix Agent

Voyons maintenant comment configurer un agent Zabbix pour monitorer un nouveau serveur.

Il suffit d’installer le package zabbix-agent

et de faire un peu de configuration

On redemarre l’agent

Il faut ensuite l’ajouter dans la configuration de zabbix:

Configuration -> hosts -> New hosts.

Dans cette ecran, il ne faut pas oublier d’ajouter un template:

template

 

Au bout de quelques instants, vous devriez voir dans les logs (comme précédemment):

Et voila, il ne reste plus qu’a ajouter le monitoring sur les autres serveurs.