Hello,
I did a test of CMA version 24.10.12.
The test was done on a single host under Rocky Linux 9, monitoring himself.
I follow this documentation : https://docs.centreon.com/pp/integrations/plugin-packs/getting-started/how-to-guides/cma/cma-setup/
This will looks like a book of complains, because I only wrote for problems I found, things I was not happy with. Of course there is plenty of things who works well.
------------------------------------------------------------------------------------
The documentation
Can be improved, some information are not in the right order, there is some errors, and some parts are difficult to understand, specially for TLS
TLS
Forced TLS, with the agent shutting down if TLS is not enabled, is a pain; we all know when we need it. I was forced to restart the agent every hour during this test, each time wondering why it stopped working.
When it comes to TLS implementation, certain requirements are troublesome: file extensions are imposed (.cert was denied, you must name it .crt), as is the location of files (you cannot put your certificates in /home/certificates, for example).
TLS does not work with self-signed certificates, even when following the documentation. (Update: I was told that a poller that supervises itself via CMA is a special case).
Templates
Unfinished host and service templates: warnings are generated when generating the poller configuration, things that will go wrong or not work without manual corrections in the templates (currently being corrected according to Centreon).
Configuration via the UI is not practical at all once you have more than a dozen hosts.
Centreon says to use the API in this case -> very tedious and impractical, difficult for a support team to do on a daily basis.
Why can't you associate a configuration with a host configuration, as you can do, for example, to choose your poller for your host?
Can I ask my team to add host via the UI and use Postman to do REST request to map the agent config file to an host ? Definitely no.
How can I know witch agent configuration is mapped to an host ? You must open all the agent’s configuration and look if it’s listed. Painful, and no, using the API is not the easy way.
Customs commands
The documentation mentions /etc/centreon-engine-whitelist/my-whitelist.yml, but the folder does not exist, and its name is strange because it concerns the agent and Engine. Couldn't it be in /etc/centreon if it concerns all of Centreon?
We do not know if the rules by host are additive or replace the default ones.
Portability (if you have more than only Linux/Windows)
The agent requires centreon-plugins for basic services, installed via package. This makes the use of officially unsupported operating systems very difficult, if not impossible, unless you do a lot of work on custom commands and fiddle around with external scripts/probes.
Ressource view, holes in the racket, and some troubles
In Agent -> Poller mode, nothing in the Resource view indicates that these are passive services; there is no column indicating this, unlike in the history views.
Forcing a check on a basic service, such as “Uptime” and “Swap,” Swap“ -> puts an error message ”(Execute command failed)" in the service status and the status in Unknown, before returning to OK about 10 seconds later.
As for the graphs of these services reported via OTL, many are very difficult to use with metrics that do not display object identifiers (e.g., partition names). We have graphs with several metrics that have the same name and we don't know what they refer to, making the graphs unusable.
Some of the services checked by the CMA agent do not display the command in the service details -> Debugging and maintenance of services is impossible, as the order cannot be reproduced in a terminal.
Ex: CPU, Disks, etc.
Customs commands.
This is a major change that will have a significant impact on those using scripts via NRPE/NSClient++.
It is no longer possible to run free commands on hosts as was possible with NRPE / NSClient++.
Previously, a server administrator could develop a script, place it on their server, and declare it in NRPE / NSClient++.
They could then request that a Centreon service linked to their server be added to call this script. This gave server administrators a great deal of freedom and simplified configuration on the Centreon side, as a simple “check_nrpe” call was made, specifying the command on the server side as an argument.
Example: /usr/lib64/nagios/plugins/check_nrpe -H 10.128.41.89 -c check_drbd -a 0 Primary. This command simply asks host 10.128.41.89 to execute the “check_drbd” command with the following arguments.
With CMA, you must declare all command lines on the Centreon side and play around with whitelists (i.e., manually on the pollers, which is complicated if you have several pollers), so you declare things on the Central that are local to a single server, a remote server that may not even belong to you.
Conclusion
At the time of writing, CMA and it’s integration into Centreon are not mature.
More works must be done, mainly in the UI, but some in the backend (portability, customs commands)
But it looks promising.