Skip to main content

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.pm


Is 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 ?

Updated idea statusNew→Discussion ongoing

Hi @gespada 

 

Thanks for this very detailed post.

 

That was the purpose of the centreon-plugins NRPE client but I should say that the probability of breaking (a lot of) existing setup is reluctant. 

 

It’s a lot of work, maybe we will be able to see through the upvote system if many other might want this, but the pain point here will be the migration from one NRPE client to another.

 

From my point of view, we could imagine creating new templates relying on centreon-plugins NRPE client, deprecate the original ones, and then totally delete those after a while. 

 

What would you think the best solution? Does the process above would work in your migration scenario or do you have anything to propose?

 

Cheers,
Simon

 

​​

 

 

 

 

 

 

Hello @sims24,

Thanks for your reply.

 

Hi @gespada 

 

Thanks for this very detailed post.

 

That was the purpose of the centreon-plugins NRPE client but I should say that the probability of breaking (a lot of) existing setup is reluctant. 

 

It’s a lot of work, maybe we will be able to see through the upvote system if many other might want this, a..]

 

Cheers,
Simon

 

Yes if this idea create many breaking changes on the application, is not a good idea for you and the process of migration to describe.

 

Hi @gespada 

 

/...] but the pain point here will be the migration from one NRPE client to another.

 

From my point of view, we could imagine creating new templates relying on centreon-plugins NRPE client, deprecate the original ones, and then totally delete those after a while. 

 

What would you think the best solution? Does the process above would work in your migration scenario or do you have anything to propose?

 

Cheers,
Simon

 

I will try to move on centreon-plugins NRPE many NRPE command, at the exception of the Linux, Windows and others provided by the EPP. I think it’s a very good idea, because this way can abstract the usage of check_centreon_nrpe and check_centreon_nrpe3.

We will do switch all of Linux NRPE to Linux NRPE3 and same thing about Windows Server from NRPE to NSClient++ API Rest probably and also standardize to the EPP.

 

Updated idea statusDiscussion ongoing→Needs Votes
Needs Votes→Declined

This idea has not been highly voted. Moreover the standard NRPE plugin is compatible and available with all versions and will be shortly used by default in monitoring connectors.

Terms & ConditionsCookie settings