Aller au contenu principal
Version: 22.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 introduisons 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.

TypeValeurUtilise Protobuf
metric1Non
rebuild2Non
remove_graph3Non
status4Non
index mapping5Non
metric mapping6Non
Pb Rebuild Message7Oui
Pb Remove Graph Message8Oui

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.

TypeValeur
version_response1
ack2

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.

TypeValeur
ba_status1
kpi_status2
meta_service_status3
ba_event4
kpi_event5
ba_duration_event6
dimension_ba_event7
dimension_kpi_event8
dimension_ba_bv_relation_event9
dimension_bv_event10
dimension_truncate_table_signal11
rebuild12
dimension_timeperiod13
dimension_ba_timeperiod_relation14
dimension_timeperiod_exception15
dimension_timeperiod_exclusion16
inherited_downtime17

Dumper

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

TypeValeur
Dump1
Timestamp cache2
Remove3
Reload4
Db dump5
Db dump committed6
Entries Ba7
Entries Ba type8
Entries boolean9
Entries host10
Entries kpi11
Entries organization12
Entries service13
Directory dump14
Directory dump committed15

Extcmd

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

TypeValeur
Command request1
Command result2

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 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