Access Control Lists allow you to grant rights to Centreon users. You can grant users rights on:
the menus of the Centreon web interface,
the resources users can see,
the actions that can be performed in the Centreon web interface.
See also: Granting rights to Centreon users (ACL).
When a user acknowledges a resource in Centreon, they notify their teams that they are aware of the incident and that they will take action to resolve it.
When a resource is acknowledged, notifications are stopped, and the resource is highlighted yellow in monitoring screens.
Acknowledging a resource does not mean that the incident is over: it will be over when the resource is back to its nominal state (OK or UP).
See also: Acknowledging a problem.
Architecture: simple VS distributed
Simple architecture: architecture that consists solely of a central server.
Distributed architecture: architecture that consists of a central server and of n remote server(s) and poller(s). Remote servers and pollers allow you to distribute the monitoring load, either for security reasons, geographical or historical reasons, etc.
See also: Architectures.
See also: The BBDO protocol.
Centreon Broker is the software component that receives monitoring data collected by monitoring engines. Once it receives this data, by default, Centreon Broker redistributes them to the MariaDB and RRD databases.
See also: Centreon Broker Event Mapping.
Broker reverse mode
Advanced configuration for Centreon Broker that reverses the direction of connection for Broker communications. It switches the "client" and "server" roles so as to adapt to particular network configurations. For exemple, this mode is used by Centreon MAP to subscribe to the real-time flow of Broker events.
In Centreon, the central server is the main console where you monitor resources. The central server allows you to:
- configure the monitoring of your whole infrastructure,
- monitor resources
- see what all your Centreon servers monitor (central server, remote servers and pollers), using its web interface.
Command-Line API: allows you to manage the monitoring using the command line.
See also: Command Line API (v1) - CLAPI.
A downtime is a time period during which notifications are disabled for a resource. Downtimes are used during planned maintenance operations, to avoid getting unnecessary alerts.
See also: Planning a downtime.
See Monitoring engine.
Fully Qualified Domain Name: hostname and domain name for a server. E.g.: demo.centreon.com (hostname: demo, domain name: centreon.com).
Centreon Gorgone is the software component that allows the central server to send information to the remote servers and the pollers. Among other things, Gorgone deploys the configuration to the monitoring engines.
See also: Managing client/server communication and the other topics in this section.
See also: Charts management and the other topics in this section.
Principle according to which a parameter of a template is applied to the resource that inherits from this template.
Equipment that has an IP address or a FQDN, and that you want to monitor. Examples: a Linux server, an internet router, a website, a 3D printer, an EC2 instance, a docker host, a cash register, etc. A host can have one or more associated services.
A host can have one of the following statuses: OK, DOWN and UNREACHABLE.
See also: Monitoring a host and the other topics in this section.
LVM (logical volume manager): Centreon recommends that you use this partitioning system when you install your host system. It will allow you to live adjust the size of partitions and to use LVM snapshots for backups.
Feature included in LVM that allows you to do a snapshot of a file system. Centreon uses this process to back up databases.
See also: Backup.
A metric (or performance data) is part of a service. This piece of data allows you to display graphs, and to define thresholds according to which you will receive notifications. These thresholds will determine the status of the service the metric belongs to.
When a service has several metrics, the status of the service is the status of the worst metric.
You can see all metrics attached to a service in the details panel of the service.
Backup, in a text file, of a MySQL/MariaDB database.
Message that warns a user that an incident has occurred. You can configure notifications on various statuses.
See also: How notifications work and the other topics in this section.
One-peer retention mode
Advanced configuration for Centreon Broker that activates the retention mechanism in Broker inverted flow mode. This mode is commonly used for monitoring servers (pollers or remote servers) located in demilitarized zones (DMZ).
A plugin is a monitoring probe, i.e. a binary executable or a script that is called by the monitoring engine to carry out a check on a host or service. The plugin determines which status should be sent to the monitoring engine, based on the checks it makes and on the thresholds defined in the configuration of the host or service.
The term "Plugin pack" refers to a plugin and the corresponding pack.
A pack contains the configuration of the plugin in Centreon (command, templates, thresholds), as well as data required by the automatic discovery feature.
A poller has no graphical interface: the resources it monitors are displayed in the interface of the central server and of the remote server it is attached to.
"Poller" is also used to refer to the monitoring engine that is present in a central server, a remote server and a poller.
Advanced configuration for Centreon Gorgone that reverses the direction of ZMQ flows. The communication is initiated by pollers and remote servers, and is directed to the central server. This mode is commonly used by MSPs.
See also: Configuring Gorgone in pull mode.
Recurring downtimes are downtimes that occur regularly.
See also: Recurrent downtimes.
Centreon server used in a distributed architecture. A remote server is attached to a central server. Pollers can be attached to a remote server.
It has a graphical interface, but no configuration menus.
The resources it monitors are displayed in its interface, and in the interface of the central server it is attached to.
Retention files belong to Centreon Broker. These files store the monitoring data that could not be inserted into the database. For instance, if a communication problem occurs between Engine and Broker, the data is not lost, Broker stores them in a file (whose name includes the term "queue"). The file will then be read by Centreon Broker, then inserted into the databases so as to avoid data loss.
Time period, in days, during which you want to keep the data from your RRD and MariaDB databases.
An RRD file contains the data for a metric. RRD files are used to build performance graph. If there are no RRD files, graphs cannot be displayed. Because of the way RRD works, the data displayed in the graphs show a trend rather than the exact data that was measured.
See Monitoring engine.
A service is attached to a host. It is a check point on this host, that can relate to:
the status of a component: is the power supply connected? Is my instance started?
the performance of a component: is my website accessible in less than 0.5s? What are the ink levels on my printer? How much of the memory is used on my server?
A service can consist of one or several metrics.
A service can have one of the following statuses: OK, WARNING, CRITICAL, UNKNOWN.
See also: Monitoring a service and the other topics in this section.
Unhandled, acknowledged, in downtime.
the availability of a host (UP, DOWN, UNREACHABLE),
the availability or performance of a service (OK, WARNING, CRITICAL, UNKNOWN).
PENDING is not a status: a resource is "pending" when it has just been created and hasn't been checked yet.
See also: Possible statuses of a resource.
Indicates whether a change in status is confirmed (HARD) or not confirmed (SOFT). For instance, if a status becomes HARD, notifications are triggered.
See also: Status types.
Skeleton of a resource that is preconfigured so that parameters defined on the skeleton are applied to the resource that inherits from it.
There are host templates, service templates and contact templates.
Time periods define a time interval for each day of the week. They enable the functionalities of the monitoring engine over a given time slot. Use time periods to define:
when check commands are executed, i.e. the time period during which resources are monitored,
when notifications are sent.
See also: Time periods.
Configurable visual element that allows you to display data in a custom view.
See also: Custom views.