Les métriques dans Shinken
Shinken Entreprise effectue un certain nombre de vérifications sur des hôtes et clusters, appelées "checks". Chaque check peut lors de son exécution extraire une donnée de performance qui est ensuite traitée par Shinken. Ces données peuvent être de tous types:
- Un check "Memory" sur une machine Linux peut par exemple remonter des métriques comme la quantité de mémoire utilisée, de mémoire libre et de mémoire totale
- Un check sur un switch peut remonter les statistiques de transfert des différentes interfaces réseau
- Un check sur une application peut par exemple remonter le nombre d'utilisateurs actuellement sur l'application, le nombre de nouveaux utilisateurs sur la journée, etc...
Les métriques sont présentées par des nombres flottants, qui pourront être ensuite consultés sous forme de graphes dans une interface.
Stockage des métriques
Dans Shinken Entreprise, les métriques sont stockées dans une base de données Graphite (https://graphiteapp.org/).
Les données de métrologie sont enregistrées dans Graphite par l'intermédiaire du module "Graphite-Perfdata", placé sur le Broker. Le Broker envoie les données au démon carbon (partie de Graphite), qui gère le stockage de ces données.
Les métriques sont physiquement rangés dans le répertoire "/opt/graphite/storage/whisper"
Consultation des métriques
Interface de visualisation
L'accès aux métriques via l'interface de Visualisation est par défaut disponible et ne demande pas de configuration de la part de l'utilisateur.
Les métriques sont accessibles de 2 manières différentes:
- Dans un tableau de bord, avec le Widget Graphique
- Directement sur un hôte/cluster ou un check dans l'Onglet Graphes
Pour accéder aux métriques stockées dans Graphite, Shinken utilise Apache. Lorsqu'un utilisateur dans l'interface de Visualisation demande la visualisation d'une métrique, l'interface Web requête Graphite via Apache pour récupérer la métrique demandée.
|
Dans le cas d'une architecture complexe avec plusieurs royaumes, il peut y avoir plusieurs serveurs de stockage des métriques. Dans ce cas, l'interface de Visualisation trouve automatiquement le serveur Graphite à interroger pour renvoyer les métriques demandées.
|
Outils externes
Ouvrir l'accès à Graphite aux outils externes
Par défaut, par mesure de sécurité Graphite est accessible seulement localement. Un serveur externe qui envoie une requête à Graphite se verra refuser l'accès.
Pour autoriser des serveurs externes à accéder à Graphite, il faut modifier la configuration d'Apache qui est responsable de la mise à disposition de Graphite au monde extérieur:
<VirtualHost 127.0.0.1:80> à remplacer par Listen PORT <VirtualHost ip_interface:PORT> |
avec:
- ip_interface à remplacer par l'adresse de l'interface sur laquelle faire l'écoute. Par défaut l'écoute n'est faite que sur l'interface locale (127.0.0.1). Utiliser * pour écouter sur toutes les interfaces
- PORT: Port d'écoute à utiliser. La directive "Listen" n'est pas obligatoire si le port par défaut 80 est utilisé.
Plus d'informations sont disponibles sur les possibilités de configuration d'Apache sur la page de documentation suivante: https://httpd.apache.org/docs/2.4/en/bind.html
Correspondance ID → Nom de l'élément
Shinken utilise l'UUID de l'élément (hôte/cluster/check) pour l'identification des métriques. Cette identification par un ID unique permet de conserver les métriques lors d'un renommage de l'élément.
- Mais les outils externes accédant à Graphite ( par exemple Grafana ) ne sont pas tous capables de comprendre la correspondance NOM→ID.
- Pour résoudre ce problème, Shinken a mis une passerelle pour ne pas perturber les outils externes.
- Par défaut les appels à Graphite renvoient les noms comme clef des métriques au monde extérieur.
- Le broker et ses modules interrogent graphite avec un paramètre additionnel qui permet d'accéder aux métriques via les UIID.
Graphite a besoin de mettre à jour sa table de correspondance des noms pour les nouveaux checks et hôtes et dans le cas des renommages.
- Cette correspondance est contenue dans la base de données Mongo , dont l’accès est configuré dans Graphite dans le fichier /opt/graphite/conf/mongodb.conf.
- Cette recherche n'est faite que si une requête par nom est demandée à graphite et que la table n'est plus à jour.
| Nom de clé | Valeur par défaut | Description |
|---|---|---|
URI | mongodb://localhost/?w=1&fsync=false | URI du serveur Mongo |
DATABASE | shinken | Nom de la base SLA sur le serveur Mongo |
L'adresse de la base Mongo à utiliser est l'adresse de la machine qui contient la base des SLA.
Droits d'accès aux métriques
Pour la lecture des métriques, Graphite se base sur Apache pour fournir un service Web facilement utilisable par d'autres logiciels. Pour avoir le droit de lire les métriques, il faut alors que le dossier de stockage des métriques /opt/graphite/storage/whisper et ses fils soient possédés par l'utilisateur et le groupe Apache (apache:apache).
Lors de manipulation manuelles sur ces emplacements disques parfois volumineux, il arrive que les droits de /opt/graphite/storage/whisper soient modifiés par le système, ce qui empêche la lecture des métriques par Graphite et par conséquent par Shinken (permission refusée par le système).
Les commandes suivantes permettent de rétablir les droits nécessaires:
chmod -R 0755 /opt/graphite/storage/ /var/log/graphite chown -R apache:apache /opt/graphite/storage/ /var/log/graphite |
Migration des données entre la version 2.04.00 et 2.05.00
Stockage des métriques en 2.04.00 et 2.05.00 (et plus)
La différence principale entre les versions 2.04.00 et les versions suivantes (2.05.00 et plus) se situent dans ce qui est envoyé/enregistré par le daemon Graphite:
- nom d'hôtes / nom de Checks / nom de métriques pour la 2.04.00
- uuids d'hôtes / uuids de checks / nom de métriques pour la version 2.05.00
La raison de ce changement concerne la possibilité depuis la 2.05.00 de renommer les hôtes et/ou les checks sans perdre les métriques associés aux éléments, ce qui n'était pas faisable en 2.04.00.
Migration automatique
En version 2.05.00 et supérieures, le module d'envoi des métriques (sur le broker ) vers Graphite s'assure à son démarrage ( avant d'envoyer les métriques donc ) que le daemon graphite a bien migré les données si besoin de leur anciens noms vers le nouveau (en uuids).
- Pour cela, il contacte Graphite (via son application Web, donc sur le port HTTP/80 de Graphite via Apache )
- et lui envoie une table de correspondante: nom (hôte ou check) → uuid.
Graphite vérifie alors que s'il a encore de données répertoriées avec le nom, il les renomme en tant qu'uuids (il n'y a pas de copie de données, seuls les répertoires sont renommés via le processus de graphite ).
Le module s'assure de cela à chaque démarrage au cas où:
- un ancien backup de métrologie était restauré;
- si un hôte/check était désactivé lors du premier lancement de la version 2.05.00 mais qu'il a été réactivé depuis
Cette opération reposant uniquement sur un listing et un déplacement de répertoire, elle est extrêmement rapide et n'impacte pas les performances du serveur Graphite.