Aller au contenu principal
Version: 24.04

Le protocole BBDO

Le protocole BBDO a été créé pour être le protocole par défaut de Centreon Broker. Il est léger, facile à décoder et spécialement conçu pour la surveillance des ressources avec Centreon Broker.

Introduction

BBDO est l’abréviation de Broker Binary Data Object. BBDO est conçu pour transférer des « paquets de données » d’un nœud à un autre. Ces « paquets de données » sont la plupart du temps des informations de supervision fournies par le moteur de supervision (par exemple le moteur Centreon Engine ou Nagios). Il utilise principalement des valeurs binaires brutes, ce qui lui permet d’utiliser très peu de mémoire.

Avec Broker 22.04.0, nous avons introduit une nouvelle version de BBDO basée sur Google Protobuf 3. Le nouveau protocole reste compatible avec le précédent mais introduit de nouveaux événements. Par exemple, les événements PbService et PbServiceStatus sont envoyés au lieu des événements Service et ServiceStatus. Configuré avec BBDO 3, Broker comprend toujours les événements Service et ServiceStatus mais il doit envoyer par défaut les nouvelles versions.

Types

Cette section porte sur le protocole BBDO 2.

En tant que protocole binaire, BBDO utilise des types de données pour sérialiser les données. Ils sont écrits dans un format Big Endian et décrits dans le tableau suivant.

TypeReprésentationTaille (octets)
entierbinaire4
entier courtbinaire2
entier longbinaire8
tempsbinaire (horodatage)8
booléenbinaire (0 est False, tout le reste est True)1
chaînechaîne UTF-8 non terminéevariable
réelchaîne UTF-8 non terminée (au format fixe (2013) ou scientifique (2.013e+3))variable

Format de paquet

Le format des paquets de Centreon Broker n’introduit que 16 octets d’en-tête pour transmettre chaque événement de supervision (généralement environ 100-200 octets chacun). Les champs sont fournis au format Big Endian.

ChampTypeDescription
checksumentier court non signéCRC-16-CCITT X.25 de la taille, de l’ID, de la source et de la destination. La somme de contrôle peut être utilisée pour récupérer un paquet de données incomplet envoyé dans le flux en laissant tomber les octets un par un.
sizeentier court non signéTaille du paquet, hors en-tête.
identier non signéID de l’événement.
source_identier non signéL’ID de l’instance source de cet événement.
destination_identier non signéL’ID de l’instance de destination de cet événement.
dataDonnées utiles.

Ici, la seule différence entre BBDO 3 et les versions précédentes est le contenu des données. Dans BBDO 3, cette partie est un objet Protobuf sérialisé alors que dans les versions précédentes, il s’agit de données sérialisées comme expliqué dans la section Types.

ID de paquet

Comme nous l’avons vu dans le paragraphe précédent, chaque paquet contient un ID qui exprime par lui-même la façon dont les données sont encodées. Cet ID peut être divisé en deux composants de 16 bits. Les 16 bits les plus significatifs sont la catégorie d’événement et les 16 bits les moins significatifs sont le type d’événement.

Les catégories d’événements sérialisent les propriétés des événements l’une après l’autre, l’ordre est donc très important pour ne pas perdre le fil lors de la désérialisation des événements.

Catégories d’événements

Les catégories actuellement disponibles sont décrites dans le tableau ci-dessous.

Catégoriemacro APIValeurDescription
NEBBBDO_NEB_TYPE1Événements classiques de supervision (hôtes, services, notifications, gestionnaires d’événements, exécution des plugins, ...).
BBDOBBDO_BBDO_TYPE2Catégorie interne au protocole BBDO.
StorageBBDO_STORAGE_TYPE3Catégorie liée à la création de graphiques RRD.
CorrelationBBDO_CORRELATION_TYPE4Corrélation d’état (obsolète).
DumperBBDO_DUMPER_TYPE5Événements de dumper (utilisés uniquement pour les tests).
BamBBDO_BAM_TYPE6Événements BAM.
ExtcmdBBDO_EXTCMD_TYPE7Commandes externes de Centreon Broker (obsolète).
InternalBBDO_INTERNAL_TYPE65535Réservé à l’usage interne du protocole.

NEB

Le tableau ci-dessous répertorie les types d’événements disponibles dans la catégorie NEB. Ils doivent être combinés avec la catégorie BBDO_NEB_TYPE pour obtenir un ID d’événement BBDO.

TypeValeurUtilise Protobuf
Acknowledgement1Non
Comment2Non
Custom variable3Non
Custom variable status4Non
Downtime5Non
Event handler6Non
Flapping status7Non
Host check8Non
Host dependency9Non
Host group10Non
Host group member11Non
Host12Non
Host parent13Non
Host status14Non
Instance15Non
Instance status16Non
Log entry17Non
Module18Non
Service check19Non
Service dependency20Non
Service group21Non
Service group member22Non
Service23Non
Service status24Non
Instance Configuration25Non
Responsive Instance26Non
Pb Service27Oui
Pb Adaptive Service28Oui
Pb Service Status29Oui
Pb Host30Oui
Pb Adaptive Host31Oui
Pb Host Status32Oui
Pb Severity33Oui
Pb Tag34Oui

Storage

Le tableau ci-dessous répertorie les types d’événements disponibles dans la catégorie Storage. Ils doivent être combinés avec la catégorie BBDO_STORAGE_TYPE pour obtenir un ID d’événement BBDO.

TypeValueUtilise Protobuf
Metric1No
Rebuild2No
Remove graph3No
Status4No
Index mapping5No
Metric mapping6No
Pb Rebuild Message7Yes
Pb Remove Graph Message8Yes
Pb Metric9Yes
Pb Status10Yes
Pb Index mapping11Yes
Pb Metric mapping12Yes

BBDO

Le tableau ci-dessous répertorie les types d’événements disponibles dans la catégorie BBDO. Ils doivent être combinés avec la catégorie BBDO_BBDO_TYPE pour obtenir un ID d’événement BBDO.

TypeValeurUtilise Protobuf
version response1Non
ack2Non
stop3Non
Pb ack8Oui
Pb stop9Oui

BAM

Le tableau ci-dessous répertorie les types d’événements disponibles dans la catégorie BAM. Ils doivent être combinés avec la catégorie BBDO_BAM_TYPE pour obtenir un ID d’événement BBDO.

TypeValeurUses Protobuf
BA status1Non
KPI status2Non
Meta Service Status3Non
BA event4Non
KPI event5Non
BA Duration Event6Non
Dimension BA Event7Non
Dimension KPI Event8Non
Dimension BA BV Relation Event9Non
Dimension BV Event10Non
Dimension Truncate Table Signal11Non
Rebuild12Non
Dimension Timeperiod13Non
Dimension BA Timeperiod Relation14Non
Inherited Downtime17Non
Pb Inherited Downtime18Oui
Pb BA status19Oui
Pb BA event20Oui
Pb KPI event21Oui
Pb Dimension BV Event22Oui
Pb Dimension BA BV Relation Event23Oui
Pb Dimension Timeperiod24Oui
Pb Dimension BA Event25Oui
Pb Dimension KPI Event26Oui
Pb KPI status27Oui
Pb BA Duration Event28Oui
Pb Dimension BA Timeperiod Relation29Oui
Pb Dimension Truncate Table Signal30Oui

Sérialisation des événements

La plupart des événements répertoriés dans chaque catégorie d’événements dispose d’un mapping utilisé pour sérialiser leur contenu. En effet, leur contenu est directement sérialisé dans les données utiles du paquet, un champ après l’autre dans l’ordre décrit dans les tables de correspondance. Ils sont encodés selon les règles décrites dans le paragraphe sur les types.

Exemple

Prenons un exemple et voyons comment un événement host check est envoyé dans un paquet. Son mapping est le suivant :

PropriétéTypeValeur dans l’exemple
active_checks_enabledbooléenTrue.
check_typeentier court0 (contrôle de l’hôte actif).
host_identier non signé42
next_checktemps1365080225
command_linechaîne./my_plugin -H 127.0.0.1

Et donne le paquet suivant avec les valeurs en hexadécimal.

+-----------------+-----------------+-----------------------------------+
| CRC16 | SIZE | ID |
+========+========+========+========+========+========+========+========+
| 0A | 23 | 00 | 28 | 00 | 01 | 00 | 09 |
+--------+--------+--------+--------+--------+--------+--------+--------+

+--------+-----------------+-----------------------------------+--------
| active_| | |
| checks_| check_type | host_id | =>
| enabled| | |
+========+========+========+========+==========================+========+
| 01 | 00 | 00 | 00 | 00 | 00 | 2A | 00 |
+--------+--------+--------+--------+--------+--------+--------+--------+

--------------------------+--------------------------------------------
=> next_check | =>
+========+========+========+========+========+========+========+========+
| 00 | 00 | 00 | 51 | 5D | 78 | A1 | 2E |
+--------+--------+--------+--------+--------+--------+--------+--------+

-----------------------------------------------------------------------
=> command_line =>
+========+========+========+========+========+========+========+========+
| 2F | 6D | 79 | 5F | 70 | 6C | 75 | 67 |
+--------+--------+--------+--------+--------+--------+--------+--------+

-----------------------------------------------------------------------
=> command_line =>
+========+========+========+========+========+========+========+========+
| 69 | 6E | 20 | 2D | 48 | 20 | 31 | 32 |
+--------+--------+--------+--------+--------+--------+--------+--------+

-----------------------------------------------------------------------+
=> command_line |
+========+========+========+========+========+========+========+========+
| 37 | 2E | 30 | 2E | 30 | 2E | 31 | 00 |
+--------+--------+--------+--------+--------+--------+--------+--------+

Établissement de la connexion

BBDO est un protocole qui peut négocier des fonctionnalités. Lors de l’établissement d’une connexion, un paquet version_response est envoyé par le client. Il fournit la version du protocole BBDO qu’il supporte et ses extensions. Le serveur répond à ce message par un autre paquet version_response contenant sa propre version du protocole supportée et ses extensions. Si les versions du protocole correspondent, la négociation des extensions commence.

Actuellement, deux extensions sont supportées : TLS et COMPRESSION. Juste après le paquet version_response, chaque pair recherche dans la liste des extensions de l’autre pair les extensions qu’il supporte. Lorsqu’il en trouve une, elle est activée (c’est-à-dire qu’elle démarre immédiatement).

Exemple

Prenons C le client et S le serveur. Les étapes suivantes sont effectuées de manière séquentielle.

  • C initie une connexion TCP avec S et la connexion est établie.
  • C envoie un paquet version_response avec les attributs suivants
    • protocole majeur : 1
    • protocole mineur : 0
    • protocole correctif : 0
    • extensions : « TLS COMPRESSION »
  • S envoie son propre paquet version_response en réponse à C
    • protocole majeur : 1
    • protocole mineur : 0
    • protocole correctif : 0
    • extensions : « TLS COMPRESSION »
  • C et S déterminent les extensions qu’ils ont en commun (ici TLS et COMPRESSION)
  • si l’ordre est important, les extensions sont appliquées dans l’ordre fourni par le serveur
  • la connexion TLS est initiée, le handshake est effectué...
  • la connexion de compression est ouverte
  • les données transmises entre C et S sont maintenant à la fois chiffrées et compressées

Acquittement

Les clients/serveurs dits « intelligents » peuvent acquitter les paquets qui leur sont envoyés. Cette fonction est utilisée par Centreon Broker pour s’assurer que chaque paquet est pris en compte et pour lancer la procédure de rétention au cas où l’autre partie ne répondrait pas.

Pour cela, l’autre partie doit envoyer périodiquement un paquet BBDO « ack » sur le même canal TCP. Ce paquet comporte le numéro du paquet acquitté par le client.

Les modes « Clever »/« Dumb » sont configurés sur chaque sortie TCP, pour chaque Broker.

Changement de version de BBDO

La version de BBDO doit être la même pour tous les serveurs de votre architecture (serveur central, serveurs distants, collecteurs).

Si vous utilisez BBDO v2 avec cette version de Centreon, vous ne pourrez pas utiliser la page Statut des ressources.

Si vous voulez changer de version de BBDO (passer de la v3 à la v2 ou de la v2 à la v3), procédez comme suit :

  1. Sur le serveur central, accédez à Configuration > Collecteurs > Configuration de Centreon Broker.

  2. Sélectionnez le serveur souhaité, et dans l’onglet Général, dans la section Paramètres avancés, sélectionnez la version de BBDO souhaitée dans la liste BBDO version. Cliquez ensuite sur Sauvegarder.

  3. Faites de même avec tous les éléments figurant sur la page Configuration > Collecteurs > Configuration de Centreon Broker.

  4. Redémarrez gorgoned sur chaque serveur :

    systemctl restart gorgoned
  5. Déployez la configuration pour tous les serveurs.

  6. Arrêtez les services suivants :

    • Sur le serveur central et sur les serveurs distants :

      systemctl stop cbd centengine
    • Sur les collecteurs :

      systemctl stop centengine
  7. Démarrez les services suivants :

    • Sur le serveur central et sur les serveurs distants :

      systemctl start cbd centengine
    • Sur les collecteurs :

      systemctl start centengine

Vous pouvez vérifier dans les journaux quelle version de BBDO est active pour un serveur :

  • broker central :

    tail /var/log/centreon-broker/central-{broker,rrd,module}-master.log

  • broker distant :

    tail /var/log/centreon-broker/<remote_name>-{broker,rrd,module}-master.log
  • module collecteur :

    tail /var/log/centreon-broker/<poller_name>-module.log

La ligne suivante indique quelle version est utilisée pour chaque serveur :

[2022-05-17T14:53:44.828+00:00] [bbdo] [info] BBDO: peer is using protocol version 2.0.0, we're using version 2.0.0