How the GLPI Centreon plugin puts monitoring status next to assets
Operations teams that track hardware in GLPI and watch availability in Centreon end up with two sources of truth for the same hosts. An engineer looking at an asset record in GLPI sees purchase, location and ownership data, but has to switch tools to learn whether the server is up, which services are failing and whether someone already acknowledged the problem. The GLPI Centreon plugin addresses that gap by bringing host and service information from Centreon into GLPI, but only for items that exist in both tools. According to the GLPI plugin documentation for Centreon, the plugin shows general information about hosts and their services, lets users acknowledge a problem, schedule a downtime, trigger a host check and view the host timeline.
The plugin is the supported route, and it is a plugin-based integration rather than a generic connector. That matters for planning: the functions available, the data displayed and the way items are matched are defined by the plugin and by the Centreon API it calls, not by a custom mapping you build yourself. Before scoping the work, confirm the plugin version that matches your GLPI release, the Centreon version in your environment and the API account permissions the plugin needs to read status and to send write actions such as acknowledgements and downtimes. Write actions deserve a separate review, because an account that can schedule downtime from GLPI can also silence alerts in Centreon.
The practical question is how many of your GLPI assets have a counterpart in Centreon under a matching name or identifier. Items that exist only in GLPI will show no monitoring data, and hosts that exist only in Centreon will not appear on asset records at all. Ask your team to export both inventories and compare them before the build starts, and decide which system owns the host name. Teams that skip this step usually discover the gap after go-live, when a critical server appears with empty status fields.
What you need in place before connecting GLPI to Centreon
The Centreon plugin only works once GLPI, Centreon and the network between them agree on versions, addresses and trust. Settle these items first, because most failed connections trace back to one of them. Each card below is a item to confirm in your own environment before any plugin configuration begins.
GLPI version and deployment
Record the GLPI release your team runs, including whether it is a Linux install or the official Docker image, and whether the web server document root points to GLPI's public directory. Plugin releases are built for specific GLPI versions, so check the Centreon plugin documentation for compatibility with your exact GLPI release before you install anything. Ask the plugin maintainers which GLPI versions they test against.
Centreon version and API access
Confirm the Centreon version in production and that its API is enabled and reachable from the GLPI server. Write down the base URL the plugin will call, because it must match the address Centreon serves, including the path prefix if one is used. Confirm the API version your Centreon release exposes, since the plugin depends on it.
Network path from GLPI to Centreon
Trace the route from the GLPI web and worker hosts to the Centreon API endpoint, including any reverse proxy, load balancer or firewall rule in between. Open only the port and protocol the API listens on, and test it from the same host and user context that runs GLPI's automatic actions. A connection that works from your workstation can still fail from the GLPI server.
Certificate trust
If Centreon serves HTTPS with an internal certificate authority, install that CA chain on the GLPI server so PHP trusts it. Check that the certificate name matches the hostname in the plugin configuration. Disabling certificate verification may make the first test pass, but it leaves the credentials and monitoring data exposed in transit.
Dedicated Centreon account
Create a separate Centreon user for GLPI rather than reusing an administrator login. Grant only the rights the plugin needs to read host and service status, acknowledge problems, schedule downtime and run host checks, and confirm each right against the plugin documentation. Store the credentials in your secrets process and plan a rotation date, since the account is used by a scheduled integration.
Matching item naming
Decide how hosts in GLPI will be paired with hosts in Centreon before you connect, because the plugin only shows data for items present in both tools. Compare hostnames, FQDNs and any asset tag fields in each system, and pick one identifier as the source of truth. Mismatched names in the two tools are the most common reason expected hosts do not appear.
Configuring the Centreon connection and matching items step by step
This sequence connects GLPI to Centreon, confirms which GLPI items correspond to Centreon hosts, and turns on the monitoring actions only for the profiles that need them. Each step ends with a check you can see before moving on.
Install and activate the Centreon plugin
A GLPI administrator installs the Centreon plugin into the GLPI plugins directory, then activates it from the plugin management screen in GLPI setup. Confirm the plugin version matches the GLPI version you run, since GLPI 11 suspends plugins when it detects a new version and they must be reactivated after major updates. The step is done when the plugin shows as active and a Centreon entry appears in the GLPI configuration menu.
Create the Centreon API connection in GLPI
In the plugin configuration, enter the Centreon server address and the credentials of a dedicated Centreon account with only the rights the integration needs. Use a service account rather than a personal login so the connection survives staff changes. Record which Centreon account and which network path GLPI uses, because this is the first thing auditors and the Centreon team will ask about. The step is done when the connection settings are saved and the account is documented.
Test the connection before mapping anything
Run the connection test from the plugin configuration screen. A successful result means GLPI reached Centreon and the account authenticated. If the test fails, check network routing from the GLPI web server to the Centreon host, the Centreon API endpoint address, TLS trust for the certificate in use, and the account permissions in Centreon. Do not continue until the test passes, because every later check depends on it. The step is done when the test reports a successful connection.
Decide which GLPI itemtypes map to Centreon hosts
Decide which GLPI asset types should carry Centreon status, typically computers, network devices or servers depending on how your inventory is organized. Write the decision down with the owner of each asset class, because a Centreon host can only appear on a GLPI item that the plugin is set up to match. Ask the Centreon team which host groups or templates they want visible in GLPI, so the scope stays limited to systems that matter to operations. The step is done when the mapping list is approved and recorded.
Confirm matching items exist in both tools
For each mapped asset type, compare the identifiers in GLPI with the host names in Centreon and check that the same system appears in both under a consistent name. Mismatched names, duplicate records or assets that exist only in one tool will show no status in GLPI. Clean up naming in the system of record you choose to keep, and agree who owns the rule going forward. The step is done when a sample of assets shows Centreon host and service status on the matching GLPI item.
Enable actions for the right profiles
Enable acknowledge, downtime, host check and timeline actions only for the GLPI profiles that need them, such as the operations team, and leave them off for general requesters. Confirm the profile assignments with the people who will use them, since acknowledging a problem or scheduling downtime changes what Centreon users see. Test each action with a non-production host first, if your environment has one. The step is done when a test user with the operations profile can perform each action and a user with a read-only profile cannot.
Why matching items in both tools decides what GLPI shows
The Centreon plugin only displays host and service information for items that exist in both GLPI and Centreon, so the matching step decides what your technicians see on an asset. An asset that has no counterpart in Centreon shows nothing, and a monitored host that never appears in GLPI never reaches the asset record that owners and ticket queues use. Before go-live, choose the identifier both tools will share and confirm in the plugin documentation which key the plugin matches on. Do not assume it matches on hostname, FQDN, IP address or an asset tag until the documentation for your plugin version says so. The GLPI plugin documentation for Centreon is the place to start.
Duplicates and renamed hosts are the most common reasons status goes missing. If the same server exists twice in GLPI, for example once from an inventory agent and once from a manual entry, the plugin may link only one of them, and the other shows no status. A host renamed in Centreon but not in GLPI, or the reverse, breaks the link silently: nothing errors, the status simply does not appear. Ask your team to run a reconciliation before go-live. Export the host names from both tools, compare them against the chosen key, and list every item that appears in only one side. Resolve duplicates in GLPI first, since inventory sources will recreate them otherwise, and agree a rename procedure that updates both tools in the same change window.
Before go-live, review the naming conventions that feed the key, the owners of each side (who renames, who retires a host), and the process for new hosts added to either tool. Test the link with a small set of representative assets, including a clustered or virtual host, so you can confirm that acknowledgements and downtime requests land on the correct Centreon object. Record which items are intentionally excluded, such as network devices GLPI tracks but Centreon does not monitor, so that a missing status later is read as a known gap rather than an error.
Mapping Centreon hosts, services and actions to GLPI objects
This table maps each object and action in the Centreon plugin to the system that owns it and the permission each side needs. Read the Centreon column as the source of truth for state, checks and history, and the GLPI columns as the access rules that decide who sees or triggers them. Grant rights in both tools in pairs, then test each action with a non-administrator account before go-live.
| Object or action | Owned by Centreon | Permission needed in Centreon | GLPI profile to hold |
|---|---|---|---|
| Host matching | Host record that corresponds to a GLPI asset present in both tools | Read access to the host and its services | Read access to the asset type. Confirm the matching key in plugin settings |
| Host status and check output | Current host state, last check time and check output | Read access to the host | Read access on the asset item |
| Services on the item | Services attached to the host, with their state and output | Read access to the services of the host | Read access on the asset tab that lists services |
| Acknowledge a problem | Acknowledgement, comment and author recorded against the host or service | Acknowledgement right on the target resources. Confirm the exact Centreon ACL name | Plugin action right held by operators only |
| Schedule downtime | Downtime window and its comment stored in Centreon | Downtime right on the target resources | Separate plugin action right, not granted with acknowledge |
| Trigger a host check | Check scheduled and executed by the Centreon poller | Right to run checks on the host. Confirm whether it is a separate ACL | Plugin action right limited to on-call or support profiles |
| View host timeline | Event history for the host held in Centreon | Read access to host events | Read access on the asset. Timeline data stays in Centreon |
| Asset fields | Not changed by Centreon | Not applicable | GLPI owns name, location, owner, serial, status and contracts. Edit rights stay on the asset profile |
| Visibility scope | Contact groups or access rules that limit what the Centreon user can see | Read scope on the host groups used by the user | GLPI entity assignment limits which assets the profile can open |
Securing the Centreon API account and the actions it allows
The Centreon plugin gives GLPI users a path into your monitoring platform, so the risk sits in two places: the account GLPI uses to call Centreon and the GLPI profiles that decide who can act on alerts. The controls below cover both sides, plus the logs and network path that let you prove what happened.
Dedicated least-privilege Centreon account
Create a separate Centreon user for the GLPI plugin instead of reusing an administrator or a person's account. Grant only the rights needed to read host and service status and to perform the actions you intend GLPI to trigger. Confirm in your Centreon version which role or ACL group covers acknowledgement, downtime and check submission, because those rights are often bundled together. Review the account's rights after every Centreon upgrade.
Scoping hosts and actions by Centreon access groups
Use Centreon access groups to limit which hosts and services the plugin account can see and act on. A GLPI user who can acknowledge a problem on a payment gateway should not be able to do the same on a lab network. Map your GLPI entities or asset groups to Centreon groups where possible, and test with at least one out-of-scope host to confirm that GLPI shows no status and rejects actions for it.
Storing API credentials outside plain configuration
The plugin stores the Centreon API connection settings in GLPI's database, so treat them as secrets. Restrict who can open the plugin configuration page, rotate the Centreon password on a fixed schedule, and record who changed it. Keep GLPI's encryption keys backed up with the database, because encrypted values cannot be recovered from a database dump alone. Confirm with the plugin release you run how it handles these values.
Restricting GLPI profiles that can act
Viewing monitoring status and changing monitoring state are different privileges. Create GLPI profiles that can see host and service status but cannot acknowledge problems, schedule downtime or trigger checks, and assign the action rights only to operations or on-call roles. Check the plugin's rights for each action in your GLPI version, and test with a read-only user before go-live so you know the restriction holds.
Auditing actions in both tools
An acknowledgement or downtime started from GLPI should leave a trace in GLPI and in Centreon. Confirm that GLPI's logs record the user who clicked the action, and that Centreon records the API account as the actor, so you can match the two entries by time. Decide how long each system keeps these records, forward them to your central log platform if you have one, and test the match with a sample action before relying on it in an investigation.
Limiting the network path and TLS verification
Allow the GLPI server to reach only the Centreon web API endpoint, over HTTPS, from its fixed address. Keep certificate verification enabled and install the internal certificate authority in the GLPI server's trust store rather than turning verification off. Confirm the plugin's TLS and proxy settings for your deployment, and verify with a test call that a certificate mismatch fails closed.
Why Centreon status is missing or actions fail in GLPI
This table lists the failures teams most often hit when the Centreon plugin shows no status or an action such as acknowledging a problem or scheduling downtime fails. Each row gives the likely cause and the first check to run, so you can work through the symptoms in order before changing configuration. Start with item matching and the API connection, since most empty views trace back to one of those two.
| Symptom | Likely cause | First check |
|---|---|---|
| No host or service status shown | The GLPI asset does not match a host present in Centreon, so the plugin has nothing to display | Compare the asset name or identifier in GLPI with the host name in Centreon for the same device, and correct the mismatch |
| Connection test fails on the URL | The Centreon API URL in the plugin points to the wrong path, uses the wrong scheme, or includes a trailing segment the API does not expect | Open the API endpoint in a browser or with curl from the GLPI server and confirm it responds before editing the plugin settings |
| Connection test fails with a TLS error | The Centreon certificate is self-signed, issued by an internal authority GLPI does not trust, or does not match the host name used in the URL | Check the certificate chain from the GLPI server and confirm the host name in the URL matches the certificate subject |
| Connection test times out | A firewall, proxy or routing rule blocks traffic from the GLPI web or PHP host to the Centreon server | Test TCP reachability from the GLPI server to the Centreon host and port, and confirm the path is allowed in both directions |
| Authentication rejected | The API account credentials are wrong, expired, or the account is locked or disabled in Centreon | Confirm the account can sign in to the Centreon API with the same credentials outside GLPI |
| Acknowledge, downtime or check action is denied | The Centreon account lacks the permission or contact role needed for that action | Review the account's roles and access groups in Centreon and test the same action directly in the Centreon interface |
| Downtime appears at the wrong time | GLPI and Centreon use different time zones, or the start and end values were entered in a different zone than expected | Compare the server time zones of both systems and confirm the downtime window in Centreon after creating it from GLPI |
| Views or actions break after a GLPI upgrade | The Centreon plugin was not updated to a version compatible with the new GLPI release, or it was not reactivated after the upgrade | Check the plugin version and compatibility against your GLPI version, and confirm the plugin is active in the plugin list |
Questions teams ask before connecting GLPI to Centreon
How long does a GLPI and Centreon integration take?
Duration depends mostly on how many hosts and services need to appear in GLPI, how cleanly asset names match between the two tools, and how many people must sign off on API access. A small, well-named estate with one Centreon instance and a clear owner for each system moves quickly. Larger estates with duplicate names, several Centreon instances or strict change windows take longer. No fixed timeline is given here. Ask for a timeline that lists the discovery, matching, test and rollout phases separately, so you can see which phase your own environment will stretch.
Can our own team connect GLPI to Centreon without a partner?
Yes, if you have someone comfortable with both platforms, with access to create a Centreon API user and install and configure a GLPI plugin. The plugin's documented features are straightforward once the connection works: viewing host and service status for matched items, acknowledging a problem, scheduling a downtime, triggering a host check and viewing the host timeline. The harder part is usually agreeing on the matching rules, testing them on real data and documenting the result. A partner is most useful when you want that work scoped in writing, tested against your data and handed over with runbooks.
What do we need from our Centreon and GLPI administrators?
Both sides need to contribute time and access before the build starts. Centreon administrators should confirm which monitoring servers and hosts are in scope, create a dedicated API account with only the permissions the integration needs, and agree which actions (acknowledgement, downtime, forced checks) operators may perform from GLPI. GLPI administrators should confirm the entity and profile structure, who may see monitoring data, and where the plugin will be installed in a test instance first. Agree these decisions in writing, because they determine who can change monitoring state from a ticket or asset screen.
How do matching items affect the scope of the work?
The plugin only displays monitoring information for items that exist in both GLPI and Centreon, so matching is the main scope driver. Each host in scope needs a reliable link between its GLPI asset and its Centreon host, typically through a shared identifier or name convention. Where names differ, duplicates exist or assets were never inventoried, the team must decide whether to clean up data in one tool, add mapping rules or leave some hosts out. Ask the provider to produce a match report before quoting, listing matched, unmatched and ambiguous items, because that report sets the real effort.
Will the Centreon plugin keep working after a GLPI upgrade?
Plugins need checking after every GLPI upgrade, and this one is no exception. GLPI's update procedure requires backing up the database, files and the config directory, replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. That means you should confirm the Centreon plugin version supports your target GLPI release, test the upgrade on a copy of production, and plan a verification step that checks status display and the action buttons. Include plugin compatibility in your upgrade plan from the start.
Which GLPI release should the Centreon integration target?
Choose the GLPI release first, then confirm the plugin supports it. GLPI 12.0.0 was released on October 7, 2026, GLPI 11.0.11 on October 1, 2026 and GLPI 11.0.0 on October 1, 2025, according to the GLPI releases page. Newer releases add security and administration features, but they also change platform requirements. The GLPI 11 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, while the main README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later for the current branch. Confirm the plugin's supported versions against the release you plan to run.
What should a quote for this integration include?
A useful quote lists each deliverable and who performs it. Ask for the discovery and match report, the Centreon API account and permission design, the plugin installation and configuration in a test instance, the matching rules and any data cleanup, the test plan covering each action (acknowledgement, downtime, host check, timeline), the production rollout, and the operator and administrator documentation. Also ask what is one-time and what recurs, such as plugin updates tested after each GLPI upgrade, and which Centreon or GLPI changes would reopen the scope. DeployOpen does not publish a price list, and a quote follows from the written scope.
Which operator actions should we allow from GLPI?
Limit write actions to the roles that need them. The plugin can acknowledge a problem, schedule a downtime, trigger a host check and show the host timeline, and each of these changes monitoring state or generates load. A reasonable starting point is to allow read-only status for most GLPI users, and to restrict acknowledgement and downtime to on-call or service desk profiles inside the correct entities. Test each action with a named operator and record who is allowed to do it, so an audit trail in Centreon matches the people you expect.
How DeployOpen scopes and delivers a GLPI and Centreon integration
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, so the GLPI and Centreon connection runs in your environment under your access controls. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We confirm the GLPI and Centreon versions in use and the Centreon plugin version that matches them before any build begins.
- We inventory which hosts and services exist in both tools and agree how matching items will be identified.
- The written scope names which actions are in play: status display, acknowledgements, downtime scheduling and manual host checks.
How we build
- We configure the Centreon API connection from GLPI with a dedicated account whose permissions match the actions you approve.
- We test item matching on a sample of assets, then correct naming or identifier differences before wider rollout.
- We verify each action, including acknowledging a problem, scheduling downtime and triggering a host check, against a non-production Centreon instance.
How we hand over
- You receive documentation of API settings, account permissions, matching rules and the test results for each action.
- We walk through the operator steps for acknowledging problems and scheduling downtime, so support staff know who may run them.
- The handover records the GLPI and Centreon versions tested, so future upgrades can be checked against a known baseline.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover re-testing the integration when GLPI or Centreon is upgraded and the plugin needs a matching release.
- We agree in writing which changes count as support and which need a new scoped piece of work.
