When creating and/or editing configuration files, keep the following in mind:

Lines that start with a ‘”#”’ character are taken to be comments and are not processed

Variable names are case-sensitive

If you want to configure a process to use a specific module:

You must define the module in a xxx.cfg file in the modules directory

You must reference it in the modules section for that process, e.g. the broker.cfg file

The main configuration file is “shinken.cfg”. It is located in the “/etc/shinken/” directory.
Sample main configuration files are installed for you when you follow the Quickstart installation guide.
Below are listed parameters currently used in the file. For other parameters (not mentionned by default) see Main Configuration File Advanced

Those are statements and not parameters. The arbiter considers them as order to open other(s) configuration(s) file(s)
For the cfg_dir one, the arbiter only reads files ending with ”.cfg”.
The arbiter does read recursively directory for files but does not consider lines into those files as statements anymore.

This means that a cfg_dir or cfg_file is considered as a parameter outside of shinken.cfg (or any configuration file directly given to the arbiter as parameter in a command line)
The arbiter handles main configuration files differently than any other files.

With those 2 statements, all Shinken configuration is defined : daemons, objects, resources.

This setting determines how often (in minutes) that Shinken scheduler will automatically save retention data during normal operation.
If you set this value to 0, it will not save retention data at regular intervals, but it will still save retention data before shutting down or restarting.
If you have disabled state retention (with the State Retention Option option), this option has no effect.

This option determines the maximum number of minutes from when Shinken starts that all hosts/services (that are scheduled to be regularly checked) are checked. This option will ensure that the initial checks of all hosts/services occur within the timeframe you specify. Default value is 30 (minutes).

This is the maximum number of seconds that Shinken will allow service/host checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned. A timeout error will also be logged.

There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each check normally finishes executing within this time limit. If a check runs longer than this limit, Shinken will kill it off thinking it is a runaway processes.

This option is used to set the history size of states keep by the scheduler to make the flapping calculation. By default, the value is 20 states kept.

The size in memory is for the scheduler daemon : 4Bytes * flap_history * (nb hosts + nb services). For a big environment, it costs 4 * 20 * (1000+10000) - 900Ko. So you can raise it to higher value if you want. To have more information about flapping, you can read this.

This option is used to know if we apply or not the state change when an host or service is impacted by a root problem (like the service’s host going down or a host’s parent being down too). The state will be changed by UNKNONW for a service and UNREACHABLE for an host until their next schedule check. This state change do not count as a attempt, it’s just for console so the users know that theses objects got problems and the previous states are not sure.

This option allows you to override the default timezone that this instance of Shinken runs in. Useful if you have multiple instances of Shinken that need to run from the same server, but have different local times associated with them. If not specified, Shinken will use the system configured timezone.

This option determines whether or not the Shinken daemon will make all standard macros available as environment variables to your check, notification, event hander, etc. commands. In large installations this can be problematic because it takes additional CPU to compute the values of all macros and make them available to the environment. It also cost a increase network communication between schedulers and pollers.

This variable determines whether or not Shinken will force all initial host and service states to be logged, even if they result in an OK state. Initial service and host states are normally only logged when there is a problem on the first check. Enabling this option is useful if you are using an application that scans the log file to determine long-term state statistics for services and hosts.

This option specifies the location of the lock file that Shinken arbiter daemon should create when it runs as a daemon (when started with the “-d” command line argument). This file contains the process id (PID) number of the running arbiter process.

Specify which http_backend to use. Auto is better. If cherrypy3 is not available, it will fail back to swsgiref
.. note:: Actually, if you specify something else than cherrypy or auto, it will fall into swsgiref