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.

Type	Représentation	Taille (octets)
entier	binaire	4
entier court	binaire	2
entier long	binaire	8
temps	binaire (horodatage)	8
booléen	binaire (0 est False, tout le reste est True)	1
chaîne	chaîne UTF-8 non terminée	variable
réel	chaî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.

Champ	Type	Description
checksum	entier 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.
size	entier court non signé	Taille du paquet, hors en-tête.
id	entier non signé	ID de l’événement.
source_id	entier non signé	L’ID de l’instance source de cet événement.
destination_id	entier non signé	L’ID de l’instance de destination de cet événement.
data		Donné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égorie	macro API	Valeur	Description
NEB	BBDO_NEB_TYPE	1	Événements classiques de supervision (hôtes, services, notifications, gestionnaires d’événements, exécution des plugins, ...).
BBDO	BBDO_BBDO_TYPE	2	Catégorie interne au protocole BBDO.
Storage	BBDO_STORAGE_TYPE	3	Catégorie liée à la création de graphiques RRD.
Correlation	BBDO_CORRELATION_TYPE	4	Corrélation d’état (obsolète).
Dumper	BBDO_DUMPER_TYPE	5	Événements de dumper (utilisés uniquement pour les tests).
Bam	BBDO_BAM_TYPE	6	Événements BAM.
Extcmd	BBDO_EXTCMD_TYPE	7	Commandes externes de Centreon Broker (obsolète).
Internal	BBDO_INTERNAL_TYPE	65535	Ré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.

Type	Valeur	Utilise Protobuf
Acknowledgement	1	Non
Comment	2	Non
Custom variable	3	Non
Custom variable status	4	Non
Downtime	5	Non
Event handler	6	Non
Flapping status	7	Non
Host check	8	Non
Host dependency	9	Non
Host group	10	Non
Host group member	11	Non
Host	12	Non
Host parent	13	Non
Host status	14	Non
Instance	15	Non
Instance status	16	Non
Log entry	17	Non
Module	18	Non
Service check	19	Non
Service dependency	20	Non
Service group	21	Non
Service group member	22	Non
Service	23	Non
Service status	24	Non
Instance Configuration	25	Non
Responsive Instance	26	Non
Pb Service	27	Oui
Pb Adaptive Service	28	Oui
Pb Service Status	29	Oui
Pb Host	30	Oui
Pb Adaptive Host	31	Oui
Pb Host Status	32	Oui
Pb Severity	33	Oui
Pb Tag	34	Oui

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.

Type	Value	Utilise Protobuf
Metric	1	No
Rebuild	2	No
Remove graph	3	No
Status	4	No
Index mapping	5	No
Metric mapping	6	No
Pb Rebuild Message	7	Yes
Pb Remove Graph Message	8	Yes
Pb Metric	9	Yes
Pb Status	10	Yes
Pb Index mapping	11	Yes
Pb Metric mapping	12	Yes

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.

Type	Valeur	Utilise Protobuf
version response	1	Non
ack	2	Non
stop	3	Non
Pb ack	8	Oui
Pb stop	9	Oui

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.

Type	Valeur	Uses Protobuf
BA status	1	Non
KPI status	2	Non
Meta Service Status	3	Non
BA event	4	Non
KPI event	5	Non
BA Duration Event	6	Non
Dimension BA Event	7	Non
Dimension KPI Event	8	Non
Dimension BA BV Relation Event	9	Non
Dimension BV Event	10	Non
Dimension Truncate Table Signal	11	Non
Rebuild	12	Non
Dimension Timeperiod	13	Non
Dimension BA Timeperiod Relation	14	Non
Inherited Downtime	17	Non
Pb Inherited Downtime	18	Oui
Pb BA status	19	Oui
Pb BA event	20	Oui
Pb KPI event	21	Oui
Pb Dimension BV Event	22	Oui
Pb Dimension BA BV Relation Event	23	Oui
Pb Dimension Timeperiod	24	Oui
Pb Dimension BA Event	25	Oui
Pb Dimension KPI Event	26	Oui
Pb KPI status	27	Oui
Pb BA Duration Event	28	Oui
Pb Dimension BA Timeperiod Relation	29	Oui
Pb Dimension Truncate Table Signal	30	Oui

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é	Type	Valeur dans l’exemple
active_checks_enabled	booléen	True.
check_type	entier court	0 (contrôle de l’hôte actif).
host_id	entier non signé	42
next_check	temps	1365080225
command_line	chaî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