Main Configuration File Options

Notes

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

  • Variables names must begin at the start of the line - no white space is allowed before the name

  • Variable names are case-sensitive

Sample Configuration File

Note

A sample main configuration file /etc/centreon-engine/centengine.cfg is installed for you when you follow the quickstart installation guide.

Config File Location

The main configuration file is usually named centengine.cfg and located in the /etc/centreon-engine/ directory.

Configuration File Variables

Below you will find descriptions of each main Centreon Engine configuration file option…

Log File

This variable specifies where Centreon Engine should create its main log file. This should be the first variable that you define in your configuration file, as Centreon Engine will try to write errors that it finds in the rest of your configuration data to this file. If you have log rotation enabled, this file will automatically be rotated every hour, day, week, or month.

Format

log_file=<file_name>

Example

log_file=/var/log/centreon-engine/centengine.log

Object Configuration File

This directive is used to specify an object configuration file containing object definitions that Centreon Engine should use for monitoring. Object configuration files contain definitions for hosts, host groups, contacts, contact groups, services, commands, etc. You can seperate your configuration information into several files and specify multiple cfg_file= statements to have each of them processed.

Format

cfg_file=<file_name>

Example

cfg_file=/etc/centreon-engine/hosts.cfg cfg_file=/etc/centreon-engine/services.cfg cfg_file=/etc/centreon-engine/commands.cfg

Object Configuration Directory

This directive is used to specify a directory which contains object configuration files that Centreon Engine should use for monitoring. All files in the directory with a .cfg extension are processed as object config files. Additionally, Centreon Engine will recursively process all config files in subdirectories of the directory you specify here. You can seperate your configuration files into different directories and specify multiple cfg_dir= statements to have all config files in each directory processed.

Format

cfg_dir=<directory_name>

Example

cfg_dir=/etc/centreon-engine/commands cfg_dir=/etc/centreon-engine/services cfg_dir=/etc/centreon-engine/hosts

Object Cache File

This directive is used to specify a file in which a cached copy of object definitions should be stored. The cache file is (re)created every time Centreon Engine is (re)started. It is intended to speed up config file caching and allow you to edit the source object config files while Centreon Engine is running without affecting the output displayed.

Format

object_cache_file=<file_name>

Example

object_cache_file=/var/log/centreon-engine/objects.cache

Precached Object File

This directive is used to specify a file in which a pre-processed, pre-cached copy of object definitions should be stored. This file can be used to drastically improve startup times in large/complex Centreon Engine installations. Read more information on how to speed up start times here.

Format

precached_object_file=<file_name>

Example

precached_object_file=/var/log/centreon-engine/objects.precache

Resource File

This is used to specify an optional resource file that can contain $USERn$ macro definitions. $USERn$ macros are useful for storing usernames, passwords, and items commonly used in command definitions (like directory paths). You can include multiple resource files by adding multiple resource_file statements to the main config file - Centreon Engine will process them all. See the sample resource.cfg file in the sample-config/ subdirectory of the Centreon Engine distribution for an example of how to define $USERn$ macros.

Format

resource_file=<file_name>

Example

resource_file=/etc/centreon-engine/resource.cfg

Temp File

This is a deprecated and ignored variable.

Format

temp_file=<file_name>

Status File

This is the file that Centreon Engine uses to store the current status, comment, and downtime information. This file is deleted every time Centreon Engine stops and recreated when it starts.

Format

status_file=<file_name>

Example

status_file=/var/log/centreon-engine/status.dat

Status File Update Interval

This setting determines how often (in seconds) that Centreon Engine will update status data in the status file. The minimum update interval is 1 second.

Format

status_update_interval=<seconds>

Example

status_update_interval=15

Notifications Option

This option determines whether or not Centreon Engine will send out notifications when it initially (re)starts. If this option is disabled, Centreon Engine will not send out notifications for any host or service.

Format

enable_notifications=<0/1>

Example

enable_notifications=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Disable notifications

  • 1 = Enable notifications (default)

Service Check Execution Option

This option determines whether or not Centreon Engine will execute service checks when it initially (re)starts. If this option is disabled, Centreon Engine will not actively execute any service checks and will remain in a sort of “sleep” mode (it can still accept passive checks unless you’ve disabled them). This option is most often used when configuring backup monitoring servers, as described in the documentation on redundancy, or when setting up a distributed monitoring environment.

Format

execute_service_checks=<0/1>

Example

execute_service_checks=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Don’t execute service checks

  • 1 = Execute service checks (default)

Passive Service Check Acceptance Option

This option determines whether or not Centreon Engine will accept passive service checks when it initially (re)starts. If this option is disabled, Centreon Engine will not accept any passive service checks.

Format

accept_passive_service_checks=<0/1>

Example

accept_passive_service_checks=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Don’t accept passive service checks

  • 1 = Accept passive service checks (default)

Host Check Execution Option

This option determines whether or not Centreon Engine will execute on-demand and regularly scheduled host checks when it initially (re)starts. If this option is disabled, Centreon Engine will not actively execute any host checks, although it can still accept passive host checks unless you’ve disabled them). This option is most often used when configuring backup monitoring servers, as described in the documentation on redundancy, or when setting up a distributed monitoring environment.

Format

execute_host_checks=<0/1>

Example

execute_host_checks=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Don’t execute host checks

  • 1 = Execute host checks (default)

Passive Host Check Acceptance Option

This option determines whether or not Centreon Engine will accept passive host checks when it initially (re)starts. If this option is disabled, Centreon Engine will not accept any passive host checks.

Format

accept_passive_host_checks=<0/1>

Example

accept_passive_host_checks=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Don’t accept passive host checks

  • 1 = Accept passive host checks (default)

Event Handler Option

This option determines whether or not Centreon Engine will run event handlers when it initially (re)starts. If this option is disabled, Centreon Engine will not run any host or service event handlers.

Format

enable_event_handlers=<0/1>

Example

enable_event_handlers=1

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface. Values are as follows:

  • 0 = Disable event handlers

  • 1 = Enable event handlers (default)

Log Rotation Method

This is a deprecated and ignored variable. Use logrotate daemon.

Format

log_rotation_method=<n/h/d/w/m>

Log Archive Path

This is a deprecated and ignored variable.

Format

log_archive_path=<path>

External Command Check Option

This option determines whether or not Centreon Engine will check the command file for commands that should be executed. More information on external commands can be found here.

  • 0 = Don’t check external commands

  • 1 = Check external commands (default)

Format

check_external_commands=<0/1>

Example

check_external_commands=1

External Command Check Interval

If you specify a number with an “s” appended to it (i.e. 30s), this is the number of seconds to wait between external command checks. If you leave off the “s”, this is the number of “time units” to wait between external command checks. Unless you’ve changed the interval_length value (as defined below) from the default value of 60, this number will mean minutes.

Format

command_check_interval=<xxx>[s]

Example

command_check_interval=1

Note

By setting this value to -1, Centreon Engine will check for external commands as often as possible. Each time Centreon Engine checks for external commands it will read and process all commands present in the command file before continuing on with its other duties. More information on external commands can be found here.

External Command File

This is the file that Centreon Engine will check for external commands to process. The external command file is implemented as a named pipe (FIFO), which is created when Centreon Engine starts and removed when it shuts down. If the file exists when Centreon Engine starts, the Centreon Engine process will terminate with an error message. More information on external commands can be found here.

Format

command_file=<file_name>

Example

command_file=/var/log/centreon-engine/rw/centengine.cmd

External Command Buffer Slots

Format

external_command_buffer_slots=<#>

Example

external_command_buffer_slots=512

Note

This is an advanced feature. This option determines how many buffer slots Centreon Engine will reserve for caching external commands that have been read from the external command file by a worker thread, but have not yet been processed by the main thread of the Centreon Engine deamon. Each slot can hold one external command, so this option essentially determines how many commands can be buffered. For installations where you process a large number of passive checks (e.g. distributed setups), you may need to increase this number.

State Retention Option

This option determines whether or not Centreon Engine will retain state information for hosts and services between program restarts. If you enable this option, you should supply a value for the state_retention_file variable. When enabled, Centreon Engine will save all state information for hosts and service before it shuts down (or restarts) and will read in previously saved state information when it starts up again.

  • 0 = Don’t retain state information

  • 1 = Retain state information (default)

Format

retain_state_information=<0/1>

Example

retain_state_information=1

State Retention File

This is the file that Centreon Engine will use for storing status, downtime, and comment information before it shuts down. When Centreon Engine is restarted it will use the information stored in this file for setting the initial states of services and hosts before it starts monitoring anything. In order to make Centreon Engine retain state information between program restarts, you must enable the retain_state_information option.

Format

state_retention_file=<file_name>

Example

state_retention_file=/var/log/centreon-engine/retention.dat

Automatic State Retention Update Interval

This setting determines how often (in minutes) that Centreon Engine will automatically save retention data during normal operation. If you set this value to 0, Centreon Engine 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 retain_state_information option), this option has no effect.

Format

retention_update_interval=<minutes>

Example

retention_update_interval=60

Use Retained Program State Option

This setting determines whether or not Centreon Engine will set various program-wide state variables based on the values saved in the retention file. Some of these program-wide state variables that are normally saved across program restarts if state retention is enabled include the enable_notifications, enable_flap_detection, enable_event_handlers, execute_service_checks, and accept_passive_service_checks options. If you do not have state retention enabled, this option has no effect.

  • 0 = Don’t use retained program state

  • 1 = Use retained program state (default)

Format

use_retained_program_state=<0/1>

Example

use_retained_program_state=1

Use Retained Scheduling Info Option

This setting determines whether or not Centreon Engine will retain scheduling info (next check times) for hosts and services when it restarts. If you are adding a large number (or percentage) of hosts and services, I would recommend disabling this option when you first restart Centreon Engine, as it can adversely skew the spread of initial checks. Otherwise you will probably want to leave it enabled.

  • 0 = Don’t use retained scheduling info

  • 1 = Use retained scheduling info (default)

Format

use_retained_scheduling_info=<0/1>

Example

use_retained_scheduling_info=1

Retained Host and Service Attribute Masks

They are a deprecated and ignered variables.

Format

retained_host_attribute_mask=<number> retained_service_attribute_mask=<number>

Retained Process Attribute Masks

They are a deprecated and ignered variables.

Format

retained_process_host_attribute_mask=<number> retained_process_service_attribute_mask=<number>

Retained Contact Attribute Masks

These options determine which contact attributes are NOT retained across program restarts. There are two masks because there are often separate host and service contact attributes that can be changed. The values for these options are a bitwise AND of values specified by the “MODATTR_” definitions in the include/common.h source code file. By default, all process attributes are retained.

Format

retained_contact_host_attribute_mask=<number> retained_contact_service_attribute_mask=<number>

Example

retained_contact_host_attribute_mask=0 retained_contact_service_attribute_mask=0

Note

This is an advanced feature. You’ll need to read the Centreon Engine source code to use this option effectively.

Syslog Logging Option

This variable determines whether messages are logged to the syslog facility on your local host. Values are as follows:

  • 0 = Don’t use syslog facility

  • 1 = Use syslog facility

Format

use_syslog=<0/1>

Example

use_syslog=1

Notification Logging Option

This variable determines whether or not notification messages are logged. If you have a lot of contacts or regular service failures your log file will grow relatively quickly. Use this option to keep contact notifications from being logged.

  • 0 = Don’t log notifications

  • 1 = Log notifications

Format

log_notifications=<0/1>

Example

log_notifications=1

Service Check Retry Logging Option

This variable determines whether or not service check retries are logged. Service check retries occur when a service check results in a non-OK state, but you have configured Centreon Engine to retry the service more than once before responding to the error. Services in this situation are considered to be in “soft” states. Logging service check retries is mostly useful when attempting to debug Centreon Engine or test out service event handlers.

  • 0 = Don’t log service check retries

  • 1 = Log service check retries

Format

log_service_retries=<0/1>

Example

log_service_retries=1

Host Check Retry Logging Option

This variable determines whether or not host check retries are logged. Logging host check retries is mostly useful when attempting to debug Centreon Engine or test out host event handlers.

  • 0 = Don’t log host check retries

  • 1 = Log host check retries

Format

log_host_retries=<0/1>

Example

log_host_retries=1

Event Handler Logging Option

This variable determines whether or not service and host event handlers are logged.

Event handlers are optional commands that can be run whenever a service or hosts changes state. Logging event handlers is most useful when debugging Centreon Engine or first trying out your event handler scripts.

  • 0 = Don’t log event handlers

  • 1 = Log event handlers

Format

log_event_handlers=<0/1>

Example

log_event_handlers=1

Initial States Logging Option

This variable determines whether or not Centreon Engine 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.

  • 0 = Don’t log initial states (default)

  • 1 = Log initial states

Format

log_initial_states=<0/1>

Example

log_initial_states=1

External Command Logging Option

This variable determines whether or not Centreon Engine will log external commands that it receives from the external command file.

Format

log_external_commands=<0/1>

Example

log_external_commands=1

Note

This option does not control whether or not passive service checks (which are a type of external command) get logged. To enable or disable logging of passive checks, use the log_passive_checks option.

  • 0 = Don’t log external commands

  • 1 = Log external commands (default)

Passive Check Logging Option

This variable determines whether or not Centreon Engine will log passive host and service checks that it receives from the external command file. If you are setting up a distributed monitoring environment or plan on handling a large number of passive checks on a regular basis, you may wish to disable this option so your log file doesn’t get too large.

  • 0 = Don’t log passive checks

  • 1 = Log passive checks (default)

Format

log_passive_checks=<0/1>

Example

log_passive_checks=1

Global Host Event Handler Option

This option allows you to specify a host event handler command that is to be run for every host state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each host definition. The command argument is the short name of a command that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the event_handler_timeout option. More information on event handlers can be found here.

Format

global_host_event_handler=<command>

Example

global_host_event_handler=log-host-event-to-db

Global Service Event Handler Option

This option allows you to specify a service event handler command that is to be run for every service state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each service definition. The command argument is the short name of a command that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the event_handler_timeout option. More information on event handlers can be found here.

Format

global_service_event_handler=<command>

Example

global_service_event_handler=log-service-event-to-db

Inter-Check Sleep Time

This is the number of seconds that Centreon Engine will sleep before checking to see if the next service or host check in the scheduling queue should be executed.

Format

sleep_time=<seconds>

Example

sleep_time=1

Note

That Centreon Engine will only sleep after it “catches up” with queued service checks that have fallen behind.

Service Inter-Check Delay Method

This option allows you to control how service checks are initially “spread out” in the event queue. Using a “smart” delay calculation (the default) will cause Centreon Engine to calculate an average check interval and spread initial checks of all services out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended, as it will cause all service checks to be scheduled for execution at the same time. This means that you will generally have large CPU spikes when the services are all executed in parallel. More information on how to estimate how the inter-check delay affects service check scheduling can be found here. Values are as follows:

  • n = Don’t use any delay - schedule all service checks to run immediately (i.e. at the same time!)

  • d = Use a “dumb” delay of 1 second between service checks

  • s = Use a “smart” delay calculation to spread service checks out evenly (default)

  • x.xx = Use a user-supplied inter-check delay of x.xx seconds

Format

service_inter_check_delay_method=<n/d/s/x.xx>

Example

service_inter_check_delay_method=s

Maximum Service Check Spread

This option determines the maximum number of minutes from when Centreon Engine starts that all services (that are scheduled to be regularly checked) are checked. This option will automatically adjust the service inter-check delay method” (if necessary) to ensure that the initial checks of all services occur within the timeframe you specify. In general, this option will not have an affect on service check scheduling if scheduling information is being retained using the use_retained_scheduling_info option. Default value is 30 (minutes).

Format

max_service_check_spread=<minutes>

Example

max_service_check_spread=30

Service Interleave Factor

This variable determines how service checks are interleaved. Interleaving allows for a more even distribution of service checks, reduced load on remote hosts, and faster overall detection of host problems. Setting this value to 1 is equivalent to not interleaving the service checks (this is how versions of Centreon Engine previous to 0.0.5 worked). Set this value to s (smart) for automatic calculation of the interleave factor unless you have a specific reason to change it. You should see that the service check results are spread out as they begin to appear. More information on how interleaving works can be found here.

  • x = A number greater than or equal to 1 that specifies the interleave factor to use. An interleave factor of 1 is equivalent to not interleaving the service checks.

  • s = Use a “smart” interleave factor calculation (default)

Format

service_interleave_factor=<s|x>

Example

service_interleave_factor=s

Maximum Concurrent Service Checks

This option allows you to specify the maximum number of service checks that can be run in parallel at any given time. Specifying a value of 1 for this variable essentially prevents any service checks from being run in parallel. Specifying a value of 0 (the default) does not place any restrictions on the number of concurrent checks. You’ll have to modify this value based on the system resources you have available on the machine that runs Centreon Engine, as it directly affects the maximum load that will be imposed on the system (processor utilization, memory, etc.). More information on how to estimate how many concurrent checks you should allow can be found here.

Format

max_concurrent_checks=<max_checks>

Example

max_concurrent_checks=20

Check Result Reaper Frequency

This option allows you to control the frequency in seconds of check result “reaper” events. “Reaper” events process the results from host and service checks that have finished executing. These events consitute the core of the monitoring logic in Centreon Engine.

Format

check_result_reaper_frequency=<frequency_in_seconds>

Example

check_result_reaper_frequency=5

Maximum Check Result Reaper Time

This option allows you to control the maximum amount of time in seconds that host and service check result “reaper” events are allowed to run. “Reaper” events process the results from host and service checks that have finished executing. If there are a lot of results to process, reaper events may take a long time to finish, which might delay timely execution of new host and service checks. This variable allows you to limit the amount of time that an individual reaper event will run before it hands control back over to Centreon Engine for other portions of the monitoring logic.

Format

max_check_result_reaper_time=<seconds>

Example

max_check_result_reaper_time=30

Use Check Result Path

This option enable or disable compatibility mode to use check result path.

Format

use_check_result_path=<0/1>

Example

use_check_result_path=0

Check Result Path

This options determines which directory Nagios will use to temporarily store host and service check results before they are processed. This directory should not be used to store any other files, as Nagios will periodically clean this directory of old file (see the max_check_result_file_age option for more information).

Format

check_result_path=<path>

Example

check_result_path=/tmp

Note

This options is deprecated.

Max Check Result File Age

This options determines the maximum age in seconds that Nagios will consider check result files found in the check_result_path directory to be valid. Check result files that are older that this threshold will be deleted by Nagios and the check results they contain will not be processed. By using a value of zero (0) with this option, Nagios will process all check result files - even if they’re older than your hardware :-).

Format

max_check_result_file_age=<seconds>

Example

max_check_result_file_age=3600

Note

This options is deprecated.

Host Inter-Check Delay Method

This option allows you to control how host checks that are scheduled to be checked on a regular basis are initially “spread out” in the event queue. Using a “smart” delay calculation (the default) will cause Centreon Engine to calculate an average check interval and spread initial checks of all hosts out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended. Using no delay will cause all host checks to be scheduled for execution at the same time. More information on how to estimate how the inter-check delay affects host check scheduling can be found here.Values are as follows:

  • n = Don’t use any delay - schedule all host checks to run immediately (i.e. at the same time!)

  • d = Use a “dumb” delay of 1 second between host checks

  • s = Use a “smart” delay calculation to spread host checks out evenly (default)

  • x.xx = Use a user-supplied inter-check delay of x.xx seconds

Format

host_inter_check_delay_method=<n/d/s/x.xx>

Example

host_inter_check_delay_method=s

Maximum Host Check Spread

This option determines the maximum number of minutes from when Centreon Engine starts that all hosts (that are scheduled to be regularly checked) are checked. This option will automatically adjust the host inter-check delay method” (if necessary) to ensure that the initial checks of all hosts occur within the timeframe you specify. In general, this option will not have an affect on host check scheduling if scheduling information is being retained using the use_retained_scheduling_info option. Default value is 30 (minutes).

Format

max_host_check_spread=<minutes>

Example

max_host_check_spread=30

Timing Interval Length

This is the number of seconds per “unit interval” used for timing in the scheduling queue, re-notifications, etc. “Units intervals” are used in the object configuration file to determine how often to run a service check, how often to re-notify a contact, etc.

Format

interval_length=<seconds>

Example

interval_length=60

Note

The default value for this is set to 60, which means that a “unit value” of 1 in the object configuration file will mean 60 seconds (1 minute). I have not really tested other values for this variable, so proceed at your own risk if you decide to do so!

Auto-Rescheduling Option

This option determines whether or not Centreon Engine will attempt to automatically reschedule active host and service checks to “smooth” them out over time. This can help to balance the load on the monitoring server, as it will attempt to keep the time between consecutive checks consistent, at the expense of executing checks on a more rigid schedule.

Format

auto_reschedule_checks=<0/1>

Example

auto_reschedule_checks=1

Note

This is an experimental feature and may be removed in future versions. Enabling this option can degrade performance - rather than increase it - if used improperly!

Auto-Rescheduling Interval

This option determines how often (in seconds) Centreon Engine will attempt to automatically reschedule checks. This option only has an effect if the auto_reschedule_checks option is enabled. Default is 30 seconds.

Format

auto_rescheduling_interval=<seconds>

Example

auto_rescheduling_interval=30

Note

This is an experimental feature and may be removed in future versions. Enabling the auto-rescheduling option can degrade performance - rather than increase it - if used improperly!

Auto-Rescheduling Window

This option determines the “window” of time (in seconds) that Centreon Engine will look at when automatically rescheduling checks. Only host and service checks that occur in the next X seconds (determined by this variable) will be rescheduled. This option only has an effect if the auto_reschedule_checks option is enabled. Default is 180 seconds (3 minutes).

Format

auto_rescheduling_window=<seconds>

Example

auto_rescheduling_window=180

Note

This is an experimental feature and may be removed in future versions. Enabling the auto-rescheduling option can degrade performance - rather than increase it - if used improperly!

Aggressive Host Checking Option

Centreon Engine tries to be smart about how and when it checks the status of hosts. In general, disabling this option will allow Centreon Engine to make some smarter decisions and check hosts a bit faster. Enabling this option will increase the amount of time required to check hosts, but may improve reliability a bit. Unless you have problems with Centreon Engine not recognizing that a host recovered, I would suggest not enabling this option.

  • 0 = Don’t use aggressive host checking (default)

  • 1 = Use aggressive host checking

Format

use_aggressive_host_checking=<0/1>

Example

use_aggressive_host_checking=0

Translate Passive Host Checks Option

This option determines whether or not Centreon Engine will translate DOWN/UNREACHABLE passive host check results to their “correct” state from the viewpoint of the local Centreon Engine instance. This can be very useful in distributed and failover monitoring installations. More information on passive check state translation can be found here.

  • 0 = Disable check translation (default)

  • 1 = Enable check translation

Format

translate_passive_host_checks=<0/1>

Example

translate_passive_host_checks=1

Passive Host Checks Are SOFT Option

This option determines whether or not Centreon Engine will treat passive host checks as HARD states or SOFT states. By default, a passive host check result will put a host into a HARD state type. You can change this behavior by enabling this option.

  • 0 = Passive host checks are HARD (default)

  • 1 = Passive host checks are SOFT

Format

passive_host_checks_are_soft=<0/1>

Example

passive_host_checks_are_soft=1

Predictive Host Dependency Checks Option

This option determines whether or not Centreon Engine will execute predictive checks of hosts that are being depended upon (as defined in host dependencies”) for a particular host when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found here.

  • 0 = Disable predictive checks

  • 1 = Enable predictive checks (default)

Format

enable_predictive_host_dependency_checks=<0/1>

Example

enable_predictive_host_dependency_checks=1

Predictive Service Dependency Checks Option

This option determines whether or not Centreon Engine will execute predictive checks of services that are being depended upon (as defined in service dependencies) for a particular service when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found here.

  • 0 = Disable predictive checks

  • 1 = Enable predictive checks (default)

Format

enable_predictive_service_dependency_checks=<0/1>

Example

enable_predictive_service_dependency_checks=1

Cached Host Check Horizon

This option determines the maximum amount of time (in seconds) that the state of a previous host check is considered current. Cached host states (from host checks that were performed more recently than the time specified by this value) can improve host check performance immensely. Too high of a value for this option may result in (temporarily) inaccurate host states, while a low value may result in a performance hit for host checks. Use a value of 0 if you want to disable host check caching. More information on cached checks can be found here.

Format

cached_host_check_horizon=<seconds>

Example

cached_host_check_horizon=15

Cached Service Check Horizon

This option determines the maximum amount of time (in seconds) that the state of a previous service check is considered current. Cached service states (from service checks that were performed more recently than the time specified by this value) can improve service check performance when a lot of service dependencies are used. Too high of a value for this option may result in inaccuracies in the service dependency logic. Use a value of 0 if you want to disable service check caching. More information on cached checks can be found here.

Format

cached_service_check_horizon=<seconds>

Example

cached_service_check_horizon=15

Large Installation Tweaks Option

This option determines whether or not the Centreon Engine daemon will take several shortcuts to improve performance. These shortcuts result in the loss of a few features, but larger installations will likely see a lot of benefit from doing so.

  • 0 = Don’t use tweaks (default)

  • 1 = Use tweaks

Format

use_large_installation_tweaks=<0/1>

Example

use_large_installation_tweaks=0

Use Setpgid

This option allow to change plugin process group into they own process group id. This option protect Centreon Engine process from child miss used or bug.

For example, if we use nagios check_ping, check_dns, check_dig or check_rbl, don’t disable this option, because, these checks can call kill -KILL 0 on timeout (this is a bug from these plugins) and kill the engine if the PGID is the same as the engine.

For maximum performance, this option must be disable.

  • 0 = Don’t use setpgid

  • 1 = Use setpgid (default)

Format

use_setpgid=<0/1>

Example

use_setpgid=1

Child Process Memory Option

This is a deprecated and ignored variable.

Format

free_child_process_memory=<0/1>

Child Processes Fork Twice

This is a deprecated and ignored variable.

Format

child_processes_fork_twice=<0/1>

Environment Macros Option

This option determines whether or not the Centreon Engine daemon will make all standard macros available as environment variables to your check, notification, event hander, etc. commands. In large Centreon Engine installations this can be problematic because it takes additional memory and (more importantly) CPU to compute the values of all macros and make them available to the environment.

  • 0 = Don’t make macros available as environment variables

  • 1 = Make macros available as environment variables (default)

Format

enable_environment_macros=<0/1>

Example

enable_environment_macros=0

Flap Detection Option

This option determines whether or not Centreon Engine will try and detect hosts and services that are “flapping”. Flapping occurs when a host or service changes between states too frequently, resulting in a barrage of notifications being sent out. When Centreon Engine detects that a host or service is flapping, it will temporarily suppress notifications for that host/service until it stops flapping. Flap detection is very experimental at this point, so use this feature with caution! More information on how flap detection and handling works can be found here.

Format

enable_flap_detection=<0/1>

Example

enable_flap_detection=0

Note

If you have state retention enabled, Centreon Engine will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you’ll have to use the appropriate external command or change it via the web interface.

  • 0 = Don’t enable flap detection (default)

  • 1 = Enable flap detection

Low Service Flap Threshold

This option is used to set the low threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read this.

Format

low_service_flap_threshold=<percent>

Example

low_service_flap_threshold=25.0

High Service Flap Threshold

This option is used to set the high threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read this.

Format

high_service_flap_threshold=<percent>

Example

high_service_flap_threshold=50.0

Low Host Flap Threshold

This option is used to set the low threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read this.

Format

low_host_flap_threshold=<percent>

Example

low_host_flap_threshold=25.0

High Host Flap Threshold

This option is used to set the high threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read this.

Format

high_host_flap_threshold=<percent>

Example

high_host_flap_threshold=50.0

Soft State Dependencies Option

This option determines whether or not Centreon Engine will use soft state information when checking host and service dependencies. Normally Centreon Engine will only use the latest hard host or service state when checking dependencies. If you want it to use the latest state (regardless of whether its a soft or hard state type), enable this option.

  • 0 = Don’t use soft state dependencies (default)

  • 1 = Use soft state dependencies

Format

soft_state_dependencies=<0/1>

Example

soft_state_dependencies=0

Service Check Timeout

This is the maximum number of seconds that Centreon Engine will allow service 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 service check normally finishes executing within this time limit. If a service check runs longer than this limit, Centreon Engine will kill it off thinking it is a runaway processes.

Format

service_check_timeout=<seconds>

Example

service_check_timeout=60

Host Check Timeout

This is the maximum number of seconds that Centreon Engine will allow host checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned and the host will be assumed to be DOWN. 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 host check normally finishes executing within this time limit. If a host check runs longer than this limit, Centreon Engine will kill it off thinking it is a runaway processes.

Format

host_check_timeout=<seconds>

Example

host_check_timeout=60

Event Handler Timeout

This is the maximum number of seconds that Centreon Engine will allow event handlers to be run. If an event handler exceeds this time limit it will be killed and a warning will 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 commands 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 event handler command normally finishes executing within this time limit. If an event handler runs longer than this limit, Centreon Engine will kill it off thinking it is a runaway processes.

Format

event_handler_timeout=<seconds>

Example

event_handler_timeout=60

Notification Timeout

This is the maximum number of seconds that Centreon Engine will allow notification commands to be run. If a notification command exceeds this time limit it will be killed and a warning will 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 commands 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 notification command finishes executing within this time limit. If a notification command runs longer than this limit, Centreon Engine will kill it off thinking it is a runaway processes.

Format

notification_timeout=<seconds>

Example

notification_timeout=60

Obsessive Compulsive Service Processor Timeout

This is the maximum number of seconds that Centreon Engine will allow an obsessive compulsive service processor command” to be run. If a command exceeds this time limit it will be killed and a warning will be logged.

Format

ocsp_timeout=<seconds>

Example

ocsp_timeout=5

Obsessive Compulsive Host Processor Timeout

This is the maximum number of seconds that Centreon Engine will allow an obsessive compulsive host processor command” to be run. If a command exceeds this time limit it will be killed and a warning will be logged.

Format

ochp_timeout=<seconds>

Example

ochp_timeout=5

Performance Data Processor Command Timeout

This is the maximum number of seconds that Centreon Engine will allow a host performance data processor command” or service performance data processor command to be run. If a command exceeds this time limit it will be killed and a warning will be logged.

Format

perfdata_timeout=<seconds>

Example

perfdata_timeout=5

Obsess Over Services Option

This value determines whether or not Centreon Engine will “obsess” over service checks results and run the obsessive compulsive service processor command you define. I know - funny name, but it was all I could think of. This option is useful for performing distributed monitoring. If you’re not doing distributed monitoring, don’t enable this option.

  • 0 = Don’t obsess over services (default)

  • 1 = Obsess over services

Format

obsess_over_services=<0/1>

Example

obsess_over_services=1

Obsessive Compulsive Service Processor Command

This option allows you to specify a command to be run after every service check, which can be useful in distributed monitoring. This command is executed after any event handler or notification commands. The command argument is the short name of a command definition that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the ocsp_timeout option. More information on distributed monitoring can be found here. This command is only executed if the obsess_over_services option is enabled globally and if the obsess_over_service directive in the service definition is enabled.

Format

ocsp_command=<command>

Example

ocsp_command=obsessive_service_handler

Obsess Over Hosts Option

This value determines whether or not Centreon Engine will “obsess” over host checks results and run the obsessive compulsive host processor command you define. I know - funny name, but it was all I could think of. This option is useful for performing distributed monitoring. If you’re not doing distributed monitoring, don’t enable this option.

  • 0 = Don’t obsess over hosts (default)

  • 1 = Obsess over hosts

Format

obsess_over_hosts=<0/1>

Example

obsess_over_hosts=1

Obsessive Compulsive Host Processor Command

This option allows you to specify a command to be run after every host check, which can be useful in distributed monitoring. This command is executed after any event handler or notification commands. The command argument is the short name of a command definition that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the ochp_timeout option. More information on distributed monitoring can be found here. This command is only executed if the obsess_over_hosts option is enabled globally and if the obsess_over_host directive in the host definition is enabled.

Format

ochp_command=<command>

Example

ochp_command=obsessive_host_handler

Performance Data Processing Option

This value determines whether or not Centreon Engine will process host and service check performance data.

  • 0 = Don’t process performance data (default)

  • 1 = Process performance data

Format

process_performance_data=<0/1>

Example

process_performance_data=1

Host Performance Data Processing Command

This option allows you to specify a command to be run after every host check to process host performance data that may be returned from the check. The command argument is the short name of a command definition” that you define in your object configuration file. This command is only executed if the process_performance_data option is enabled globally and if the process_perf_data directive in the host definition is enabled.

Format

host_perfdata_command=<command>

Example

host_perfdata_command=process-host-perfdata

Service Performance Data Processing Command

This option allows you to specify a command to be run after every service check to process service performance data that may be returned from the check. The command argument is the short name of a command definition that you define in your object configuration file. This command is only executed if the process_performance_data option is enabled globally and if the process_perf_data directive in the service definition is enabled.

Format

service_perfdata_command=<command>

Example

service_perfdata_command=process-service-perfdata

Host Performance Data File

This option allows you to specify a file to which host performance data will be written after every host check. Data will be written to the performance file as specified by the host_perfdata_file_template option. Performance data is only written to this file if the process_performance_data option is enabled globally and if the process_perf_data directive in the host definition is enabled.

Format

host_perfdata_file=<file_name>

Example

host_perfdata_file=/var/log/centreon-engine/host-perfdata.dat

Service Performance Data File

This option allows you to specify a file to which service performance data will be written after every service check. Data will be written to the performance file as specified by the service_perfdata_file_template option. Performance data is only written to this file if the process_performance_data option is enabled globally and if the process_perf_data directive in the service definition is enabled.

Format

service_perfdata_file=<file_name>

Example

service_perfdata_file=/var/log/centreon-engine/service-perfdata.dat

Host Performance Data File Template

This option determines what (and how) data is written to the host performance data file. The template may contain macros, special characters (t for tab, r for carriage return, n for newline) and plain text. A newline is automatically added after each write to the performance data file.

Format

host_perfdata_file_template=<template>

Example

host_perfdata_file_template=[HOSTPERFDATA]\t$HOSTNAME$\t$HOSTOUTPUT$\t$HOSTPERFDATA$

Service Performance Data File Template

This option determines what (and how) data is written to the service performance data file. The template may contain macros, special characters (t for tab, r for carriage return, n for newline) and plain text. A newline is automatically added after each write to the performance data file.

Format

service_perfdata_file_template=<template>

Example

service_perfdata_file_template=[SERVICEPERFDATA]\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$

Host Performance Data File Mode

This option determines how the host performance data file” is opened. Unless the file is a named pipe you’ll probably want to use the default mode of append.

  • a = Open file in append mode (default)

  • w = Open file in write mode

  • p = Open in non-blocking read/write mode (useful when writing to pipes)

Format

host_perfdata_file_mode=<mode>

Example

host_perfdata_file_mode=a

Service Performance Data File Mode

This option determines how the service performance data file” is opened. Unless the file is a named pipe you’ll probably want to use the default mode of append.

  • a = Open file in append mode (default)

  • w = Open file in write mode

  • p = Open in non-blocking read/write mode (useful when writing to pipes)

Format

service_perfdata_file_mode=<mode>

Example

service_perfdata_file_mode=a

Host Performance Data File Processing Interval

This option allows you to specify the interval (in seconds) at which the host performance data file is processed using the host performance data file processing command”. A value of 0 indicates that the performance data file should not be processed at regular intervals.

Format

host_perfdata_file_processing_interval=<seconds>

Example

host_perfdata_file_processing_interval=0

Service Performance Data File Processing Interval

This option allows you to specify the interval (in seconds) at which the service performance data file” is processed using the service performance data file processing command. A value of 0 indicates that the performance data file should not be processed at regular intervals.

Format

service_perfdata_file_processing_interval=<seconds>

Example

service_perfdata_file_processing_interval=0

Host Performance Data File Processing Command

This option allows you to specify the command that should be executed to process the host performance data file”. The command argument is the short name of a command definition that you define in your object configuration file. The interval at which this command is executed is determined by the host_perfdata_file_processing_interval directive.

Format

host_perfdata_file_processing_command=<command>

Example

host_perfdata_file_processing_command=process-host-perfdata-file

Service Performance Data File Processing Command

This option allows you to specify the command that should be executed to process the service performance data file”. The command argument is the short name of a command definition that you define in your object configuration file. The interval at which this command is executed is determined by the service_perfdata_file_processing_interval directive.

Format

service_perfdata_file_processing_command=<command>

Example

service_perfdata_file_processing_command=process-service-perfdata-file

Orphaned Service Check Option

This option allows you to enable or disable checks for orphaned service checks. Orphaned service checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the service, it is not rescheduled in the event queue. This can cause service checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a service check. If this option is enabled and Centreon Engine finds that results for a particular service check have not come back, it will log an error message and reschedule the service check. If you start seeing service checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned services.

  • 0 = Don’t check for orphaned service checks

  • 1 = Check for orphaned service checks (default)

Format

check_for_orphaned_services=<0/1>

Example

check_for_orphaned_services=1

Orphaned Host Check Option

This option allows you to enable or disable checks for orphaned hoste checks. Orphaned host checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the host, it is not rescheduled in the event queue. This can cause host checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a host check. If this option is enabled and Centreon Engine finds that results for a particular host check have not come back, it will log an error message and reschedule the host check. If you start seeing host checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned hosts.

  • 0 = Don’t check for orphaned host checks

  • 1 = Check for orphaned host checks (default)

Format

check_for_orphaned_hosts=<0/1>

Example

check_for_orphaned_hosts=1

Service Freshness Checking Option

This option determines whether or not Centreon Engine will periodically check the “freshness” of service checks. Enabling this option is useful for helping to ensure that passive service checks are received in a timely manner. More information on freshness checking can be found here.

  • 0 = Don’t check service freshness

  • 1 = Check service freshness (default)

Format

check_service_freshness=<0/1>

Example

check_service_freshness=0

Service Freshness Check Interval

This setting determines how often (in seconds) Centreon Engine will periodically check the “freshness” of service check results. If you have disabled service freshness checking (with the check_service_freshness option), this option has no effect. More information on freshness checking can be found here.

Format

service_freshness_check_interval=<seconds>

Example

service_freshness_check_interval=60

Host Freshness Checking Option

This option determines whether or not Centreon Engine will periodically check the “freshness” of host checks. Enabling this option is useful for helping to ensure that passive host checks are received in a timely manner. More information on freshness checking can be found here.

  • 0 = Don’t check host freshness

  • 1 = Check host freshness (default)

Format

check_host_freshness=<0/1>

Example

check_host_freshness=0

Host Freshness Check Interval

This setting determines how often (in seconds) Centreon Engine will periodically check the “freshness” of host check results. If you have disabled host freshness checking (with the check_host_freshness option), this option has no effect. More information on freshness checking can be found here.

Format

host_freshness_check_interval=<seconds>

Example

host_freshness_check_interval=60

Additional Freshness Threshold Latency Option

This option determines the number of seconds Centreon Engine will add to any host or services freshness threshold it automatically calculates (e.g. those not specified explicity by the user). More information on freshness checking can be found here.

Format

additional_freshness_latency=<#>

Example

additional_freshness_latency=15

Date Format

This option allows you to specify what kind of date/time format Centreon Engine should use in the web interface and date/time macros. Possible options (along with example output) include:

Option

Output Format

Sample Output

us

MM/DD/YYYY HH:MM:SS

06/30/2002 03:15:00

euro

DD/MM/YYYY HH:MM:SS

30/06/2002 03:15:00

iso8601

YYYY-MM-DD HH:MM:SS

2002-06-30 03:15:00

strict-iso8601

YYYY-MM-DDTHH:MM:SS

2002-06-30T03:15:00

Format

date_format=<option>

Example

date_format=us

Timezone Option

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

Format

use_timezone=<tz>

Example

use_timezone=US/Mountain

Illegal Object Name Characters

This option allows you to specify illegal characters that cannot be used in host names, service descriptions, or names of other object types. Centreon Engine will allow you to use most characters in object definitions, but I recommend not using the characters shown in the example above. Doing may give you problems in the web interface, notification commands, etc.

Format

illegal_object_name_chars=<chars…>

Example

illegal_object_name_chars=`~!$%^&*”|’<>?,()=

Illegal Macro Output Characters

This option allows you to specify illegal characters that should be stripped from macros before being used in notifications, event handlers, and other commands. This DOES NOT affect macros used in service or host check commands. You can choose to not strip out the characters shown in the example above, but I recommend you do not do this. Some of these characters are interpreted by the shell (i.e. the backtick) and can lead to security problems. The following macros are stripped of the characters you specify:

$HOSTOUTPUT$, $HOSTPERFDATA$, $HOSTACKAUTHOR$, $HOSTACKCOMMENT$, $SERVICEOUTPUT$, $SERVICEPERFDATA$, $SERVICEACKAUTHOR$, and $SERVICEACKCOMMENT$

Format

illegal_macro_output_chars=<chars…>

Example

illegal_macro_output_chars=`~$^&”|’<>

Regular Expression Matching Option

This option determines whether or not various directives in your object definitions will be processed as regular expressions. More information on how this works can be found here.

  • 0 = Don’t use regular expression matching (default)

  • 1 = Use regular expression matching

Format

use_regexp_matching=<0/1>

Example

use_regexp_matching=0

True Regular Expression Matching Option

If you’ve enabled regular expression matching of various object directives using the use_regexp_matching option, this option will determine when object directives are treated as regular expressions. If this option is disabled (the default), directives will only be treated as regular expressions if they contain *, ?, +, or \.. If this option is enabled, all appropriate directives will be treated as regular expression - be careful when enabling this! More information on how this works can be found here.

  • 0 = Don’t use true regular expression matching (default)

  • 1 = Use true regular expression matching

Format

use_true_regexp_matching=<0/1>

Example

use_true_regexp_matching=0

Administrator Email Address

This is the email address for the administrator of the local machine (i.e. the one that Centreon Engine is running on).

This value can be used in notification commands by using the $ADMINEMAIL$ macro.

Format

admin_email=<email_address>

Example

admin_email=root@localhost.localdomain

Administrator Pager

This is the pager number (or pager email gateway) for the administrator of the local machine (i.e. the one that Centreon Engine is running on). The pager number/address can be used in notification commands by using the $ADMINPAGER$ macro.

Format

admin_pager=<pager_number_or_pager_email_gateway>

Example

admin_pager=pageroot@localhost.localdomain

Event Broker Options

This option controls what (if any) data gets sent to the event broker and, in turn, to any loaded event broker modules. This is an advanced option. When in doubt, either broker nothing (if not using event broker modules) or broker everything (if using event broker modules). Possible values are shown below.

  • 0 = Broker nothing

  • -1 = Broker everything

  • # = See BROKER_* definitions in source code (include/broker.h) for

    other values that can be OR’ed together

Format

event_broker_options=<#>

Example

event_broker_options=-1

Event Broker Modules

This directive is used to specify an event broker module that should by loaded by Centreon Engine at startup. Use multiple directives if you want to load more than one module. Arguments that should be passed to the module at startup are seperated from the module path by a space.

Format

broker_module=<modulepath> [moduleargs]

Example

broker_module=/usr/local/centengine/bin/ndomod.o cfg_file=/etc/centreon-engine/ndomod.cfg

Note

Do NOT overwrite modules while they are being used by Centreon Engine or Centreon Engine will crash in a fiery display of SEGFAULT glory. This is a bug/limitation either in dlopen(), the kernel, and/or the filesystem. And maybe Centreon Engine…

The correct/safe way of updating a module is by using one of these methods:

  • Shutdown Centreon Engine, replace the module file, restart Centreon Engine

  • While Centreon Engine is running… delete the original module file, move the new module file into place, restart Centreon Engine

Debug File

This option determines where Centreon Engine should write debugging information. What (if any) information is written is determined by the debug_level and debug_verbosity options. You can have Centreon Engine automaticaly rotate the debug file when it reaches a certain size by using the max_debug_file_size option.

Format

debug_file=<file_name>

Example

debug_file=/var/log/centreon-engine/centengine.debug

Debug Level

This option determines what type of information Centreon Engine should write to the debug_file. This value is a logical OR of the values below.

  • -1 = Log everything

  • 0 = Log nothing (default)

  • 1 = Function enter/exit information

  • 2 = Config information

  • 4 = Process information

  • 8 = Scheduled event information

  • 16 = Host/service check information

  • 32 = Notification information

  • 64 = Event broker information

Format

debug_level=<#>

Example

debug_level=24

Debug Verbosity

This option determines how much debugging information Centreon Engine should write to the debug_file.

  • 0 = Basic information

  • 1 = More detailed information (default)

  • 2 = Highly detailed information

Format

debug_verbosity=<#>

Example

debug_verbosity=1

Maximum Debug File Size

This option determines the maximum size (in bytes) of the debug file. If the file grows larger than this size, it will be renamed with a .old extension. If a file already exists with a .old extension it will automatically be deleted. This helps ensure your disk space usage doesn’t get out of control when debugging Centreon Engine.

Format

max_debug_file_size=<#>

Example

max_debug_file_size=1000000