Skip to main content

    Filter by idea status

    Filter by product

    644 Ideas

    gespadaBuilder ***

    NRPE Protocol on centreon-pluginsDeclined

    Hello,Recently I saw that there was the NRPE plugin apps::protocols:nrpe::plugin to trigger a command on a host https://github.com/centreon/centreon-plugins/blob/1a2ef498ea4cacb0ba90ff3adf9aba9e432d8684/centreon/plugins/nrpe.pmIs this functionality intended to be able to be integrated into the centreon-plugins in such a way that it is native and therefore that we can ignore the centreon-nrpe-plugin or centreon-nrpe3-plugin that is installed on the collectors and therefore involves the use of check_centreon_nrpe and check_centreon_nrpe3 commands ?In my idea, if it were feasible, we could ignore this plugin and therefore it could also simplify the plugin pack since it exists in NRPE (v2), NRPE3, NSClient++, API Rest NSClient++Moreover, this would make it possible to have only perl centreon-plugins apart for the status of the hosts and the use of check_icmp.I have this thought, because for a client of which we have an upgrade from 20.10 to 21.10 we change version of OS RHEL 7 to RHEL 8 and the depreciation of the standard NRPE especially for OS Linux but also Windows, generates a work of update of the NRPE agents in v4 (centreon-nrpe3-daemon) on the Linux system and above all a redesign of the host models and thus a redeployment of virtually all supervision.In my idea still 🙂, if this had been possible, it would have been necessary to deploy the latest versions of NRPE agents, NSClient++, but the host models would have been less impacted, with just changes in values of the HOST macros relative to the plugin options (--nrpe-version, --nrpe-payload, --nrpe-timeout and NRPEEXTRAOPTIONS)Is that a possibility to see that a day ?

    jdevroedDHLSteward **

    Uptime Kuma global external monitoringNeeds Votes

    I have raised this as a bug in the HTTP Loader and it was rejected there, yet, I have discussed this feature request with a Centreon support guys and he was keen on raising this again as a new feature, and not a bug.Allow me to explain why this feature would be absolutely great in Centreon...Many of my colleagues including myself have a server or NAS at home which is running uptime-kuma, and they have created a status page for DHL public internet services. These uptime kuma instances run locally, so we created a page to test from the source of every ISP in our part of the country…(from the principle: page of colleague A going down → ISP issue vs all pages showing issues → effective problem with our public services)https://uptime.kuma.pet/The enormous advantage of this tool is that is is freeware, largely deployed, available on all OSes and IOT devices and is not hosted in the cloud, hence you can really do checks per ISP.I would like to display such a service overview (the “external” view into our applications) within Centreon, but we are receiving a connection refused error…Other (PHP/HTML based) websites are displayed in the HTTP Loader correctly, but when I curl the UptimeKuma status page, no webpage body is displayed...I guess because the node.js parts are not renderedI could easily build a similar view in Wordpress, but the monitoring plugins in wordpress are running somewhere on a cloud subscription (and not locally) and this is a disadvantage: I do not want to provide a list of my company hosts to a third-party, and the monitoring then relies on the uptime of a single cloud subscription which is basically blackboxIf Centreon could create something similar to the HTTP Loader, this would allow the addition of http(S) monitoring from public webservices, from the public  perspective of various local ISPs, displaying it internally on the central monitoring solution