Skip to main content

Getting Started

Getting Helped

Webinars & Tutorials

Product How-To

How-To

How to migrate from NSClient++/NRPE to the Centreon Monitoring Agent?

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.If you're already using NSClient++ or NRPE with Centreon, this guide will help you gradually switch to Centreon Monitoring Agent. The Centreon Monitoring Agent offers a number of advantages over NSClient and NRPE:  Better performance in executing controls, i.e. reduced impact on the host. Enhanced security, implemented by default (TLS encryption, authentication token). Easy configuration with a dedicated interface, especially for connection security. An "offline" mode for installing plugins on hosts without internet access. Command-line installation mode for mass deployment under Windows. A monitoring method based solely on passive checks. Full Centreon support and dedicated roadmap.   Agent deployment & configuration First create a token using the dedicated interface (Administration > Authentication Tokens)The same token can be used for one or more pollers and agents. Then deploy and configure the Centreon Monitoring Agent using the documentation.The public certificate and private key (.key) must be stored on the poller (/etc/pki) with the appropriate rights.The public certificate (.crt) must be stored on the host, and configured within the agent.The poller endpoint must match the poller's DNS, and the certificate's Common Name.You can generate a self-signed certificate on the poller using the following command:Warning: the Common Name (here: "poller") must match the DNS used to configure the agent on the host. openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout /etc/pki/agent.key -out /etc/pki/agent.crt -subj '/CN=poller' -subj '/CN=poller'.Monitoring configuration Install the dedicated Windows and/or Linux Monitoring connectors (as required)Here is the correspondence with NSClient/NRPE Connectors:  Windows NSClient API Windows Centreon Monitoring Agent Windows NSClient 0.5 NRPE Windows Centreon Monitoring Agent Linux NRPE4 Linux Centreon Monitoring Agent  Modifying host templates on existing resources (hosts)Here is the correspondence with NSClient++/NRPE host templates:  OS-Windows-NSClient-05-Restapi-custom Windows Centreon Monitoring Agent OS-Windows-NSClient-05-NRPE-custom Windows Centreon Monitoring Agent OS-Linux-NRPE4-custom Linux Centreon Monitoring Agent  Adapt/replace existing servicesCentreon plugin commandsThese are the same plugins as those for NSClient/NRPE; only the command changes.Macros with the same name are kept, so you can replace the existing service template with the one linked to the Centreon Monitoring Agent.For example: OS-Linux-Memory-NRPE4 → OS-Linux-Memory-NRPE4-customNative check commands (NSClient)The Centreon Monitoring Agent provides native checks that differ in structure (JSON command) from those of NSClient++ and the rest of the Centreon ecosystem.It will be necessary to create a new service or modify the existing service template by adapting the macros.For example: OS-Windows-NSClient05-NRPE-Cpu or OS-Windows-NSClient05-Restapi-Cpu→ OS-Windows-Centreon-Monitoring-Agent-CPUCustomizable check commandsThese scripts remain compatible with the Centreon Monitoring Agent. You will need to adapt the commands (or duplicate them to work in double run mode).

how-to

How to obtain access point users without UNKNOWN status

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.The purpose of this topic is to share with you the solution to obtain the number of users connected on an access point, and the way to find it.The targetThe first and obvious solution was to use the Centreon plugin dedicated for this service : centreon_cisco_wlc.pl, with the ap-users mode. The syntax is like this :/usr/lib/centreon/plugins//centreon_cisco_wlc.pl --plugin=network::cisco::wlc::snmp::plugin --mode=ap-users --hostname=x.x.x.x --snmp-community='x' --snmp-version=2c --filter-group='' --warning-total='' --critical-total='' --snmp-autoreduce --snmp-timeout=30 --filter-counters='^ap' --filter-ap='apName'The important point is the IP to provide is Wireless Controller’s IP.The issueWhen there is only few access points (AP) associated to the wireless controller, the plugin works fine ; but when many access points are connected to the wireless controller (WLC), many UNKNOWN issues can appear. To understand the root cause of this behaviour, tcpdump and Wireshark are good tools to troubleshoot.The result of the analysis is the following :The poller sends a request to know the name of all the AP It receives all the answers It asks the user number to all the AP It receives all the answers It matches 2. and 4. answers, and publishes the resultThis process is done for all the AP, so it’s very resource consuming, and can create UNKNOWN alerts.How to obtain the number of user ? The value can be found with a MIB (mibs.observium.org/mib/AIRESPACE-WIRELESS-MIB/), bsnAPIfLoadNumOfClients, which is .1.3.6.1.4.1.14179.2.2.13.1.4.But it’s not enough, because the AP is missing on this MIB. The complete MIB is given by .1.3.6.1.4.1.14179.2.2.13.1.4.A.B.C.D.E.F.a (a is 0 for 2.4 GHz and 1 for 5 GHz).What is A.B.C.D.E.F ?It was the more difficult point to fix on this investigation. It comes from the Radio MAC address of the access point. If the Radio MAC is ab12.cd34.ef56, then the conversion provides 171.18.205.52.239.86.So finally, for this AP, the number of users is given by :.1.3.6.1.4.1.14179.2.2.13.1.4.171.18.205.52.239.86.0 (2.4 GHz) .1.3.6.1.4.1.14179.2.2.13.1.4.171.18.205.52.239.86.1 (5 GHz)How to display the value ?The last step is to create the service with the value. It seems better to group both values (2.4 and 5 GHz) on the same service, with this syntax :/usr/lib/centreon/plugins//centreon_generic_snmp.pl --plugin=apps::protocols::snmp::plugin --mode=numeric-value --hostname=x.x.x.x --snmp-community='x' --snmp-version=2c --oid='' --format='current value is %s' --warning= --critical= --config-json='[ { "oid": "1.3.6.1.4.1.14179.2.2.13.1.4.171.18.205.52.239.86.0","perfdata_name": "2.4GHz", "format": "2.4GHz users %s"},{ "oid": "1.3.6.1.4.1.14179.2.2.13.1.4.171.18.205.52.239.86.1", "perfdata_name": "5GHz", "format": "5GHz users %s"} ]' --snmp-timeout=30  Hoping it can be an help for some of you,

How-To

How to change a log level in Broker/Engine without restarting them

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.Introduction Sometimes you have an issue with Engine or Broker and you would like to change a log level to understand the issue, for example change the sql log level to trace but without reloading/restarting Broker because otherwise you will lose the issue you encounter.Thanks to the gRPC API provided by Engine and Broker, it is possible. About the gRPC API Nowadays, Broker and Engine have a gRPC API accessible directly from localhost. If you execute the following command on your central server:ss -plant | grep cbd | grep LISTEN… you will get something like this:Each line represents a TCP server. Here we are interested in the ones with ports in the [51000, 51999] range. You can see four lines with ports 51001 or 51002 in the example.These ports can be different on your platform, so make sure you test your configuration.We have two instances of Broker, so 51001 is the port used by the first one and 51002 is the port used by the second one.If we run a similar command for Engine:ss -plant | grep centengine | grep LISTEN… then we get something like:This time we get two lines with the same port. The gRPC API for Engine is in the [50000, 50999] range, and in the example we can read 50618. Communicating through the gRPC API If you want to talk to Engine or Broker through their gRPC API, you have to install the ccc tool. Depending on your distribution, you can install it using:apt-get install centreon-collect-clientordnf install centreon-collect-clientTo check it is correctly installed, run the following command (51001 is the listening port for Broker or Engine):ccc -p51001The answer you receive should look like this:To get help on the program, use the following command: ccc --help   To list the available commands:   ccc -p51001 --list   It is important to note that the answer is not the same when querying Broker or Engine. Functions about logs In the case of Broker, the answer contains these lines:So we have two functions about logs:The first one to get info about loggers The second one to change a log level.Let’s try the first one. We can start with:ccc -p51001 --help GetLogInfoSo we know this function needs a string argument. We also know this string can be empty. Let’s try it:ccc -p51001 'GetLogInfo{}'Then we get some information about all the loggers:And if we want information about the sql logger, we can just enter:ccc -p51001 'GetLogInfo{str_arg:"sql"}' Setting a log level Now, let’s take a look at the second function, SetLogLevel.ccc -p51001 --help SetLogLevelHere the function needs two arguments: the logger name and the new level. Let’s try to change the sql level to debug:​​​​​​​ccc -p51001 'SetLogLevel{logger:"sql", level:"ERROR"}'We can then check the level is the correct one:​​​​​​​ccc -p51001 'GetLogInfo{str_arg:"sql"}' Conclusion As you can see, we were able to change the log level of the sql logger without reloading or restarting Broker. Bear in mind that this change is temporary: the next time Broker or Engine is restarted (e.g. when you deploy the configuration), the log level will revert to the value defined in the interface. 

How-TO

How to create automatic tickets on ITSM tool with Open-Tickets extension

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.In this article we will see how to create automatic tickets in your favorite ITSM tool with Open-Ticket module. What is the Open-Ticket module? If you are here and want to automation this, you already know this… but a reminder is never useless.This module is designed to easily create formatted tickets on an ITSM tool and in case of API usage, have the ability to automatically acknownledge hosts and services with ticket number in Centreon over custom view and a dedicated widget.You can find most informations about ITSM tool supported in the online documentation here. What is the automatic creation ticket objective? By default, Open-Ticket is able to manually create a ticket through an API call or by email. You select your alert service and click on “create a ticket”.Automation frees you from these manipulations by automatically sending information to your ITSM tools.How do I implement the automation? We start of principle the open-ticket module is installed and works correctly. If not, follow this procedure: https://docs.centreon.com/docs/alerts-notifications/ticketing-install/Step 1: Install the plugin to manage notificationsInstall it on all your pollers able to send notifications (central too if makes monitoring)On Debianapt install centreon-plugin-notification-centreon-opentickets-apiOn RHEL / Alma Linux / Oracle Linuxdnf install centreon-plugin-Notification-Centreon-Opentickets-ApiStep 2: Create the notification commands on the UIGo to Configuration > Commands > Notifications menu Create two new commands for host and service notifications like this:For host:$CENTREONPLUGINS$/centreon_notification_centreon_opentickets_api.pl --mode=open-host --api-hostname=<CENTRALNAME_OR_IP> --api-username=<CENTREONUSER_LOGIN> --api-password='<CENTREONUSER_PASSWORD>' --rule-name=<OPENTICKET_RULE_NAME> --host-id=$_HOSTID$ --host-state=$HOSTSTATE$ --host-output="$HOSTOUTPUT$" --last-host-state-change=$LASTHOSTSTATECHANGE$For service:$CENTREONPLUGINS$/centreon_notification_centreon_opentickets_api.pl --mode=open-service --api-hostname=<CENTRALNAME_OR_IP> --api-username=<CENTREONUSER_LOGIN> --api-password='<CENTREONUSER_PASSWORD>' --rule-name=<OPENTICKET_RULE_NAME> --host-id=$_HOSTID$ --service-id=$_SERVICEID$ --service-state=$SERVICESTATE$ --serviceoutput="$SERVICEOUTPUT$" --last-service-state-change=$LASTSERVICESTATECHANGE$with:<CENTRALNAME_OR_IP> : Centreon URL or IP<CENTREONUSER_LOGIN> : admin user without access to the UI (see creation below)<CENTREONUSER_PASSWORD> : his password<OPENTICKET_RULE_NAME> : Open-tickect rule namethe result could be like this for host notification:You can add some other informations in the command line like custom message, selected value in dropdown list (for example your workspace or the team to affect or the priority of the ticket), in fact all the mandatory fields to create a ticket --extra-property='custom_message=automatic opening' --select='jira_project=Support' --select='jira_issuetype=Send Issue'where “jira_project” is the name of the project field in Jira and “Support” is the project name to affectThe field names and his values are defined in your ITSM tool and getted by open-ticket to manage it.Save it.Step 3: Create a dedicated user for those commandsGo to Configuration > Users > Contacts / Users menu and create a new user:No need a valid email because using APINo need a UI accessNeeds admin rightsSet classicaly the notification options you need and commands created previouslySave your new contact.Step 4: Define hosts or services you want to automatically create ticketAs same as other notifications, set the dedicated open-ticket notification contact and notification options (timeperiod and statuses) to the hosts and services you want to automatically create tickets.Save and export the configuration on pollers needed. Be carreful to fully qualified hosts and services selected for automation to avoid a lot of tickets on your ITSM tool. That’s all. Have fun to resolve your automatically created tickets.

Troubleshooting

Troubleshooting

I can't install/upgrade a Centreon 22.10 on CentOS7 (CentOS 7 end of life)

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.This article concerns Centron 22.10. (If you are using an earlier version, you need to migrate your platform to a supported OS and a supported version, as versions older than 22.10 are no longer supported.) Problem On June 30 2024, CentOS 7 reached its end of life.Here are several things that may impact existing CentOS 7-based servers: mirrorlist.centos.org is offline mirror.centos.org is also offline. This means that you will get an error if you try to run a yum install or yum upgrade command on a Centreon 22.10.SolutionIf you get this error, you should replace all your occurrences of mirrorlist.centos.org, mirror.centos.org by vault.centos.org in all CentOS repofiles. The repo files can be found in /etc/yum.repos.d:-rw-r--r-- 1 root root 1661 Jul 1 15:32 CentOS-Base.repo-rw-r--r-- 1 root root 1308 Jul 1 15:32 CentOS-CR.repo-rw-r--r-- 1 root root 649 Oct 23 2020 CentOS-Debuginfo.repo-rw-r--r-- 1 root root 630 Oct 23 2020 CentOS-Media.repo-rw-r--r-- 1 root root 970 Jul 1 15:33 CentOS-SCLo-scl-rh.repo-rw-r--r-- 1 root root 996 Jul 1 15:33 CentOS-SCLo-scl.repo-rw-r--r-- 1 root root 1332 Jul 1 15:32 CentOS-Sources.repo-rw-r--r-- 1 root root 8515 Oct 23 2020 CentOS-Vault.repo-rw-r--r-- 1 root root 313 Jul 1 15:32 CentOS-fasttrack.repo-rw-r--r-- 1 root root 614 Jul 1 15:32 CentOS-x86_64-kernel.repoFor each CentOS repofile, comment mirrorlist uncomment baseurl and replace mirror.centos.org by vault.centos.org  Here is an example:# CentOS-Base.repo## The mirror system uses the connecting IP address of the client and the# update status of each mirror to pick mirrors that are updated to and# geographically close to the client. You should use this for CentOS updates# unless you are manually picking other mirrors.## If the #mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead.##[base]name=CentOS-$releasever - Base#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infrabaseurl=http://vault.centos.org/centos/$releasever/os/$basearch/gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7#released updates [updates]name=CentOS-$releasever - Updates#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infrabaseurl=http://vault.centos.org/centos/$releasever/updates/$basearch/gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7#additional packages that may be useful[extras]name=CentOS-$releasever - Extras#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infrabaseurl=http://vault.centos.org/centos/$releasever/extras/$basearch/gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7#additional packages that extend functionality of existing packages[centosplus]name=CentOS-$releasever - Plus#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infrabaseurl=http://vault.centos.org/centos/$releasever/centosplus/$basearch/gpgcheck=1enabled=0gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 

Troubleshooting

Generating SNMP trap is not working

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments.This article explains how to troubleshoot the SNMP trap generation through the user interface.Symptom You are trying to generate a trap as follows:But nothing happens. No trap logged in /var/log/messages or /var/log/snmptrapd.log Solution Make sure the trap is enabled by following the Enable SNMP Traps documentation. Make sure centreon-gorgone (user+groupe) is the owner on a poller:ls -l /etc/snmp/centreon_traps/centreontrapd.sdb But it could be in a subdirectory. For example for a central or a remote:ls -lR /etc/snmp/centreon_traps/ If centreon-gorgone is not the owner, you need to set it on the poller as below:chown centreon-gorgone. /etc/snmp/centreon_traps/centreontrapd.sdb For a central or remote server, apache (or www-data for Debian) should be the owner, not centreon-gorgone:chown -R apache. /etc/snmp/centreon_traps/ Try to generate the trap again as follows. It should be working now!  Still stuck? If the service centreontrapd still doesn’t start, enter the following command:systemctl status centreontrapd The partition is probably full:df -hdf -i Enter this command to clean old traps:rm -rf /var/spool/centreontrapd/ This time, the trap generation should work. The logs should provide information about the trap.

Troubleshooting

"1451 Cannot delete or update a parent row: a foreign key constraint fails" error message

Please note that the only procedures supported and maintained by Centreon are those published in the official documentation. If you have a question about this article, post it in the comments. Symptoms When trying to delete an object (like a host, service, contact or image, etc.), you get a blank page as below:   Deleting a host   Deleting a service  Deleting an imageYou get this type or error in /var/log/php-fpm/centreon-error.log: [16-Jan-2023 11:36:38 Europe/Paris] PHP Fatal error:  Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`centreon`.`host_service_relation`, CONSTRAINT `FK8v725mivdxvnvc9n3ptx6b8bg` FOREIGN KEY (`service_service_id`) REFERENCES `service` (`service_id`)) in /usr/share/centreon/www/class/centreonDB.class.php:263 Stack trace: #0 /usr/share/centreon/www/class/centreonDB.class.php(263): PDO->query() #1 /usr/share/centreon/www/include/configuration/configObject/service/DB-Func.php(396): CentreonDB->query() #2 /usr/share/centreon/www/include/configuration/configObject/service/serviceByHost.php(193): deleteServiceInDB() #3 /usr/share/centreon/www/main.get.php(272): include_once('...') #4 {main}   thrown in /usr/share/centreon/www/class/centreonDB.class.php on line 263  Solution   Stop httpd, php-fpm and crond services using this command:systemctl stop httpd* php-fpm crond Make sure services are stopped:systemctl status httpd* php-fpm crond Make a mysqldump of Centreon database:mysqldump -h IP -u USER -pPASSWORD centreon > /tmp/dump_centreon.sqlList the constraints:mysql -u<databaseuser> -puse information_schema select Concat('ALTER TABLE ',TABLE_NAME, ' DROP CONSTRAINT `', CONSTRAINT_NAME, '`;' ) INTO OUTFILE '/tmp/output.sql' from TABLE_CONSTRAINTS where CONSTRAINT_NAME like BINARY 'FK%';Delete | and add ; with the following command:sed 's/^| //' /tmp/output.sql | sed 's/|$//' | sed 's/[[:blank:]]*$//' | sed 's/$/;/' > /tmp/output_2.sqlApply changes:mysql centreon < /tmp/output_2.sqlStart httpd, php-fpm and crond services:systemctl start httpd* php-fpm crondFor debian : systemctl status apache2 php8.1-fpm cronNow everything should work regarding the configuration on the interface!The 1451 Cannot delete or update a parent row: a foreign key constraint fails error should not appear in /var/log/php-fpm/centreon-error.log anymore.

Need more help?

Terms & ConditionsCookie settingsAccessibility statement