| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Introduction
La base de métrologie de Shinken peut être fortement sollicitée sur des architectures supervisant un grand nombre d'éléments. Sa disponibilité est également importante puisqu'elle peut être source de données pour des outils externes à Shinken ( Grafana par exemple ) pouvant être mis à disposition des utilisateurs.
L'objectif de cette page de documentation est d'expliquer de manière détaillée détailler la procédure nécessaire pour la mise en place d'un cluster Graphite. Cela permet Ce qui permettra d'augmenter la disponibilité des données et d'éviter la perte de données en cas d'incident sur la machine stockant les métriques.
Architecture mise en place
Dans une installation Shinken classique, les métriques sont émises par le Broker pour être stockées dans une base de données Graphite par le Broker.
Chaque résultat de vérification contenant des données de métrologie sont analysées est analysé par le Broker. Ces métriques sont enregistrées dans envoyées à Graphite par le Broker grâce au module Graphite-Perfdata.
Dans Du côté de Graphite, le nom du démon responsable de l'enregistrement des métriques sur le disque est est "carbon-cache".
| Panel |
|---|
Pour transformer cette architecture pour dans le but de la rendre hautement disponible, on veut faire en sorte que les données soient seront répliquées lors de leur écriture.
Le On utilise alors le logiciel Keepalived qui permet permettra de créer une adresse IP virtuelle qui, en cas de problème sur le serveur principal, gèrera une bascule sur le serveur secondaire automatiquement. Grâce à l'installation du démon
Des démons "carbon-relay" sur le serveur principale principal ET le serveur secondaire, l'assureront un enregistrement des métriques n'est pas interrompu sans interruption, même en cas de bascule.
L'architecture qu'on obtient obtenue à la fin de la procédure décrite dans cette documentation correspond à celle présente sur le schéma ci-contre.
Notre Le cluster Graphite est constitué d'au moins 2 machines distinctes ( idéalement 3 pour répartir les performances ).
- Le démon "carbon-cache" est sur toutes machine du cluster, ce qui permettra il assurera le stockage des métriques.
- Le démon "carbon-relay" est aussi sur toutes les machines du cluster, ce qui permettra en cas de bascule d'assurer la continuité de l'enregistrement des métriquesil fera suivre les métriques à tous les "carbon-cache" constituant le cluster.
- Sur la machine possédant la VIPl'adresse IP virtuelle, le démon "carbon-relay" reçoit effectivement l'ensemble des métriques envoyées par le Broker.
Il se charge ensuite d'envoyer les ordres d'écritures des métriques aux démons "carbon-cache".
| Note |
|---|
Le système mis en place ici est de la réplication, et non de la répartition. Les démons "carbon-cache" stockent chacun l'ensemble des métriques envoyés par le Broker. Il faut donc que chaque machine qui héberge un démon "carbon-cache" soit capable d'enregistrer l'intégralité des métriques gérées par le Broker. |
| Note |
|---|
Pour que le cluster Graphite fonctionne correctement, il est nécessaire de l'installer sur des machines utilisant le même système d'exploitation. |
| Panel |
|---|
Procédure de configuration
Avant de commencer, voici un résumé des différentes étapes nécessaires pour la configuration du cluster Graphite:
- Installation de Shinken
- Installation et configuration de Keepalived
- Mise en place du démon carbon-relay
- Autorisation des connexions à Graphite
- Modification de la configuration Shinken pour l'utilisation du cluster Graphite
- Redémarrage de Graphite et Shinken
Installation de Shinken
La première étape dans la mise en place d'un cluster Graphite est bien entendu l'installation de Graphite. Comme les autres dépendances de Shinken, il faut que la version de Graphite installée soit celle fournie avec l'installeur Shinken. En effet, certaines modifications ont été faites sur Graphite pour l'intégration avec Shinken, ce qui rend incompatible les versions de Graphites Graphite qui auraient pu être installées auparavant via d'autres installeurs.
Sur chaque machine qui compose le cluster Graphite, il faudra alors procéder à une installation de Shinken.
Pour tous les détails de la La procédure d'installation de Shinken est décrite une page de documentation dédiée ( voir la page Guide d'installation et de mise à jour ).
Installation et configuration de Keepalived
Sur chaque carbon-relaymachine constituant le cluster Graphite
Installer Keepalived et ses dépendances sur tous les serveurs qui vont composer le cluster::
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
Code Block language text theme Emacs yum install keepalived
Debian 13
Code Block language text theme Emacs apt install keepalived
Éditer
Une fois l'installation terminé, il faut aller éditerle fichier de configuration de Keepalived
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
! Configuration File for keepalived
vrrp_instance NOM_DU_SERVEUR {
# Priorité utilisée lors de l'élection d'un nouveau maître. C'est la priorité la plus élevée qui gagne l'élection
priority 150
# ID du routeur virtuel. Doit être unique sur l'ensemble des noeuds
virtual_router_id 255
# Option qui a pour conséquence qu’un master qui renaît ne reprendra pas l’IP si son SLAVE l’a
nopreempt
# Interface d'écoute et d'échange des paquets multicast VRRP
interface enp0s3
# L'état de santé des cibles est vérifié toutes les 5 secondes
advert_int 5
# Interface réseau commune aux membres
virtual_ipaddress {
XXX.XXX.XXX.XXX/XX brd XXX.XXX.XXX.XXX dev enp0s3 scope global
}
} |
ATTENTION à modifier les informations suivantes :
- vrrp_instance NOM_DU_SERVEUR : Le nom associé à l'adresse virtuelle
- priority 150 : 150 pour le serveur principal et une valeur inférieur pour les secondaires
- interface enp0s3 : Le nom de l'interface réseau principale du serveur ( commande "ip addr" ou "ifconfig" )
- virtual_ipaddress XXX.XXX.XXX.XXX/XX :
- En 1er l'adresse virtuelle qui va être créée.
- En 2ème le masque de sous réseau.
- En 3ème l'adresse de broadcast du sous-réseau ( se termine en général par 255 ).
- En 4ème le nom de l'interface réseau du serveur.
Exemple d'un configuration avec 1 serveur principal et 1 serveur secondaire
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
! Configuration File for keepalived
vrrp_instance graphite-relay {
priority 150
virtual_router_id 255
nopreempt
interface enp0s3
advert_int 5
virtual_ipaddress {
192.168.1.100/24 brd 192.168.1.255 dev enp0s3 scope global
}
} |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
! Configuration File for keepalived
vrrp_instance graphite-relay {
priority 100
virtual_router_id 255
nopreempt
interface enp0s3
advert_int 5
virtual_ipaddress {
192.168.1.100/24 brd 192.168.1.255 dev enp0s3 scope global
}
} |
Redémarrer Keepalived sur tous les serveurs du cluster en commençant par la le maître :
| Code Block | ||||
|---|---|---|---|---|
| ||||
systemctl restart keepalived |
Ainsi la commande "ip addr" sur le serveur maître devrait vous renvoyer l'ip courante ip du serveur et l'ip virtuelle précédemment créée :
| Code Block | ||||
|---|---|---|---|---|
| ||||
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:20:4a:2f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.68/24 brd 192.168.1.255 scope global noprefixroute dynamic enp0s3
valid_lft 75921sec preferred_lft 75921sec
inet 192.168.1.100/24 brd 192.168.1.255 scope global secondary enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe20:4a2f/64 scope link noprefixroute
valid_lft forever preferred_lft forever |
Mise en place du démon carbon-relay
Sur tous les serveurs constituant le cluster Graphite :
Une fois Shinken, Graphite et Keepalived installés, il faut procéder à la configuration de Graphite.
On commence par dire à Graphite qu'on utilise la fonctionnalité de relay relais via le fichier /opt/graphite/conf/carbonrelay-rules.conf ( copier le fichier d'exemple carbon relay-rules.conf.example si besoin ).
Sur chaque carbon-relay
Dans la section "[relay]", on modifie la variable "DESTINATIONS" dans laquelle on décrit la liste des démons carbon-relay qui constituent le cluster GraphiteOn configure le relais en précisant les adresses des serveurs hébergeant les démons carbon-cache ( pour l'écriture et la lecture des métriques ).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[relaydefault] ... <autres options> ... DESTINATIONSdefault = true destinations = adresse_carbon_cache_1:2004, adresse_carbon_cache_2:2004 |
On configure ensuite le relay pour lui spécifier les adresses des carbon-cache pour l'écriture et les adresses à utiliser pour la lecture des métriques.
Sur chaque carbon-relay
read_destinations = adresse_carbon_cache_1:80,adresse_carbon_cache_2:80 |
On configure ensuite le démon carbon-relay pour préciser la liste des carbon-cache constituant le cluster.
Pour cela éditer Cette configuration se fait via le fichier /opt/graphite/conf/relay-rulescarbon.conf ( copier le fichier d'exemple relay-rulesexemple carbon.conf.example si besoin ):.
Dans la section "[relay]", on modifie la variable "DESTINATIONS" dans laquelle on décrit la liste des démons carbon-cache qui constituent le cluster Graphite.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| Code Block | ||||||
| ||||||
[relay] ... <autres options> ... DESTINATIONS[default] default = true destinations = adresse_carbon_cache_1:2004, adresse_carbon_cache_2:2004 read_destinations = adresse_carbon_cache_1:80,adresse_carbon_cache_2:80 |
Par défaut, Par défaut, l'installeur Shinken met en place le fichier d'initialisation un fichier de démarrage pour le démon carbon-relay mais ne lui attribue pas sans les droits d'exécution. Pour pouvoir le démarrer permettre un démarrage en tant que service du système comme les autres démons, il va falloir lui donner faut ajouter le droit de sd'exécuterexécution.
Pour cela, lancer la commande suivant sur la Sur la machine qui va héberger le démon carbon-relay: , lancer la commande suivante :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
chmod +x /etc/init.d/carbon-relay |
A la fin de cette étape de À ce stade de la configuration, le relais est correctement configuré en ce qui concerne l'écriture des données.
Pour la lecture des métriques, il faut encore autoriser Il faut maintenant permettre la lecture des métriques, ce qui est l'objectif de l'étape suivante.
Autorisation des connexions à Graphite
Par défaut, Graphite n' autorise la lecture des métriques seulement depuis une l'interface locale ( 127.0.0.1 ), pour des raisons de sécurité. Il faut alors sur chaque machine qui héberge un démon carbon-relay, modifier les réglages d'
Pour le fonctionnement en cluster, il faut modifier les réglages d'Apache pour autoriser la lecture sur des machines externes.depuis le réseau.
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
Sur chaque serveur constituant le cluster Graphite, Sur chaque carbon-relay, on trouve dans le fichier /etc/httpd/conf.d/graphite.confon trouve la ligne suivante:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost 127.0.0.1:80> |
Cette ligne permet de dire Cette directive indique à Apache qu'il faut écouter les requêtes de lecture des métriques sur l'interface locale ( 127.0.0.1 ) et le port 80 seulement.
Pour écouter ces requêtes sur toutes les interfaces réseau de la machine, on la remplacera cette ligne par la suivante :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost *:80> |
On redémarre ensuite Apache pour prendre en compte les modifications :
| Code Block | ||||
|---|---|---|---|---|
| ||||
systemctl restart httpd |
Modification de la configuration Shinken pour l'utilisation du cluster Graphite
Debian 13
Sur chaque serveur constituant le cluster Graphite, dans le fichier /etc/apache2/sites-available/graphite.conf on trouve la ligne suivante
Comme vu dans la section présentant l'architecture haute disponibilité qu'on est en train de mettre en place, le Broker, et en particulier son module Graphite-Perfdata, doit maintenant envoyer ses informations au démon carbon-relay au lieu de les envoyer directement à un démon carbon-cache.
Il faut donc modifier la configuration actuelle de Shinken pour envoyer les métriques sur le démon carbon-relay plutôt qu'au démon carbon-cache.
Pour cela, on modifie la configuration du module Graphite-Perfdata dans le fichier /etc/shinken/modules/graphite.cfg:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost 127.0.0.1:80> |
Cette directive indique à Apache qu'il faut écouter les requêtes de lecture des métriques sur l'interface locale ( 127.0.0.1 ) et le port 80 seulement.
Pour écouter ces requêtes sur toutes les interfaces réseau de la machine, on la remplacera par :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost *:80> |
On redémarre ensuite Apache pour prendre en compte les modifications :
| Code Block | ||||
|---|---|---|---|---|
| ||||
systemctl restart apache2 |
Modification de la configuration Shinken pour l'utilisation du cluster Graphite
Écriture des métriques
L'envoi des métriques à Graphite est géré par le module Graphite-Perfdata du Broker.
Pour que les métriques soient envoyées au relais sur l'IP virtuelle plutôt qu'au démon carbon-cache, il faut modifier la configuration du module Graphite-Perfdata ( fichier /etc/shinken/modules/graphite.cfg ) :
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ──────────── Metrology server parameters ──────────────────────────────────────────────────────────── # # ─── Graphite writer ( carbon ) address # ──────────── Metrology server parameters ──────────────────────────────────────────────────────────── # # ─── Graphite writer ( carbon ) address ─── # ─── IP address or FQDN of carbon-cache or carbon-relay instance to send metrics to ─── # ─── # ─── IP address or FQDN of carbon-cache or carbon-relay instance to send metrics to ─── # ─── # Default : localhost ─── # Default : localhost ─── ─── # ─── broker__module_graphite_perfdata__writer__host addresse_carbonip_relayvirtuelle # ─── Graphite writer ( carbon ) port ─── # ─── tcp port of carbon-cache or carbon-relay instance to send metrics to ─── # ─── # Default : 2003 ─── # ─── broker__module_graphite_perfdata__writer__port 2013 |
On change ici le port 2003 ( port par défaut du carbon-cache ) vers le port 2013 ( port par défaut du carbon-relay ).
Il faut également modifier les réglages de Shinken pour lui spécifier d'envoyer les requêtes de lecture des métriques sur le carbon-relay au lieu de les envoyer directement sur un démon carbon-cache.
Cette modification se fait directement dans les réglages du module WebUI, responsable de l'interface de Visualisation. Dans /etc/shinken/modules/webui.cfg, on modifie la section suivante:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[...]
#======== Metrology access =========
# Multi-realm graphite parameter
graphite_backends *:addresse_ip_virtuelle
[...] |
Redémarrage de Graphite et Shinken
A ce stade, la configuration de Graphite a été modifiée pour utiliser un démon carbon-relay. On a aussi effectué des modifications de configuration au niveau de Shinken pour prendre en compte ce changement d'architecture au niveau de Graphite.
La dernière étape est de redémarrer les différents démons pour prendre en compte ces changements de configuration.
On commence par stopper le démon carbon-cache sur le serveur shinken:
Code Block language text theme Emacs service carbon-cache stop
On démarrer le démon carbon-relay sur tous les serveurs composants le cluster:
Code Block language text theme Emacs service carbon-cache startOn redémarrer le démon carbon-cache sur tous les serveurs composants le cluster:
Code Block language text theme Emacs service carbon-cache restartOn redémarre ensuite l'Arbiter pour prendre en compte les modifications de configuration de Shinken:
Code Block language text theme Emacs service shinken-arbiter restart
2013 |
On change ici
- l'adresse du serveur destinataire des métriques à écrire par l'IP virtuelle configurée avec keepalived,
- le port 2003 ( port par défaut du carbon-cache ) vers le port 2013 ( port par défaut du carbon-relay ).
Lecture des métriques
Il faut également préciser à Shinken de passer par l'adresse IP virtuelle pour la lecture des métriques.
Cette modification se fait dans les paramètres du module WebUI, responsable de l'interface de Visualisation. Dans /etc/shinken/modules/webui.cfg, on modifie la section suivante :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[...]
#======== Metrology access =========
# Multi-realm graphite parameter
graphite_backends *:addresse_ip_virtuelle
[...] |
Redémarrage de Graphite et Shinken
Les configurations de Graphite et de Shinken ayant été modifiées pour utiliser le cluster, il faut maintenant redémarrer les différents démons pour appliquer ces changements.
On commence par démarrer le démon carbon-relay sur chaque machine constituant le cluster Graphite :
Code Block language text theme Emacs service carbon-relay start
On fait en sorte que ce démon soit relancé au démarrage des serveurs ( sur chaque machine constituant le cluster Graphite ) :
Code Block language text theme Emacs systemctl enable carbon-relayOn redémarre le démon carbon-cache sur tous les serveurs composants le cluster:
Code Block language text theme Emacs service carbon-cache restartEnfin, on redémarre l'Arbiter pour prendre en compte les modifications de configuration de Shinken:
Excerpt Include Fichier de configuration ( shinken.cfg ) Fichier de configuration ( shinken.cfg ) page DefaultLink[destination=Optional[PageResourceIdentifier[spaceKey=<null>,title=Fichier de configuration ( shinken.cfg )]],body=Optional.empty,tooltip=Optional.empty,anchor=Optional.empty,target=Optional.empty] nopanel true
Vérification du firewall ( est-ce que l'accès à carbon-cache / carbon-relay est disponible )
En cas de problème de connexion aux démons carbon-cache / carbon-relay vérifier que le port est ouvert dans le firewall.
Liste des ports utilisés par Graphite
La liste des ports utilisés par Graphite est la suivante :
| Port | Serveur hébergeant | Fonctionnalité |
|---|---|---|
| 2003 | carbon-cache | Réception des métriques à écrite, au format texte clair. |
| 2004 | carbon-cache | Réception des métriques à écrire, au format binaire ( les données sont sérialisées ). |
| 2013 | carbon-relay | Réception des métriques à relayer, au format texte clair. |
| 2014 | carbon-relay | Réception des métriques à relayer, au format binaire ( les données sont sérialisées ). |
| 80 | carbon-relay et carbon-cache | Lecture des métriques ( protocole http ). |
| 443 | carbon-relay et carbon-cache | Lecture des métriques ( protocole https ). |
Si firewalld est présent ( firewall activé par défaut sur RHEL / Alma / Rocky 8 et RHEL / Alma / Rocky 9 )
Vérifier que les ports de Graphite sont ouverts
Vérification du firewall ( est ce que vous avez accès )
Si vous n'arrivez pas à vous connecter au carbon-cache / carbon-relay vérifier que le port est ouvert dans votre firewall.
Si vous avez firewalld ( firewall par défaut de la Redhat / AlmaLinux )
Voici comment vérifier que les ports des démons carbon-relay / carbon-cache sont ouvert ouverts sur leurs machines respectives :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --list-ports |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
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, aucun des ports de carbon-relay ( 2013/tcp ) et de carbon-cache ( 2004/tcp ) ne sont présents, ils sont donc bloqués.
Autoriser le trafic vers les ports de Graphite
Sur tous les serveurs
carbon-relayconstituant le cluster :
Si le port du démon carbon-relay n'est pas ouvert, il faut alors pour autoriser le trafic vers ce port.Cela peut être fait avec , utiliser les commandes suivantes suivantes :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --add-port=2013/tcp firewall-cmd --runtime-to-permanent |
Si le port du carbon-cache n'est pas ouvert, il faut alors pour autoriser le trafic vers ce port.Cela peut être fait avec , utiliser les commandes suivantes :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --add-port=2004/tcp firewall-cmd --runtime-to-permanent |
Sur les serveurs keepalived
Vérifier les autorisations
sur firewalldpour les communications de keepalived
Pour vérifier que les démons keepalived puissent communiquer, lancer la commande suivante
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --list-all |
La ligne rich rules indiquera si le protocol "vrrp" est autorisé.
Voici deux exemples de sorties,
- sur le premier l'autorisation est en place
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: cockpit dhcpv6-client ssh
ports: 80/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 3000/tcp
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule protocol value="vrrp" accept |
- sur le deuxième, elle ne l'est pas :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
public (active) target: default icmp-block-inversion: no interfaces: enp0s3 enp0s8 sources: services: cockpit dhcpv6-client ssh ports: 80/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 3000/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: |
Autoriser les démons keepalived à communiquer
sur firewalldSi le protocole n'est pas autorisé par le firewall, il faut alors pour autoriser le trafic pour keepalived.Cela peut être fait avec , utiliser les commandes suivantes :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent firewall-cmd --reload |
Comportement de Shinken avec un cluster Graphite
La haute disponibilité de Graphite est donc entièrement gérée entièrement par Keepalived, puis Graphite s'occupe de la réplication des données entre les démons carbon-cache et de la lecture des données.
Cette modification d'architecture est invisible pour les utilisateurs de Shinken.
Outils externes ( Grafana ) et relation UUID ↔ nom
En cas d'utilisation d'outils externes ( comme Grafana par exemple ) pour consulter les métriques, il faut également
- configurer la récupération des données de l'inventaire sur tous les serveurs carbon-cacheconstituant le cluster,
- autoriser les connexions au serveur d'inventaire depuis les serveurs carbon-cacheconstituant le cluster.
( voir la page Base de métrologie ( Graphite ) section section Correspondance ID → Nom de l'élémentélément )

