Core configuration

The core configuration part describes the Alignak framework infrastructure (which daemons are used and how they are) and the main configuration.

The Alignak environment file (alignak.ini) aims to contain all the Alignak configuration, except the monitored system that may be configured separately in Nagios legacy configuration (cfg) files or in the Alignak backend.

If your monitored system configuration is stored in the Alignak backend, the alignak.ini file is (almost) the only configuration file you will have to manage ;)

The Alignak environment file contains the necessary information about:

  • the Alignak installation directories
  • the Alignak daemons and their configuration
  • the Alignak monitored configuration
  • the Alignak macros

This file is structured as a common Ini file with some sections containig variables.

All the Alignak configuration variables are commented in the default shipped configuration file and are described in the following chapter

When an Alignak daemon loads its configuration, it will try to open the file which name is provided on the command line with the -e / –environment parameter. If it exists an alignak.d sub-directory in the same directory as the environment file, all the **.ini* files located in this sub-directory will also be loaded and parsed.

When updating the configuration with a new daemon or new parameters, it is cleaner/easier to add a new file in the alignak.d rather than modifying a unique configuration file;)

The default shipped example configuration is structured as:

alignak.ini
alignak.d/
    daemons.ini
    modules.ini

Warning

all the default shipped files may be updated when you will update Alignak. As such, all the modifications you did in these files will be lost!

Configuration sections

[DEFAULT]

The DEFAULT section is the main section of the configuration. It defines global variables that will be inherited by all the other configuration sections.

The default configuration defines all the Alignak configuration variable in this section. It is a choice to make all the variables available, if needed, in any daemon that loads the alignak.ini file.

Note

For more information about this inheritance process, check the Python configuration parser behavior.

[alignak-configuration]

The alignak-configuration section is used to define the global variables and macros, and the monitored system configuration files (eg. the Nagios legacy cfg files).

Thanks to the section inheritance process, all the configuration variables are made available in this section and they may be overloaded if needed. Only the Alignak Arbiter gets this section variables to build its monitoring configuration.

Global variables

To change a default configured variable:

; Disable notifications
enable_notifications=0

Alignak uses most of the Nagios common configuration variables that may be defined in this section.

Note

the variables defined in some legacy configuration files take precedence over the one defined in this configuration file.

Nagios legacy configuration

If your monitored system is configured with legacy configuration files, you can declare the main configuration entry point file in this section:

cfg=my_nagios.cfg
cfg2=an_extra_file.cfg

All the cfg prefixed variables will be considered as some Nagios legacy configuration files. The Alignak arbiter will open and parse these files to build the monitored system configuration.

Macros

Some plugins used to check the system hosts/services often need global variables known as macros. This section is the rigth place to declare such variables:

_my_macro_=1
_nrpe_plugins_dir_=/usr/local/libexec/nagios/

The variables prefixed with an _ (underscore) will be considered as macros. The leading and trailing underscores will be removed and the variable name will be uppercased. _my_macro_ will be usable as $MY_MACRO$.

[daemon.daemon-name]

The daemon.* sections allow to declare all the daemons that are involved in the Alignak configuration.

Each daemon must have its own section with its specific parameters.

Note

Remember that the DEFAULT section variables are inherited in all the other sections. Thus, you only need to declare the daemon specific variables (eg. listening port) in each daemon section.

All the daemons have a common set of configuration variables which are explained in this table:

Variable name Type Default Short description
type string   Daemon type (arbiter, scheduler, poller, broker, reactionner, receive, poller)
name string   Daemon unique name
user string   Daemon user account username
group string   Daemon user account group
host string 0.0.0.0 listening interface
address string 127.0.0.1 FQDN or ip address used by the other daemons
port integer   HTTP port of the daemon WS interface
spare boolean 0 set if the daemon is a spare
debug boolean 0 set to activate debug log level
active boolean 1 unset to disable the daemon in the configuration
modules string   modules name list separated by comma
use_ssl boolean 0 use SSL for communications with this daemons
realm string All the realm the daemon is attached to
manage_sub_realms boolean 0 manage its realm only (0) and the sub realms (1)
server_cert string %(etcdir)s/certs/server.crt  
server_key string %(etcdir)s/certs/server.key  
ca_cert string %(etcdir)s/certs/ca.pem  

Each daemon is listening on an host:port interface where it exposes its Web Service API. It may be accessible for the other daemons on the same port but with an other address.

Each daemon will change its credentials to run as user / group as specified in its parameters. If non is specified it will use the current logged in user.

Each daemon is attached to a realm (defaults to All) and it may be involved only in its realm (default behavior) or in its realm and all the sub-realms (manage_sub_realms=1). When using a multi-realms environment, make sure to avoid overlapping realms/daemons because it may have some unexpected behavor!

Poller / reactionner daemons specific parameters:

Variable name Type Default Short description
min_workers integer 0 The minimum workers launched by the daemon
max_workers integer 0 The maximum workers launched by the daemon
processes_by_worker integer 256 The processes that may be started by a worker process.
worker_polling_interval integer 1 The daemon will check its workers on this polling interval
passive boolean 0 Set to 1 to use the daemon passive mode

The minimum and maximum workers launched by the daemon allow to configure the number of processes that will be used to execute the delegated actions. If set to 0, the poller/reactionner daemon will use N-1 workers if your system has N CPUs. The poller defaults to 0 (use as many workers as possible) whereas the reactionner defaults to 1 (use only one worker).

In active mode, the poller/reactionner is connecting to its scheduler to get its actions to execute and to report the execution results. The passive mode allows to make the scheduler push its actions and get the results from the poller/reactionner satellites. This mode is interesting to control the network flow from the scheduler to poller/reactionner on a remote site…

Scheduler daemons specific parameters (advanced configuration parameters):

Variable name Type Default Short description
skip_initial_broks boolean 0 The scheduler will not require the initial initialization broks
weight integer 1 Set the scheduler weight in the dispatching process
accept_passive_unknown_check_results boolean 0 set 1 to allow passive check for unknown hosts

Note

Those are advanced configuration parameters. Feel free to request for more information about them if needed. This will mean that you already have an idea of what it is about ;)

Broker daemons specific parameters:

Variable name Type Default Short description
max_queue_size integer 100000 Limit the broker modules queue size if it becomes too important
manage_arbiters boolean 1 Set this to get the arbiter created broks

There must only be one and only one broker that gets the broks created by the arbiter (manage_arbiters). o not set this parameter for all other brokers because it defaults to False.

The max_queue_size parameter is managed by all the daemons with a default value set to 0, which means: do not care about the queue size. For a broker, it is important to manage the queue size limitation!

Note

Those are advanced configuration parameters. Feel free to request for more information about them if needed. This will mean that you already have an idea of what it is about ;)

[module.module-name]

The module.* sections allow to declare all the extra modules that are used and their configuration.

Each module must have its own section with its specific parameters.

Note

Remember that the DEFAULT section variables are inherited in all the other sections. Thus, you only need to declare the module specific variables in each module section.

All the modules have a common set of configuration variables which are explained in this table:

Variable name Type Default Short description
type string   Module type (retention, metrics, …)
name string   Module unique name
python_name string 0.0.0.0 Python libray to be loaded for the module

The module type is only an informative field. Except for some specific case, this is not considered by Alignak

Note

Contact the development team for more about the module type if needed!.