Stream connector migration to BBDO 3.0.0

Centreon Broker 22.04.0 (and later versions) comes with a new 3.0.0 version of its BBDO protocol. This new protocol is far more flexible than the previous one:

• it is not fixed in time, but can be upgraded without breaking changes.
• it supports more structured objets like arrays, maps and other things.
• serialization generally results into smaller buffers.

All broker events have not yet been migrated; we just focused on:

• neb::host event
• neb::host_status event
• neb::service event
• neb::service_status event

Broker can still read them,but now it produces the following events:

• neb::pb_host event
• neb::pb_adaptive_host event
• neb::pb_host_status event
• neb::pb_service event
• neb::pb_adaptive_service event
• neb::pb_service_status event

The drawback is if that if you have written stream connectors, they might not work anymore, and you would have to fix them.

In this section, we are going to explain what has changed, and then how to fix your issue.

An example of a stream connector that won't work with BBDO 3.0

Here is some Lua code for a stream connector that worked before BBDO 3.0 and that will not work with Centreon Broker 22.10 or up if BBDO 3.0 is enabled:

    function init(conf)
      broker_log:set_parameters(0, "/tmp/log")
    end

    function write(d)
      if d.category == 1 and d.element == 23 then
        broker_log:info(0, "Here is a service: " .. broker.json_encode(d))
      end
      if d.category == 1 and d.element == 12 then
        broker_log:info(0, "Here is a host: " .. broker.json_encode(d))
      end
      return true
    end

This script is very simple. The init() function initializes logs to allow for all the logs to be written in the file /tmp/log.

The write() function, called each time an event is received, handles only two events: the neb::service event (with category 1 and element 23) and the neb::host event (with category 1 and element 12).

For each of them, it is serialized in JSON and written to the log file.

This script does not work with BBDO 3.0 because it expects the legacy events neb::host and neb::service, and while these events can still be forwarded by Centreon Broker, they are no longer produced with the new protocol. So all the events received by the write() function do not match the expected category and element values.

Instead of neb::service, the events produced are neb::pb_service and instead of neb::host, the events produced are neb::pb_host.

So for the script to work again, we just have to add the recognition of these two new events.

As a result, we get the following new script:

    function init(conf)
      broker_log:set_parameters(0, "/tmp/log")
    end

    function write(d)
      if d.category == 1 and (d.element == 27 or d.element == 23) then
        broker_log:info(0, "Here is a service: " .. broker.json_encode(d))
      end
      if d.category == 1 and (d.element == 30 or d.element == 12) then
        broker_log:info(0, "Here is a host: " .. broker.json_encode(d))
      end
      return true
    end

Now, the script should work as expected.

If you need to get fields from a neb::service event, for example description, this same field should also be available in neb::pb_service. So generally, except for the new types to handle, you will have nothing more to do.

For the migration, this table can help:

legacy object	BBDO 3.0 object	Comments
neb::service (1, 23)	neb::pb_service (1, 27)
neb::host (1, 12)	neb::pb_host (1, 30)
neb::service_status (1, 24)	neb::pb_service_status (1, 29)	New events are lighter. Several fields can be missing. In that case, pb_service is useful to get them.
neb::host_status (1, 14)	neb::pb_host_status (1, 32)	New events are lighter. Several fields can be missing. In that case, pb_host is useful to get them.

There are also two new events with BBDO 3.0: neb::pb_adaptive_host* and neb::pb_adaptive_service. They carry configuration changes for a host or a service. These events are designed to be small.

In a neb::pb_adaptive_service event, there are two mandatory fields:host_id and service_id to know the relevant service. All the other fields are optional. If defined (in Lua not nil), the value has been set and you have to handle it; otherwise, ignore it.