Superviser avec CMA

🚀 1. Pourquoi passer de NRPE à CMA ?

CMA est l’agent de supervision nouvelle génération de Centreon. Contrairement à NRPE, il fonctionne en mode passif : l’agent exécute ses sondes localement et pousse les résultats vers le collecteur (poller) via le protocole OTLP (OpenTelemetry) sur gRPC. Résultat : une communication moderne, chiffrée et authentifiée.

Deux modes de connexion

• Mode standard (celui de ce guide) : l’agent initie la connexion vers le poller (agent → poller:4317). Idéal quand les agents peuvent joindre le central.
• Mode inversé (reversed) : c’est le poller qui va vers l’agent. Utile derrière un pare-feu qu’on ne veut pas ouvrir en entrée (reversed_grpc_streaming: true).

✅ 2. Prérequis & pare-feu

Avant de commencer, assurez-vous d’avoir :

• Un central Centreon 25.10 (ou 24.10+), sur RHEL 9 ou Debian 12. Chez moi : 192.168.1.46, Debian 12 (Bookworm).
• Une licence Centreon IT Edition (offre gratuite, souvent appelée « IT-100 » car limitée à 100 hôtes) — indispensable pour les fonctions agent/OpenTelemetry. Voir l’encadré ci-dessous pour l’obtenir.
• La connectivité réseau agent → poller sur le port 4317/tcp.
• Le dépôt Centreon configuré (RPM ou APT) et un accès root/sudo partout.

2.1 Ouvrir le pare-feu sur le poller

Le poller doit accepter le port 4317/tcp en entrée.

🎩 RHEL / Alma / Rocky (firewalld)

firewall-cmd --permanent --add-port=4317/tcp
firewall-cmd --reload
firewall-cmd --list-ports

🌀 Debian / Ubuntu — généralement pas de pare-feu hôte actif. Si ufw est activé :

sudo ufw allow 4317/tcp
sudo ufw status

🗺️ 3. L’architecture en un coup d’œil

Avant de plonger dans les commandes, visualisons qui parle à qui :

• Le poller écoute sur *:4317 (vérif : ss -ltn | grep 4317).
• Le poller présente son certificat serveur ; l’agent s’authentifie par token.
• Certificats auto-signés générés à la main sur le central (Let’s Encrypt inutile sur un LAN — voir l’encadré en étape 2).

📦 Étape 1 — Installer l’agent sur la machine à superviser

Bonne nouvelle : en 25.10, vous n’avez presque rien à faire à la main. Centreon vous génère une commande d’installation clé en main, valable aussi bien sous Windows que sous Linux.

Cas nº1 — La machine a accès à Internet (méthode recommandée)

La commande générée télécharge le script depuis GitHub et configure le dépôt Centreon : elle suppose donc un accès sortant vers Internet. Dans l’interface, allez dans Configuration > Collecteurs > Configurations d’agent et ouvrez le générateur « Générez votre commande d’installation CMA ». Vous ① choisissez le collecteur qui supervisera l’hôte, ② le système d’exploitation (Windows ou Linux) — et Centreon produit la commande à copier-coller sur la machine à superviser.

🪟 Windows (PowerShell)

curl -fsSL https://raw.githubusercontent.com/centreon/centreon-collect/refs/tags/25.10.15-latest/agent/installer/install_cma.ps1 -o install_cma.ps1 ; .\install_cma.ps1 -endpoint "192.168.1.46:4317" -fingerprint "<EMPREINTE_FOURNIE_PAR_L_UI>" -commonname "centreon"

🐧 Linux (RHEL & Debian)

curl -fsSL https://raw.githubusercontent.com/centreon/centreon-collect/refs/tags/25.10.15-latest/agent/installer/scripts_linux/install_cma.sh -o install_cma.sh \
  && sudo chmod +x install_cma.sh \
  && sudo ./install_cma.sh -e "192.168.1.46:4317" -f "<EMPREINTE_FOURNIE_PAR_L_UI>" -N "centreon"

Ce script unique fait tout le travail :

• détecte l’OS et configure le dépôt Centreon (avec la clé officielle apt-key.centreon.com) ;
• installe centreon-monitoring-agent et les plugins (option -p agent,plugins) ;
• génère /etc/centreon-monitoring-agent/centagent.json (endpoint, chiffrement, empreinte, host, host_template) ;
• vous demande le token de manière interactive (celui de l’étape 3) s’il n’est pas passé en -t — c’est pourquoi il n’apparaît pas dans la commande copiée.

openssl x509 -in /etc/pki/centreon-agent.crt -outform der | openssl dgst -sha256 -binary | openssl base64
# -> ex. gxt5P9+eLKK3THylg9wuAcf7omZSrbK/iJ09cOuhXm4=

Une fois la commande passée, vérifiez que le service tourne :

systemctl status centagent          # Linux
tail -f /var/log/centreon-monitoring-agent/centagent.log

Variante « à la main » (toujours avec accès Internet) — si vous préférez piloter le dépôt et la config vous-même plutôt que le script, installez le paquet de façon classique (vous écrirez alors le centagent.json à la main, étape 5) :

🎩 RHEL / Alma / Rocky

dnf install -y dnf-plugins-core ca-certificates curl gpg wget

# Depot Centreon 25.10 (inclut aussi le depot plugins)
dnf config-manager --add-repo https://packages.centreon.com/rpm-standard/25.10/el9/centreon-25.10.repo
rpm --import https://yum-gpg.centreon.com/RPM-GPG-KEY-CES

dnf clean all
dnf install -y centreon-monitoring-agent centreon-plugin-Operatingsystems-Linux-Local

🌀 Debian / Ubuntu

# Depot standard (agent) + depot plugins
echo "deb https://packages.centreon.com/apt-standard/ bookworm-25.10-stable main" \
  | sudo tee /etc/apt/sources.list.d/centreon.list
echo "deb https://packages.centreon.com/apt-plugins-stable/ bookworm main" \
  | sudo tee /etc/apt/sources.list.d/centreon-plugins.list

# Cle GPG officielle Centreon
wget -O- https://apt-key.centreon.com \
  | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/centreon.gpg > /dev/null

sudo apt update
sudo apt install -y centreon-monitoring-agent centreon-plugin-operatingsystems-linux-local

Sous Ubuntu, remplacez apt-plugins-stable par ubuntu-plugins-stable et bookworm par votre codename (ex. noble).

Cas nº2 — Machine en DMZ ou sans aucun accès à Internet (installation hors-ligne)

Pour une machine qui n’aura jamais accès à Internet (DMZ, réseau isolé, OT/industriel…), la commande générée ne peut pas fonctionner : elle joint ni GitHub ni le dépôt Centreon. On récupère alors les paquets depuis une machine qui a l’accès (même OS/version), on les transfère, on installe hors-ligne, puis on configure à la main.

1. Récupérer les paquets sur une machine « pont » qui a accès au dépôt Centreon (même distribution/version que la cible) :

🎩 RHEL / Alma / Rocky

# Telecharge le rpm + toutes ses dependances dans ./cma
# (la commande "dnf download" est fournie par dnf-plugins-core)
mkdir -p cma
dnf download --resolve --alldeps --destdir ./cma \
  centreon-monitoring-agent centreon-plugin-Operatingsystems-Linux-Local

🌀 Debian / Ubuntu

# Depots Centreon (standard + plugins) configures sur la machine pont, puis :
mkdir -p cma
sudo apt-get update
# --reinstall force le telechargement meme si le paquet est deja installe sur le pont
sudo apt-get install -y --reinstall --download-only \
  centreon-monitoring-agent centreon-plugin-operatingsystems-linux-local
cp /var/cache/apt/archives/*.deb ./cma/

2. Transférer les paquets vers la machine isolée (clé USB, ou scp via un rebond autorisé) :

ssh utilisateur@hote-isole 'mkdir -p /tmp/cma'
scp cma/* utilisateur@hote-isole:/tmp/cma/

3. Installer hors-ligne, sur la machine isolée :

🎩 RHEL / Alma / Rocky

sudo dnf install /tmp/cma/*.rpm

🌀 Debian / Ubuntu

sudo apt install /tmp/cma/*.deb   # apt resout les dependances a partir des .deb fournis

4. Configurer à la main : créez /etc/centreon-monitoring-agent/centagent.json (voir étape 5). Sur une machine isolée, privilégiez le fingerprint (aucun fichier CA à transférer) et n’oubliez pas le token.
5. Ouvrir le flux agent → poller 4317/tcp dans le pare-feu de la DMZ (uniquement vers le collecteur), puis démarrer :

sudo systemctl enable --now centagent
sudo systemctl status centagent

Vérifier la version installée (dans tous les cas) : rpm -q centreon-monitoring-agent (RHEL) ou dpkg -l | grep centreon-monitoring-agent (Debian).

🔐 Étape 2 — Générer les certificats TLS (auto-signés)

C’est le cœur du sujet. Sur un réseau interne, on génère nos propres certificats auto-signés (openssl est identique sur RHEL et Debian). Tout se passe sur le central, en root.

2.1 La CA (autorité de certification maison)

Centreon pose déjà une CA à l’installation (/etc/pki/centreon-engine/default_cma_ca.crt, valable 10 ans). Pour en créer une propre :

sudo mkdir -p /etc/pki/centreon-engine

# Cle privee de la CA
sudo openssl genrsa -out /etc/pki/centreon-engine/default_cma_ca.key 4096

# Certificat auto-signe de la CA (10 ans)
sudo openssl req -x509 -new -nodes \
  -key /etc/pki/centreon-engine/default_cma_ca.key \
  -sha256 -days 3650 \
  -subj "/CN=centreon/description=cma centreon auto signed certificate" \
  -out /etc/pki/centreon-engine/default_cma_ca.crt

2.2 Le certificat serveur (celui que le poller présente)

La commande ci-dessous produit exactement le certificat en place chez moi (CN=centreon, SAN = DNS:centreon, IP:192.168.1.46, valable 1 an) :

# Cle privee du serveur
sudo openssl genrsa -out /etc/pki/centreon-agent.key 4096

# Demande + signature en une passe, avec SAN
sudo openssl req -new -x509 -nodes -sha256 -days 365 \
  -key /etc/pki/centreon-agent.key \
  -subj "/CN=centreon" \
  -addext "subjectAltName=DNS:centreon,IP:192.168.1.46" \
  -out /etc/pki/centreon-agent.crt

2.3 Droits sur les fichiers

Le moteur tourne sous l’utilisateur centreon-engine, qui doit pouvoir lire la clé et le certificat :

sudo chown centreon-engine:centreon-engine \
  /etc/pki/centreon-agent.crt /etc/pki/centreon-agent.key
sudo chmod 640 /etc/pki/centreon-agent.key
sudo chmod 644 /etc/pki/centreon-agent.crt

# Verification
openssl x509 -in /etc/pki/centreon-agent.crt -noout -subject -dates -ext subjectAltName

2.4 Variante recommandée pour un parc : signer le certificat par la CA

L’auto-signé (2.2) est parfait pour démarrer. Mais sur un parc de plusieurs machines, il y a mieux : signer le certificat serveur par votre CA maison (celle du 2.1, valable 10 ans). Les agents feront alors confiance à la CA et non au certificat serveur — vous pourrez donc renouveler ce dernier chaque année sans jamais retoucher les agents.

# 1. Cle privee + demande de signature (CSR) du serveur
sudo openssl genrsa -out /etc/pki/centreon-agent.key 4096
sudo openssl req -new -key /etc/pki/centreon-agent.key \
  -subj "/CN=centreon" -out /tmp/centreon-agent.csr

# 2. Fichier d'extension portant le SAN (indispensable)
printf "subjectAltName=DNS:centreon,IP:192.168.1.46\n" | sudo tee /tmp/centreon-agent.ext

# 3. Signature du certificat serveur par la CA maison (valable 365 jours)
sudo openssl x509 -req -in /tmp/centreon-agent.csr \
  -CA /etc/pki/centreon-engine/default_cma_ca.crt \
  -CAkey /etc/pki/centreon-engine/default_cma_ca.key \
  -CAcreateserial -days 365 -sha256 \
  -extfile /tmp/centreon-agent.ext \
  -out /etc/pki/centreon-agent.crt

# 4. Nettoyage des fichiers temporaires
sudo rm -f /tmp/centreon-agent.csr /tmp/centreon-agent.ext

Réappliquez ensuite les droits (comme en 2.3). Côté agent, on ne pointe plus ca_certificate vers le certificat serveur mais vers la CA — que l’on copie une fois pour toutes sur chaque machine :

"ca_certificate": "/etc/centreon-monitoring-agent/default_cma_ca.crt",

Comme la CA change rarement (10 ans), vous pouvez alors renouveler le certificat serveur chaque année sans retoucher un seul agent. C’est la variante que je recommande dès que vous avez plus de deux ou trois agents.

🎫 Étape 3 — Créer le token d’authentification

Le token est un JWT (JSON Web Token : un jeton signé cryptographiquement qui encode quelques informations — son nom, sa date d’émission, son éventuelle expiration — et que le serveur peut vérifier à la volée grâce à sa signature, sans base de données) que le poller garde dans sa liste de confiance (trusted_tokens) et que l’agent présente à chaque connexion.

Où le créer

Dans l’interface : Administration > Jetons d’authentification → Ajouter, en choisissant le type « Centreon Monitoring Agent » (type cma). Donnez-lui un nom (ex. Central-xxxxxxxx) et une expiration — laissez vide pour un jeton permanent (le mien est en exp: null). Vous pouvez aussi le générer directement depuis la page Configuration > Collecteurs > Configurations d’agent au moment de créer la configuration.

Où le mettre ensuite

Cette même chaîne se retrouve à trois endroits — c’est le même token partout :

• côté serveur : dans trusted_tokens de otl_server.json (Centreon l’y place tout seul quand le jeton est rattaché à la configuration d’agent — étape 4) ;
• côté agent : c’est ce que le script d’installation vous demande de coller de manière interactive (étape 1, cas nº1), ou que vous mettez dans le champ "token" du centagent.json (étape 5, install manuelle / hors-ligne).

🛰️ Étape 4 — Configurer le serveur OTLP côté central

Ensuite, direction Configuration > Collecteurs > Configurations d’agent. On y déclare le poller, le chiffrement (Encryption level : full), les chemins du certificat/clé de l’étape 2, et le token de l’étape 3. C’est aussi de cette page que part le générateur de commande d’installation (étape 1). À l’export du collecteur, Centreon génère /etc/centreon-engine/otl_server.json. Voici le mien (secrets caviardés) :

{
    "otel_server": {
        "host": "0.0.0.0",
        "port": 4317,
        "encryption": "full",
        "public_cert": "/etc/pki/centreon-agent.crt",
        "private_key": "/etc/pki/centreon-agent.key",
        "ca_certificate": "",
        "trusted_tokens": [
            "eyJ0eXAiOiJKV1Qi....<VOTRE_TOKEN_JWT>....nEu8"
        ]
    },
    "centreon_agent": {
        "check_interval": 60,
        "export_period": 60,
        "create_host_auto": true
    }
}

Les clés à retenir :

• encryption: "full" → TLS activé, le poller présente son public_cert.
• ca_certificate: "" → vide chez moi = pas de mTLS (pas de vérif du cert client). C’est le token qui authentifie l’agent. Plus simple à exploiter sur un parc.
• create_host_auto: true → les hôtes inconnus sont créés automatiquement (rattachés à un modèle, étape 5).
• check_interval / export_period → cadence des checks et des envois (60 s).

Puis on recharge le moteur :

systemctl reload centengine
ss -ltn | grep 4317        # doit etre en ecoute : *:4317

⚙️ Étape 5 — Configurer l’agent côté machine supervisée

La configuration vit dans /etc/centreon-monitoring-agent/centagent.json. Gabarit commenté :

{
    "log_level": "info",
    "log_type": "file",
    "log_file": "/var/log/centreon-monitoring-agent/centagent.log",
    "endpoint": "192.168.1.46:4317",
    "host": "nom-de-la-machine",
    "encryption": "full",
    "ca_certificate": "/etc/centreon-monitoring-agent/centreon-agent.crt",
    "token": "eyJ0eXAiOiJKV1Qi....<VOTRE_TOKEN_JWT>....",
    "plugins_directory": "/usr/lib/centreon/plugins/src",
    "custom_check_file": "/etc/centreon-monitoring-agent/custom_checks.cfg"
}

(Config réelle d’un de mes hôtes, secrets caviardés. En installation manuelle vous l’écrivez vous-même ; via la commande générée elle est déjà produite.)
Ce fichier est lu par le service centagent (utilisateur centreon-monitoring-agent). Comme il contient le token, on restreint ses droits — par défaut il est en 664, lisible par tout le monde, ce qui est trop permissif :

sudo chown centreon-monitoring-agent:centreon-monitoring-agent /etc/centreon-monitoring-agent/centagent.json
sudo chmod 640 /etc/centreon-monitoring-agent/centagent.json

Champ par champ, les points qui font échouer une install sur deux :

• token → LE champ qu’on oublie tout le temps. C’est le même JWT que celui créé à l’étape 3 et déclaré dans trusted_tokens côté serveur (étape 4). Sans lui, le chiffrement s’établit mais le poller rejette l’agent (« empty jwt token » dans les logs). Obligatoire dès que le chiffrement est actif.
• "encryption": "full" → active TLS ; la valeur (chaîne "full" en 25.10) doit correspondre au niveau du serveur.
• ca_certificate → le certificat auquel l’agent fait confiance. Mon cert serveur étant auto-signé, je le copie sur l’agent : scp centreon@192.168.1.46:/etc/pki/centreon-agent.crt /etc/centreon-monitoring-agent/centreon-agent.crt
• Alternative au ca_certificate : le fingerprint. Plutôt que de copier le fichier certificat sur chaque machine, on peut le remplacer par "fingerprint": "<empreinte>" (l’empreinte SHA-256 base64 vue en étape 1). C’est ce que fait la commande générée. Un seul des deux suffit.
• plugins_directory → le dossier où l’agent trouve les plugins Centreon standard (ex. /usr/lib/centreon/plugins/src).
• custom_check_file → le chemin de vos sondes personnalisées (voir étape 8). À omettre si vous n’en avez pas.
• host → le nom sous lequel l’hôte apparaîtra dans Centreon.

On démarre et on surveille :

sudo systemctl enable --now centagent
sudo systemctl status centagent
sudo tail -f /var/log/centreon-monitoring-agent/centagent.log

🛡️ Étape 6 — SELinux (RHEL / Alma / Rocky uniquement)

Sur RHEL 9, SELinux est actif par défaut (getenforce → Enforcing). Trois réglages sur le poller :

# 1. Autoriser le moteur a lire les certificats
dnf install -y policycoreutils-python-utils
semanage fcontext -a -t cert_t "/etc/pki/centreon-agent\.(crt|key)"
restorecon -v /etc/pki/centreon-agent.crt /etc/pki/centreon-agent.key

# 2. Autoriser l'ecoute sur le port 4317
semanage port -a -t centreon_engine_port_t -p tcp 4317

# 3. En cas de blocage : diagnostiquer et generer la politique
ausearch -m avc -ts recent
ausearch -m avc -ts recent | audit2allow -M centreon_cma
semodule -i centreon_cma.pp

🔥 Étape 7 — Le piège de la fraîcheur (mon retour d’expérience n°1)

Voici la partie que je n’aurais jamais pu écrire dans mon premier article : il faut s’être fait avoir pour la comprendre.

Le symptôme : j’éteins une machine supervisée en CMA… et ses services restent au vert. Aucune alerte. C’est logique une fois qu’on a compris que les checks CMA sont passifs : l’agent est muet → plus aucune donnée n’arrive → le moteur conserve le dernier état OK. Rien ne bascule.

La parade : la vérification de fraîcheur. Le principe : « si aucune donnée fraîche n’arrive à temps, le service passe UNKNOWN » (données périmées — volontairement pas CRITICAL). Il m’a fallu réunir trois conditions côté service :

1. check_freshness=1 sur chaque service. ⚠️ Piège dans le piège : cette directive n’est PAS héritée depuis les modèles de service. Centreon ne l’exporte jamais depuis un template — il faut la poser sur le service lui-même. Vérifié empiriquement.
2. freshness_threshold=600 (10 min) sur chaque service.
3. check_service_freshness=1 au niveau moteur (objet ENGINECFG) — l’interrupteur maître. S’il est à 0, les deux points précédents ne servent à rien. À vérifier en premier.

Et côté hôte, un second piège : le host-alive livré par les modèles CMA (OS-Linux-Centreon-Monitoring-Agent-Host-Alive) est un factice :

/usr/bin/echo Host alive     ->   renvoie TOUJOURS OK

Donc l’hôte ne passe jamais DOWN, même éteint. La correction : un vrai check ICMP sur le modèle d’hôte custom.

check_command = base_host_alive     (un vrai check_icmp)

Comment mettre ces 4 points en place, concrètement

Tout se pilote en CLAPI (ligne de commande Centreon) ou depuis l’interface. Les commandes ci-dessous utilisent le binaire /usr/share/centreon/bin/centreon — remplacez USER/PASS par vos identifiants. ⚠️ Rien ne prend effet tant que vous n’avez pas fait l’export du collecteur (APPLYCFG) à la toute fin.

① L’interrupteur maître, au niveau moteur — une seule fois pour toute la plateforme :

centreon -u USER -p PASS -o ENGINECFG -a setparam \
  -v 'Centreon Engine Central;check_service_freshness;1'

Interface : Configuration > Collecteurs > Configuration du moteur → cochez « Check service freshness ».

② et ③ La fraîcheur sur chaque service — non héritable, donc à poser service par service :

centreon -u USER -p PASS -o SERVICE -a setparam \
  -v 'mon-hote;mon-service;check_freshness;1'
centreon -u USER -p PASS -o SERVICE -a setparam \
  -v 'mon-hote;mon-service;freshness_threshold;600'

Interface : sur chaque service, onglet « Traitement des données » → Check freshness = Oui et Freshness threshold = 600.

④ Le vrai host-alive ICMP — posé sur le modèle d’hôte custom, il s’hérite donc tout seul par les futures machines :

centreon -u USER -p PASS -o HTPL -a setparam \
  -v 'OS-Linux-Centreon-Monitoring-Agent-custom;check_command;base_host_alive'

Interface : Configuration > Modèles > Hôtes → modèle OS-Linux-Centreon-Monitoring-Agent-custom → Check Command = base_host_alive.

Enfin, on déploie la configuration du poller pour tout activer :

centreon -u USER -p PASS -a APPLYCFG -v 'Central'

À retenir : le vrai signal de panne = hôte DOWN (ping ICMP réel). Les services UNKNOWN ne font que refléter l’absence de données.

🧩 Étape 8 — Scripts et sondes personnalisés en CMA

CMA exécute les sondes sur l’agent. Pour ajouter vos propres scripts, on ne passe pas par une commande « libre » comme avec NRPE : en CMA, chaque script custom se déclare sur l’agent, dans le fichier pointé par custom_check_file (typiquement /etc/centreon-monitoring-agent/custom_checks.cfg). C’est un simple fichier INI : une section [custom_checks] qui associe un nom à une ligne de commande.

[custom_checks]
# nom_du_check = /chemin/vers/le/script $ARG1$ $ARG2$
check_service      = /usr/lib/nagios/plugins/check_service.sh $ARG1$
check_service_ssh  = /usr/lib/nagios/plugins/check_service.sh ssh
mon_check_disque   = /usr/lib/nagios/plugins/check_disque_custom.sh $ARG1$ $ARG2$

Déposez votre script sur l’agent (ex. dans /usr/lib/nagios/plugins/), rendez-le exécutable, ajoutez sa ligne ici, puis redémarrez l’agent : sudo systemctl restart centagent.

Câblage côté Centreon

Côté Centreon, tout est déjà fourni par le pack CMA : une commande OS-Linux-Centreon-Monitoring-Agent-Custom-Script (connecteur « Centreon Monitoring Agent ») dont la ligne est un petit JSON…

{ "check": "custom", "args": { "name": "$_SERVICECUSTOMCHECK$",
  "ARG1": "$_SERVICEARG1$", "ARG2": "$_SERVICEARG2$", ... } }

…et un modèle de service prêt à l’emploi : OS-Linux-Custom-Script-Centreon-Monitoring-Agent (ou OS-Windows-Custom-Script-Centreon-Monitoring-Agent sous Windows). Pour brancher votre sonde, créez un service basé sur ce modèle et renseignez ses macros :

• CUSTOMCHECK (macro $_SERVICECUSTOMCHECK$) = le nom déclaré dans custom_checks.cfg (ex. check_service) ;
• ARG1 … ARG8 ($_SERVICEARG1$ … $_SERVICEARG8$) = jusqu’à 8 arguments passés au script (ex. ssh).

À l’export du collecteur, l’agent reçoit le nom + les arguments, retrouve la ligne correspondante dans custom_checks.cfg et exécute votre script localement. Les plugins Centreon standard, eux, sont cherchés dans le dossier plugins_directory du centagent.json (ex. /usr/lib/centreon/plugins/src).

♻️ Étape 9 — Renouveler les certificats

Mon certificat serveur est valable 1 an. Pour éviter la coupure, renouvellement annuel : on régénère le certificat (étape 2.2), on le repropage vers les agents qui le référencent, puis on recharge.

# Sur le central : regenerer (voir 2.2), puis
systemctl reload centengine

# Sur chaque agent qui reference le certificat (meme chemin qu'a l'etape 5) :
scp centreon@192.168.1.46:/etc/pki/centreon-agent.crt /etc/centreon-monitoring-agent/centreon-agent.crt
systemctl restart centagent

🩺 Dépannage express

Diagnostic pas à pas (méthode officielle)

Du plus simple au plus fin :

1. L’agent tourne-t-il ?

systemctl status centagent          # Linux
# Windows : services.msc -> service "CentreonMonitoringAgent"

2. L’agent joint-il le collecteur sur 4317 ? (à lancer depuis la machine supervisée)

nc -vz 192.168.1.46 4317                        # Linux         -> "succeeded"
Test-NetConnection 192.168.1.46 -Port 4317      # PowerShell    -> TcpTestSucceeded : True

3. Le collecteur écoute-t-il, la session est-elle établie ?

ss -plant | grep 4317     # LISTEN cote poller ; ESTABLISHED = un agent est connecte
tcpdump -i any port 4317  # du trafic passe (illisible car chiffre = c'est normal)

4. Que disent les logs ?

grep -i error /var/log/centreon-monitoring-agent/centagent.log   # cote agent
grep -i error /var/log/centreon-engine/centengine.log            # cote poller
ausearch -m avc -ts recent                                       # blocages SELinux (RHEL)

5. Passer en mode debug si besoin :

• Agent : mettez "log_level": "debug" (voire "trace") dans centagent.json, puis systemctl restart centagent.
• Collecteur / OpenTelemetry : Configuration > Collecteurs > Configuration du moteur → montez le niveau de log du serveur OTLP (debug/trace), exportez, puis observez centengine.log.

🏁 Conclusion

CMA a complètement remplacé NRPE chez moi, et pour de bonnes raisons : transport moderne (gRPC), chiffrement TLS réel adossé à un token, et création automatique des hôtes. La procédure est identique sur RHEL et Debian, à trois détails près : le dépôt (RPM/APT), le pare-feu (firewalld/ufw) et SELinux (RHEL). Les vrais pièges ne sont pas dans l’installation — simple — mais dans deux détails d’exploitation : le SAN du certificat (sans quoi rien ne se connecte) et la fraîcheur passive (sans quoi une machine morte reste au vert). Une fois ces deux points maîtrisés, c’est un agent solide et confortable.

Une question, un cas tordu, une amélioration ? Dites-le en commentaire 👇

Bon monitoring avec Centreon CMA !