Skip to main content

Bonjour, que pensez vous de cette approche ? Le but étant donc que ce soit un poller LAN qui exécute la commande de notiffication et non le poller client ou le remote serveur.

 

Objectif

  • Collecter les données via le Poller CLIENT

  • Transporter les données à travers des relai broker sécurisés

  • Laisser le CENTRAL comme maître de configuration et d’IHM

  • Rediriger les notifications vers le Poller LAN, qui exécute la commande CentreonAlerter

Architecture


[POLL_CLIENT] 

    ↓ TCP (Broker) 

[REMOTE_SERVER] 

    ↓ TCP (Broker) 

{INTERNET}

    ↓ TCP (Broker) 

[PROXY_WEB_DMZ]

    ↓ TCP (Broker) 

[POLL_LAN] → Notifications exécutées ici

    ↓ TCP (Broker)

[CENTRAL] ← Web UI, DB, conf

Génération automatique des certificats 

Voici un script Bash complet qui génère automatiquement une autorité de certification (CA), un certificat serveur, un certificat client, et les clés privées associées à l’aide d’OpenSSL. Tous les certificats seront valides pendant 10 ans et utilisables pour Centreon Broker avec TLS mutuel.

#!/bin/bash

set -euo pipefail

# Répertoire de travail
TLS_DIR="/etc/centreon/tls"
mkdir -p "$TLS_DIR"
cd "$TLS_DIR"

# Informations de base
DAYS_VALID=3650
CA_KEY="ca.key"
CA_CERT="ca.crt"
SERVER_KEY="server.key"
SERVER_CSR="server.csr"
SERVER_CERT="server.crt"
CLIENT_KEY="client.key"
CLIENT_CSR="client.csr"
CLIENT_CERT="client.crt"

echo "[1/6] Création de l'autorité de certification (CA)..."
openssl genrsa -out "$CA_KEY" 4096
openssl req -x509 -new -nodes -key "$CA_KEY" -sha256 -days "$DAYS_VALID" -out "$CA_CERT" -subj "/C=FR/ST=Centreon/L=Monitoring/O=Centreon/OU=CA/CN=Centreon-Root-CA"

echo "[2/6] Génération de la clé privée serveur..."
openssl genrsa -out "$SERVER_KEY" 2048

echo "[3/6] Création du CSR serveur..."
openssl req -new -key "$SERVER_KEY" -out "$SERVER_CSR" -subj "/C=FR/ST=Centreon/L=Monitoring/O=Centreon/OU=Server/CN=centreon-server"

echo "[4/6] Signature du certificat serveur..."
openssl x509 -req -in "$SERVER_CSR" -CA "$CA_CERT" -CAkey "$CA_KEY" -CAcreateserial -out "$SERVER_CERT" -days "$DAYS_VALID" -sha256

echo "[5/6] Génération de la clé privée client..."
openssl genrsa -out "$CLIENT_KEY" 2048

echo "[6/6] Création + signature du certificat client..."
openssl req -new -key "$CLIENT_KEY" -out "$CLIENT_CSR" -subj "/C=FR/ST=Centreon/L=Monitoring/O=Centreon/OU=Client/CN=centreon-client"
openssl x509 -req -in "$CLIENT_CSR" -CA "$CA_CERT" -CAkey "$CA_KEY" -CAcreateserial -out "$CLIENT_CERT" -days "$DAYS_VALID" -sha256

# Sécurisation des clés
chmod 600 "$TLS_DIR"/*.key

echo "✅ Tous les certificats ont été générés dans $TLS_DIR :"
ls -1 "$TLS_DIR"

echo -e "\n📌 À copier sur les hôtes concernés :"
echo "  - $CA_CERT : sur tous les nœuds"
echo "  - $SERVER_CERT + $SERVER_KEY : sur chaque nœud jouant un rôle serveur"
echo "  - $CLIENT_CERT + $CLIENT_KEY : sur chaque nœud jouant un rôle client"

 Instructions

Exécute en root sur une machine de confiance (ex: le Central) :

bash gen-centreon-tls.sh

Copie les fichiers générés sur les hôtes :

Tous les nœuds reçoivent ca.crt

Les poller clients reçoivent client.crt + client.key

Les autres serveurs reçoivent server.crt + server.key

 

Modifie les permissions :

chmod 600 *.key chown centreon-broker:centreon-broker *.key *.crt

Configure les chemins dans les broker.json comme ceci :

"tls_cert": "/etc/centreon/tls/client.crt",

"tls_key": "/etc/centreon/tls/client.key",

"tls_ca": "/etc/centreon/tls/ca.crt"

🧱 Configuration détaillée des brokers Centreon

🔹 1. POLL_CLIENT → REMOTE (via TLS)

{

  "broker": {

    "name": "poller-client",

    "log_level": "info",

    "input": {

      "name": "central-broker",

      "type": "central-broker"

    },

    "output": [

      {

        "name": "to-remote",

        "type": "tcp",

        "host": "IP_REMOTE_SERVER",

        "port": 5669,

        "encryption": "yes",

        "tls_cert": "/etc/centreon/tls/client.crt",

        "tls_key": "/etc/centreon/tls/client.key",

        "tls_ca": "/etc/centreon/tls/ca.crt",

        "failover": false

      }

    ]

  }

}

🔹 2. REMOTE (serveur TLS) → PROXY (client TLS)

{

  "broker": {

    "name": "remote-server",

    "log_level": "info",

    "input": {

      "name": "from-client",

      "type": "tcp",

      "port": 5669,

      "encryption": "yes",

      "tls_cert": "/etc/centreon/tls/server.crt",

      "tls_key": "/etc/centreon/tls/server.key",

      "tls_ca": "/etc/centreon/tls/ca.crt"

    },

    "output": [

      {

        "name": "to-proxy",

        "type": "tcp",

        "host": "IP_PROXY_PUBLIC",

        "port": 5669,

        "encryption": "yes",

        "tls_cert": "/etc/centreon/tls/client.crt",

        "tls_key": "/etc/centreon/tls/client.key",

        "tls_ca": "/etc/centreon/tls/ca.crt"

      }

    ]

  }

}

🔹 3. PROXY (serveur TLS) → POLL_LAN (client TLS)

{

  "broker": {

    "name": "poller-proxy",

    "log_level": "info",

    "input": {

      "name": "from-remote",

      "type": "tcp",

      "port": 5669,

      "encryption": "yes",

      "tls_cert": "/etc/centreon/tls/server.crt",

      "tls_key": "/etc/centreon/tls/server.key",

      "tls_ca": "/etc/centreon/tls/ca.crt"

    },

    "output": [

      {

        "name": "to-poller-lan",

        "type": "tcp",

        "host": "IP_POLL_LAN",

        "port": 5669,

        "encryption": "yes",

        "tls_cert": "/etc/centreon/tls/client.crt",

        "tls_key": "/etc/centreon/tls/client.key",

        "tls_ca": "/etc/centreon/tls/ca.crt"

      }

    ]

  }

}

🔹 4. POLL_LAN (serveur TLS + notification) → CENTRAL (client TLS)

{

  "broker": {

    "name": "poller-lan",

    "log_level": "info",

    "input": {

      "name": "from-proxy",

      "type": "tcp",

      "port": 5669,

      "encryption": "yes",

      "tls_cert": "/etc/centreon/tls/server.crt",

      "tls_key": "/etc/centreon/tls/server.key",

      "tls_ca": "/etc/centreon/tls/ca.crt"

    },

    "output": [

      {

        "name": "to-central",

        "type": "tcp",

        "host": "IP_CENTRAL",

        "port": 5670,

        "encryption": "yes",

        "tls_cert": "/etc/centreon/tls/client.crt",

        "tls_key": "/etc/centreon/tls/client.key",

        "tls_ca": "/etc/centreon/tls/ca.crt"

      },

      {

        "name": "local-notifications",

        "type": "notification",

        "command_file": "/var/lib/centreon/centengine/centengine.cmd"

      }

    ]

  }

}

🔹 5. CENTRAL (TLS serveur, pas de notification)

{

  "broker": {

    "name": "central",

    "log_level": "info",

    "input": {

      "name": "from-poller-lan",

      "type": "tcp",

      "port": 5670,

      "encryption": "yes",

      "tls_cert": "/etc/centreon/tls/server.crt",

      "tls_key": "/etc/centreon/tls/server.key",

      "tls_ca": "/etc/centreon/tls/ca.crt"

    },

    "output": [

      {

        "name": "rrd-data",

        "type": "rrd",

        "db_directory": "/var/lib/centreon/rrd"

      },

      {

        "name": "storage",

        "type": "storage",

        "db_type": "mysql",

        "host": "localhost",

        "user": "centreon",

        "password": "your_password",

        "name": "centreon_storage"

      }

    ]

  }

}

🚨 Commande de notification (Poller LAN)

Définie dans le modèle de notification Centreon :

$CENTREONPLUGINS$/centreon_alerter/CentreonAlerter \ -ID_SOCIETE=$_HOSTIDSOCIETE$ \ -ID_SERVEUR=$_HOSTHOSTID$ \ -REPLY_STATUS=$HOSTSTATE$ \ -REPLY_DATE=$DATE$_$TIME$ \ -REPLY_DESC="$HOSTOUTPUT$" \ -HOST_ID=$HOSTID$

 

Bonjour, c’est intéressant comme stratégie pour ne pas avoir a configurer la gestion des alertes au plus bas de la segmentation réseau.

Par contre, cette configuration des broker (j’imagine que ce sont des broker Centreon) est elle uniquement dédiée a la remontée des données de notification ? J’imagine qu’on devrais pouvoir filtrer uniquement les notifications dans le flux, sinon toutes les données vont être remontées et ça peut faire beaucoup de bande passante.

Je trouve l’idée par contre super.

Salut , 

Je suis également dans ce type de questionnement , mais je pensais plus partir  sur un stream connector qui après les filtrages de notif/ack/downtime/soft/etc.. pourrait envoyer vers une api de type notification 

 

Bonjour,

 

L’idée est intéressante, on en parle régulièrement de cette idée de centraliser les notifications chez Centreon.

Je suis d’accord avec les remarques qui ont été remontées:

  • ce serait intéressant de mettre en place des filtres sur les events pour éviter qu’ils arrivent tous au poller final. Le souci est que même si broker/engine supportent un filtrage à l’event près, l’interface ne permet pas de le faire. Mais au moins, on peut filtrer sur la catégorie neb qui va déja réduire le flux.
  • L’idée du streamconnector me semble très bonne. il faut écouter les events de type Service status et Host status (les versions protobuf de nos jours sauf si vous êtes encore en BBDO 2). Ces events de status portent les infos de downtime sur les hosts/services en question, les acquittements. Par contre, il faut quand même écrire le lua qui gère le déclenchement des notifications, les host status/service status contiennent les derniers changements d’états, leurs valeurs, on peut donc assez rapidement récupérer ce que l’on veut et déclencher une notification. Un point de peine est la notion de timeperiod. Engine permet de configurer des timeperiods de notification. Mais broker ne connaît pas cette notion. Du coup, pareil avec un streamconnector, si on veut notifier sur une plage horaire donnée, il faut faire le code côté streamconnector.

En tout cas bon courage !

Bonjour ​@David Boucher,

Merci mais ça ne réponds pas à m’a question initiale.

  • Confirmez vous qu’il n’y a pas de contre-indication fonctionnelle à ce que le module notification soit exécuté depuis un poller différent de celui qui collecte l’état ?
  • Confirmez vous que l’usage de connecteurs Lua de sortie est bien supporté dans une configuration distribuant les notifications à un autre poller ?
  • validez vous cette procédure théorique ?

Cordialement

J’imagine que la réponse de David implique que c’est quelque chose de techniquement possible avec les technologies en place, mais qu’il y a une perte de fonctionnalités car il faut coder l’envoie de la notification en lua (via le connector) plutot que via une commande, et que on ne peut pas profiter de la gestion des timeperiodes dans le Centreon.

En tout cas si SavCent vous partez sur cette solution, c’est assez intéressant.
De mon coté je commencais plutot a étudier l’usage d’un envoi des notification via une API HTTP. Ainsi n’importe quel poller peut envoyer la notification a son niveau vers le serveur d’api qui peut a son tour envoyer par email ou tout autre mode souhaité.

Terms & ConditionsCookie settingsAccessibility statement