Nagios Event Broker

The Nagios Event Broker (NEB) is a way Nagios makes internal information available for external libraries. NEB is based on shared code libraries which are called modules. The NEB modules are hooked into the Nagios core process when starting Nagios. The NEB uses callback routines which have to be served by the NEB modules. These routines are executed when special events occur in the Nagios server process.

List of NEB modules

In the past years several developers created many NEB modules for different purposes. Here a list and short description of the most important modules:

  • NDO, Nagios Data Out Stores all information kept in the Nagios process in a MySQL database.
  • MKLivestatus Listens on a socket for clients to request Nagios live status information.
  • DNX, Distributed Nagios Executor Distributes all Nagios checks to DNX clients. Where the DNX server is a NEB module and the DNX clients are standalone daemons on remote systems.
  • Merlin The Merlin project has been started to create an easy way using Nagios reduntand and load balanced. It is also be used as database backend for the Ninja frontend.
  • IDO (Based on NDO, forked for Icinga) When Icinga was forked it was an important step to fork the NDOutils to make several important changes mainly for performance reasons. The IDO is basically same as NDO.

NEB Background information

Using the NEB interface it is possible to get a lot of events. Just some examples:

  • Host and service checks
  • Notifications
  • Flapping states
  • Downtime starting/ending
  • Comment adding/deleting

A full list of events can be found in the nebcallbacks.h header file in the source code of Nagios.

Triggered by these events the registered functions of the modules can access all information which are kept in the Nagios process. Accessing the Nagios process internal information is very performant.

One disadvantage of the NEB API is that the function can block the Nagios process. It is important to keep the overhead caused by the NEB module as small as possible. One good example is the NDO itselfs: When an event occurs in Nagios, for example a service check has been executed, the ndomod forwards the information to the ndo2db using a tcp or unix socket. Then the ndo2db daemon inserts the information to the database. The whole action is blocking the Nagios process until the information have been added to the database. Recognizing the amount of events it is clear that such a complex flow is too much overhead which may slow down the Nagios process a lot.

It is important to know this to understand the way a NEB module should be developed. To avoid such a complex flow it is a good idea to create some sort of buffer somewhere and decouple the complex data progressing from the Nagios core.

Depending on the needs a “passive” NEB module could also be possible. For example when you need only live status information it is possible to create a NEB module which listens for queries and then reads the information from the Nagios core. This is what the MKLivestatus module works like.

Using NEB modules

It is possible to enable/disable the NEB support in Nagios on compile time. The NEB is enabled by default.

The NEB modules can be added by editing the Main Nagios configuration file (nagios.cfg).

The parameters broker_module and event_broker_options controll the ways NEB modules are handled. The event_broker_options control for which events modules are called. Setting it to -1 tells Nagios to forward all events.

The NEB modules are registered using the parameter broker_module. The option can be used multiple times to register several modules. This is an example line to register the MKLivestatus module.

> broker_module=/usr/local/nagios/bin/livestatus.o /usr/local/nagios/var/rw/live

The path to the module comes direct after the = sign. It is possible to hand over parameters to the NEB modules when the module supports that.

Filed under: Nagios
Comments (0) Trackbacks (1)