Page History

Introduction

Grafana est une plateforme permettant de créer des tableaux de bord de visualisation pour les métriques. Dans ces tableaux de bord, la création de différents types de widget et de nombreuses options sont disponibles pour la visualisation des métriques.

Plus de détails sont disponibles sur le site officiel : https://grafana.com/

Installation

L'installation de Grafana sous CentOS se fait via un paquet RPM. La version de Grafana testée avec Shinken Entreprise est la v8.3.2-1.

Pour l'installer, utiliser la commande suivante:

yum install --nogpgcheck https://dl.grafana.com/enterprise/release/grafana-enterprise-8.3.2-1.x86_64.rpm

Une fois l'installation terminée, lancer Grafana et configurer son lancement automatique au démarrage du système avec les commandes suivantes :

systemctl enable grafana-server
systemctl start grafana-server

Après avoir installé puis lancé Grafana, l'interface sera accessible sur le port 3000. Les identifiants par défaut sont admin/admin

Connexion avec Graphite

Pour pouvoir récupérer les métriques générées par Shinken et enregistrées dans Graphite. Grafana doit avoir accès à Graphite. Pour cela, il faut ajouter dans Grafana une source de données Graphite.

Dans l'interface, allez dans la catégorie Data Sources , puis ajoutez une nouvelle source de type Graphite, qui sera paramétrée comme ci-dessous:

• URL: adresse du serveur hébergeant Graphite, sur le port 80. Par exemple: 

  No Format
  http://localhost:80

• HTTPS: si Graphite est configuré en HTTPS, alors il faut adapter l'URL

  No Format
  https://localhost:443

• Version: La version de Graphite utilisée dépend de la version de Shinken Enterprise:

  • Avant la version V02.08.02-RC012, il faut choisir 0.9.x

    Panel

• • Après la version V02.08.02-RC012, il faut choisir 1.1.x

    Panel

Si Grafana est installé sur un serveur différent du serveur Graphite, il faudra effectuer une étape de configuration supplémentaire. Par défaut, Graphite autorise seulement les connexions locales.

Pour permettre à des serveurs distants d'accéder à ses données, il faut le fichier de configuration Apache de Graphite /etc/httpd/conf.d/graphite.conf :

• Changer la ligne :

  Code Block
  language js theme Confluence
  <VirtualHost 127.0.0.1:80>

• En :

  Code Block
  language js theme Confluence
  <VirtualHost 0.0.0.0:80>

  Cette ligne permet de spécifier les interfaces réseau de la machine sur lesquelles effectuer l'écoute. Spécifier 0.0.0.0 ou * permettent d'écouter sur toutes les interfaces réseau. On peut mettre une seule interface à la place en spécifiant l'IP de l'interface réseau concernée.
  
  

• Redémarrer Apache pour prendre en compte les modifications

  Code Block
  language text theme Emacs
  systemctl restart httpd

Gestion des certificats SSL/TLS par Grafana

openssl x509 -in graphite.cert -text -noout

• Il est possible que la version de Grafana refuse les certificats qui utilisent uniquement le champ 'Common Name' (CN) pour identifier le propriétaire du certificat ( C'est le cas de la version de Grafana que Shinken recommande ).
  Dans ce cas, Grafana enregistrera l'erreur suivante dans le fichier /var/log/grafana/grafana.log : "proxy error: x509: certificate relies on legacy Common Name field, use SANs instead".
  
  • Pour résoudre ce problème, le certificat Graphite doit impérativement utiliser le champ 'Subject Alternative Name' (SAN) pour identifier le propriétaire du certificat.

• Si l'adresse IP ou le nom de domaine (DNS) de l'URL de la source de données n'est pas inclus dans la liste des machines certifiées par le certificat ( par exemple si l'URL de la source de données est localhost alors que le certificat a été émis pour le nom ou l'adresse IP de la machine )  Grafana refusera alors la connexion. Dans ce cas, Grafana enregistrera l'erreur suivante dans le fichier journal /var/log/grafana/grafana.log : "proxy error: x509: certificate is valid for XXXX, not XXXX".

  • Pour résoudre ce problème, il est nécessaire de modifier l'URL de la source Graphite dans Grafana pour qu'elle corresponde aux adresses utilisées par le certificat

• ll est enfin possible que la version de Grafana refuse le certificat de Graphite s'il est signé par une autorité inconnue.
  Dans ce cas, Grafana enregistrera l'erreur suivante dans le fichier /var/log/grafana/grafana.log : "proxy error: x509: certificate signed by unknown authority".
  On peut résoudre ce problème de deux manières :
  

  • Ajouter le certificat de Graphite ou celui de l'autorité de certification à la liste des certificats de confiance du système. . Pour ce faire, on peut ajouter le certificat dans  /etc/ssl/certs/ca-bundle.trust.crt, puis redémarrer Grafana. 

    Code Block
    language text theme Emacs
    cp your_certificate.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust

    Code Block
    language text theme Emacs
    systemctl restart grafana-server

  • On peut également ajouter le certificat de la source de données Graphite directement depuis l'interface de Grafana. Cette méthode peut être plus pratique si on ne souhaite pas modifier les fichiers de configuration du système.

    Panel

L'installation et la connexion de Grafana avec Graphite sont maintenant terminées.

On peut désormais créer des tableaux de bord, ajouter des utilisateurs et permettre la visualisation des métriques de Shinken.

Intégration dans Shinken

Par défaut, cette version n'accepte pas d'être intégrée dans un widget page web ( pour plus de détail sur la configuration du widget voir la page : Widget Page web ).

Pour l'activer, il faut éditer le fichier de configuration Grafana /etc/grafana/grafana.ini dans la section "[security]":

allow_embedding = true

Puis redémarrer Grafana

systemctl restart grafana-server

Créer un tableau de bord (dashbord)

Pour créer un tableau de bord,

1. Cliquer sur le "+", "Create", puis "Add new panel".
   
   

   Panel

    chown apache:apache /opt/graphite
   
   

2. Définir un nom dans le menu de droite. Dans la partie basse de l'écran, il y a la composition de la requête.
   Pour générer un graphe, il faut cliquer sur "select metric", puis ajouter la métrique souhaitée.
   
   

   Panel

    
   
   

3. Il faut sélectionner l’intervalle de visualisation.
   
   

   Panel

    
   

Une fois terminé, le bouton "Save" en haut à droite, va sauvegarde le panneau dans le tableau de bord. Le nom inscrit sera le nom du tableau de bord qui peut être composé de plusieurs panneaux.

Récupération de l'URL à intégrer dans Shinken

Pour centraliser la visualisation des éléments supervisés par Shinken, il est possible d'intégrer les tableaux de bord Grafana dans un tableau de bord Shinken en utilisant le widget page web ( voir la page Widget Page web ).

Par exemple :

1. Allez sur le panneau et cliquer sur share :
   
   

   Panel

    
   
   

2. Dans l'onglet "Embed", sélectionner le line comme ci-dessous :
   
   

   Panel

    
   
   Pour obtenir un graphique évolutif en temps réel, remplacer dans le lien, toute la partie "from=XXXX&to=XXXX" par "from=now-6h&to=now" pour avoir un intervalle de 6h de visualisation.
   
   

3. Copier ce lien dans le widget Page web.
   
   Exemple :
   
   

   Panel

    
   
   
   

   No Format
   http://adresse_serveur:3000/d-solo/sLWNXIsMk/synchronizer?orgId=1&from=now-6h&to=now&panelId=2

   
   Décomposition de l'adresse :
   
   

   Paramètre	Définition
   adresse_serveur	Adresse IP / Nom DNS du serveur
   3000	Port par défaut de Grafana
   d-solo	Permet de cacher les barres de navigation de Grafana pour n'afficher que les éléments visualisés
   synchronizer	Nom du tableau de bord
   from=now-6h	Intervalle d'affichage du graphes sur 6h
   to=now	Intervalle jusqu'à maintenant
   panelId=2	Numéro du panneau dans le tableau de bord

   
   

Passage en HTTPS

Dans le fichier de configuration de Grafana ( /etc/grafana/grafana.ini ),

Ajoutez :

protocol = https
cert_file = /chemin/vers/server.cert
cert_key = /chemin/vers/server.key

Puis redémarrer Grafana :

• Sur CentOS 7 et RedHat / AlmaLinux 8:

  Code Block
  language text theme Emacs
  systemctl restart grafana-server

Lien vers le mapping nom→uuid nécessaire pour Grafana, et suivi des requêtes

Les métriques stockées dans Graphite utilisent l'UUID des éléments comme clé.

• L'Interface de Visualisation de Shinken va utiliser les UUID pour ses échanges avec Graphite.
• Les outils externes qui échangent avec Graphite comme Grafana vont utiliser le nom des éléments.
  • Cela implique que Graphite possède une table de correspondance UUID ↔ nom pour répondre aux outils externes.

• Cette correspondance est fournie par le serveur d'inventaire ( ce serveur est un composant du module de métrologie du Broker de Shinken ).
  • La configuration de Graphite pour l'accès au serveur d'inventaire se fait via le fichier /opt/graphite/conf/shinken_inventory.conf   
• Si la table de correspondance n'est plus à jour et qu'une requête par nom est demandée à Graphite, alors Graphite va faire la demande d'une nouvelle table de correspondance au serveur d'inventaire.
• Lorsqu'une nouvelle configuration de Shinken est déployée, le serveur d'inventaire envoie une notification à Graphite pour que l'inventaire soit modifié.
  • Afin que tous les processus de Graphite/Apache soient mis au courant, le fichier /opt/graphite/storage/whisper/.cacheinvalidation  est mis à jour
    • Ce fichier ne doit pas être modifié.
    • En cas de problème, il est recréé, et le cache vidé.

Les logs de chargement de la table de correspondance UUID ↔ nom sont disponibles dans le fichier /opt/graphite/storage/log/webapp/info.log

Pour suivre la mise à jour du mapping nom → uuid et les requêtes pour un hôte particulier, il suffit de remplir le fichier /opt/graphite/storage/whisper/.apache_graphite_host_filter_log avec le nom de l'hôte. Les mises à jour dans la table de correspondance le concernant, ainsi que les requêtes de recherches de métriques seront toutes disponibles dans le fichier de log.

Paramètres de connexion aux serveurs d'inventaire

• Graphite se base sur les informations du fichier /opt/graphite/conf/shinken_inventory.conf pour aller chercher les informations qui lui permettront d'assurer la correspondance entre les noms et les UUID

ENABLE

URI

TIMEOUT

service httpd restart

Autoriser les connexions aux serveurs d'inventaire

Configurer les modules de métrologie Graphite

Si le serveur Graphite et les Brokers avec les modules de métrologie Graphite sont sur des machines différentes, il faut configurer le serveur d'inventaire des modules de métrologie Graphite pour

• écouter sur les IP publiques de leur machine,

Pour cela, sur le serveur de l'Arbiter, éditer les fichiers de configuration des modules Graphite et décommenter la ligne du paramètre

broker__module_graphite_perfdata__inventory_server__address  0.0.0.0

( pour passer sa valeur de 127.0.0.1 à 0.0.0.0 )

• définir à qui envoyer les modifications de l'inventaire

broker__module_graphite_perfdata__inventory_push__url  http://IP_GRAPHITE/migrate

Ouvrir le port du serveur d'inventaire sur le firewall ( firewalld )

Si le serveur d'un Broker qui fait tourner le module de métrologie Graphite dispose d'un firewall ( firewalld par défaut sur les systèmes Redhat et dérivés ), la commande suivante permet d'obtenir la liste des ports autorisés

firewall-cmd --list-ports

80/tcp 7763/tcp 7765/tcp 7766/tcp 7767/tcp 7768/tcp 7769/tcp 7770/tcp 7771/tcp 7772/tcp 7773/tcp 7777/tcp 7780/tcp 50000/tcp

Dans cet exemple, le port 52000/tcp ( port par défaut du serveur d'inventaire du module de métrologie Graphite ) n'est pas listé, il est donc bloqué par défaut

Les commandes suivantes, à lancer sur le serveur du Broker,  permettent d'autoriser les connexions :

firewall-cmd --add-port=52000/tcp
firewall-cmd --runtime-to-permanent

Compatibilité historique

Mode de fonctionnement avant la version de Shinken :

• V02.08.02-RC012
• ou V02.08.01.03

En cas d'impossibilité d'accès au serveur d'inventaire des modules de métrologie ( ports bloqués, paramètres par défaut incompatibles avec la configuration, la version installé est la version V02.08.02-RC012,... ), Graphite peut utiliser l'ancienne méthode que Shinken avait déployé pour fournir ces informations avec MongoDB.

• L’accès est configuré dans Graphite dans le fichier /opt/graphite/conf/mongodb.conf.

L'accès via MongoDB est déprécié et est voué à disparaître.

En effet, Graphite ne peut consulter qu'une seule base MongoDB pour obtenir les correspondances de noms, il est ainsi obligé d'utiliser la base centrale, qui est souvent aussi la plus chargée.

Configuration de l'accès à MongoDB

Connexion vers un cluster MongoDB

Pour se connecter à un cluster MongoDB, il faut configurer un démon mongos ( voir page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ) sur les serveurs  stockant les métriques, et s'y connecter pour accéder au cluster.

Connexion vers un démon mongod

Pour se connecter au serveur MongoDB, deux méthodes sont disponibles:

• Connexion directe: Par défaut, mais non sécurisée.
• Tunnel SSH: Shinken se connecte au serveur Mongo au travers d'un tunnel SSH pour plus de sécurité

Connexion directe au serveur MongoDB

Par défaut, Graphite se connecte de manière directe au serveur MongoDB pour y lire et écrire sa table de correspondance.

Dans la configuration de Graphite, on sait que la connexion se fait de manière directe lorsque le paramètre "USE_SSH_TUNNEL" est à 0.

Cette méthode de connexion a pour avantage d'être facile à configurer au niveau de Shinken. Par contre, elle oblige à permettre l'accès à la base MongoDB au monde extérieur, et donc s'exposer à des problèmes de sécurité.

• La sécurisation de la base MongoDB est bien sur toujours possible ( voir la page Sécurisation des connexions aux bases MongoDB ) mais bien plus complexe à mettre en place.
• La méthode de connexion par SSH est donc préférable pour des raisons pratiques et de sécurité.

Connexion par SSH au serveur MongoDB

Graphite peut également se connecter au serveur MongoDB par tunnel SSH ( pour des raisons de sécurité ).

• En effet, le paramétrage de MongoDB ( /etc/mongod.conf ) permet de définir sur quelle adresse ce dernier écoute les requêtes.
  • En n'autorisant seulement l'adresse 127.0.0.1, cela évite d'ouvrir la base au monde extérieur.
    • Dans la configuration du serveur MongoDB (/etc/mongod.conf ), il faut que le paramètre "bind_ip" est positionné pour n'écouter que sur l'interface locale:
bind_ip= 127.0 . 0.1

Comme toutes les connexions vers MongoDB, il est possible, et même recommandé, de sécuriser la communication via un tunnel chiffré SSH.

Le paramétrage de la connexion à MongoDB depuis Graphite, se fait en éditant les options suivantes ( dans /opt/graphite/conf/mongodb.conf ):

URI

DATABASE

DATABASE_USERNAME

DATABASE_PASSWORD

DATABASE_SSL

DATABASE_SSL_CA_FILE

DATABASE_SSL_PEM_KEY_FILE

DATABASE_SSL_PEM_KEY_PASSWORD

DATABASE_SSL_CRL_FILE

DATABASE_SSL_ALLOW_INVALID_HOSTNAMES

DATABASE_SSL_ALLOW_INVALID_CERTIFICATES

COLLECTION

USE_SSH_TUNNEL

SSH_USER

SSH_KEYFILE

SSH_TUNNEL_TIMEOUT

service httpd restart

Graphite étant hébergé par le service apache, il n'a pas accès au répertoire /var/lib/shinken et il n'a donc pas accès à la clé SSH /var/lib/shinken/.ssh/id_rsa. C'est pour cette raison que la clé SSH utilisée pour le tunnel est situé dans /opt/graphite/conf/id_rsa.

Deux solutions sont disponibles :

• Générer une nouvelle clé SSH pour apache / graphite ( voir la page Création automatique et gestion de la clé SSH de l'utilisateur shinken )
  
  • Lors de la génération de la clé, il est possible de spécifier directement le chemin suivant : /opt/graphite/conf/id_rsa
  • Il faudra ajouter cette nouvelle clé publique ( /opt/graphite/conf/id_rsa.pub ) sur le/les serveurs MongoDB ( dans le fichier ~shinken/.ssh/authorized_keys  )
  • Cette clé sera indépendante et non impactée par un changement de clé SSH sur l'utilisateur "shinken".
    
    
• Utiliser la clé SSH de l'utilisateur "shinken" présent sur le serveur.
  • La clé publique est sûrement déjà présente sur les serveurs MongoDB.

  • Il faut copier la clé privée et changer les droits pour l'utiliser et la maintenir à jour en cas de changement.

    Code Block
    language text theme Emacs
    cp /var/lib/shinken/.ssh/id_rsa* /opt/graphite/conf/ chown apache:apache /opt/graphite/conf/id_rsa

Mise à jour d'une version supérieure à 5.4.0

Il faut simplement lancer la commande suivante :

yum update https://dl.grafana.com/enterprise/release/grafana-enterprise-X.X.X.x86_64.rpm

Pour la partie intégration avec le widget web de Shinken, si le paramètre "allow_embedding" ne se trouve pas dans le fichier /etc/grafana/grafana.ini, on peut l'ajouter dans la section "[security]" de ce fichier :

[security]
allow_embedding = true

Redémarrer grafana :

systemctl restart grafana-server

 Une fois Grafana mis à jour, il suffit de rafraîchir la page et de s'authentifier

Authentification avec le widget Page Web

Pour fonctionner avec le widget Page web, Grafana va nécessiter un paramétrage spécifique ( voir la page Widget Page web ).

• L'authentification se fait avec des cookies.
• Dans les dernières versions de Chrome/Edge ( Firefox n'est pas concerné ), l'utilisation de requête "cross-site" par un cookie n'est plus autorisé.
• Cela signifie que si l'application n'est pas installée sur le même serveur que la WebUI de Shinken, l'authentification depuis le widget Page Web ne fonctionnera pas.

Pour palier à ce problème, on peut utiliser HAProxy ( Version 1.5.18 ) pour récupérer le flux de ce site et simuler sa présence sur le serveur où est installé la WebUI.

Configuration

Pour afficher les graphes d'un Grafana qui n'est pas installé sur le serveur où se trouve la WebUI Shinken. Il faut installer HAProxy sur chacun des serveurs où ces graphes doivent être affiché dans le widget Page Web.

yum install haproxy

Ajouter une exception dans SELinux pour HAProxy:

setsebool -P haproxy_connect_any=1

Modifier le fichier de configuration /etc/haproxy/haproxy.cfg et le remplir avec ces informations :

#---------------------------------------------------------------------
# Example configuration for a possible web application.  See the
# full configuration options online.
#
#   http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen  grafana
  bind    SERVEUR_WEBUI:3000
  server    SERVEUR_GRAFANA SERVEUR_GRAFANA:3000

Démarrer HAProxy

systemctl enable haproxy
systemctl start haproxy

On peut ajouter l'URL suivante dans le widget Page Web : http://SERVEUR_WEBUI:3000/XXXXXXX mais pas http://SERVEUR_GRAFANA:3000/XXXXXXX La première authentification est nécessaire.

Log HAProxy

Par défaut HAProxy n'a pas de fichier de log. 

Pour en générer un il faut :

• Éditer le fichier /etc/rsyslog.conf et décommenter les lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

• Créer et ajouter dans le fichier /etc/rsyslog.d/haproxy.conf :

local2.* /var/log/haproxy.log

• Redémarrer rsyslog et haproxy :

systemctl restart rsyslog
systemctl restart haproxy