The following chapters define how to configure Centreon Broker directly with plain-text files. This is not however the recommended way to configure software if you’re using the Centreon Web interface. More preferably, refer to Centreon Web’s documentation.


Centreon Broker’s configuration is based on XML. This format allows module configuration within the main configuration file without interfering with core options. The core options are listed in the table below. They must be specified right under the root node (whose name is of no importance).


If you use configuration files generated by Centreon, you might find that some configuration values are within a markup called CDATA. This syntax is used to prevent security issues.

Please remember that basically, Centreon Broker is an I/O multiplexer. This means that it receives input events and forward them to some output streams. Centreon Broker does not directly know which events are handled. This is the job of the modules.

The daemon

The Daemon, called cbd, is the exact result of the description above. A standalone program that multiplex events. In a monitoring setup, having only daemons would be useless, as none of them generate monitoring events. They can however be configured to perform some specific tasks. For example a daemon can handle all RRD graphs creation, another can insert events in database, ...

Daemon init script

The daemon can be started by the init script cbd. By default (/etc/init.d/cbd).

This startup script use a configuration file (by default /etc/centreon-broker/

This file contains the list of cbd daemons to start. This list must correspond to the list configured in Centreon Web.

The format of this file is:

daemon_name   config_file     start   reload


cbd           cbd-broker.xml  y       y
cbd-rrd       cbd-rrd.xml     y       n

The daemon_name is the name for distinct daemon each other.

The config_file is the configuration file for start the daemon.

If start is set to y, the daemon will be start and stop with init script.

If reload is set to y, the daemon will be reload with init script.

The module

The Module is called cbmod and is fully compatible with Centreon Engine, Nagios and Icinga. It is cbmod‘s job to generate monitoring information that will be processed further. Obviously, the module configuration shall contain at least one output stream, as explained below, for events to be treated.


The following options must be placed directly under the root of the XML file.


A logger is an object that receives log messages generated by Centreon Broker.

Here’s an example of a full logger definition placed right under the root XML node:



The list of available options for use within a logger block are defined in the table below:

Option Description
type One of file, standard or syslog. File to write logs to a file, standard to write on the process’ stdout or stderr and syslog to write on syslog.
config Enable or disable logging of config messages.
debug Enable or disable logging of debug messages.
error Enable or disable logging of error messages.
info Enable or disable logging of informational messages.
level Log verbosity. Range from 0 (no message) to 3 (highly detailed messages).
name For file loggers, path to the log file. For standard loggers, one of stdout or stderr.

Input, Output and Temporary

Streams and Layers

Input and output streams are the two end of Centreon Broker’s core : the multiplexer. This multiplexer receives monitoring events from input streams and forward them to output streams. The exact definition of what an input or output stream is, is handled by modules. Centreon Broker only directly knows that input streams can be read from whereas output streams can be written to and that multiple protocols can be stacked together to create input streams.

Temporary object alows to dump event into a stream when the event queue limit is reached.


To create input or output streams, user specifies which protocols a stream uses. To properly stack protocols one upon another, Centreon Broker uses a layer system, very similar to the OSI layers. Layers ranges from 1 to 7, 1 being a raw protocol and 7 an event-generator layer. Each stream definition must have at least one protocol which handles the first layer and one that handles the last one (ie. intermediate layers are not required but can provide additional features). Also one layer can only be handled by one protocol maximum.

Centreon recommands to use the BBDO protocol by default. This optimized protocol uses very low resources and provide feature negociation which usually enables encryption and compression without any configuration.

Common Options

This table lists all options that can be specified on every endpoint. Note that some of them might be useless on some endpoint types.

Option Description Example
buffering_timeout Number of seconds to wait before launching the endpoint failover.
filters (category) This parameter is used by endpoint to skip usless events for a specific endpoint. The filtering is base on category (neb, storage, correlation).
name An optional name, mostly used to identify a failover.
read_timeout This parameter is used by some output endpoints to take some action after an inactivity of specified seconds. For example the SQL module will commit its current transaction, the compression module will compress data without waiting for a full buffer, ...
retry_interval Number of seconds to wait between two reconnections to the same endpoint.
type Endpoint type, as specified by modules.  

Configuration File

Input objects are defined using an input block. Output objects are defined using an output block. Either input or output blocks have one mandatory tag called type used to build the protocol stack associated with this endpoint.

Here’s an example of a input/output definition:

<?xml version="1.0" encoding="UTF-8" ?>

Specific configuration entries are specified in the modules chapter.


The failover feature is a key concept in Centreon Broker. This feature allows you to redirect event stream from a failed output to another output. One common use case is when a database becomes unavailable (network outage, DB server shutdown, ...) events are temporarily stored in a file. When the server is back online, data is read from the file and stored back in the database.

Centreon Broker’s failover feature is a generalization of this process. You can use any output as a failover to another. Of course the data replaying process is only available if the protocol supports it.

All endpoints can have a <name> tag that is used by the <failover> tag to identify which endpoint if the failover of another.

Here’s an example of a failover definition placed right under to root XML node:


In this example, the MyFile endpoint will only be activated if the output to MyDB fails.