Hi @SavCent,

Why do you need to monitor several instances on the same host?

Given the templating features in Centreon, the simplest way to configure and the clearest way to read the statuses is to have separate hosts for instances.

Personally, I modified the oracle templates commands and services.But ideally I would also like to be able to do this without modifying the plugin.

Exemple ( App-DB-Oracle-Session-Usage ) :

$CENTREONPLUGINS$/centreon_oracle.pl --plugin=database::oracle::plugin --hostname='$HOSTADDRESS$' --port='$_SERVICEORACLEPORT$' --sid='$_SERVICEORACLESID$' --servicename='$_SERVICEORACLESERVICENAME$' --username='$_SERVICEORACLEUSERNAME$' --password='$_SERVICEORACLEPASSWORD$' --mode='session-usage' --warning='$_SERVICEWARNING$' --critical='$_SERVICECRITICAL$' $_SERVICEEXTRAOPTIONS$

$CENTREONPLUGINS$/centreon_oracle.pl --plugin=database::oracle::plugin --hostname='$HOSTADDRESS$' --port='$_HOSTORACLEPORT$' --sid='$_HOSTORACLESID$' --servicename='$_HOSTORACLESERVICENAME$' --username='$_HOSTORACLEUSERNAME$' --password='$_HOSTORACLEPASSWORD$' --mode='session-usage' --warning='$_SERVICEWARNING$' --critical='$_SERVICECRITICAL$' $_SERVICEEXTRAOPTIONS$

I also play with the port because the instances do not all listen on the same port

​​

Hi @omercier ,

We have many much server with multiple instances (ie : 100 server with 3 oracle instances by server). And each of the instances on the same server are software-interdependent. So we need to manage all the instances on the same hosts for consistency.

regards

Currently, the connection parameters are located on the host, which allows to set them once for all the services that monitor one instance. 

If the connection parameters were provided by the service instead of the host, you would have to:

• Manually create each service with a consistent name (e.g. <Instance name>-Tnsping, <Instance name>-Tablespaces-Global etc.) instead of having them created by template relations with generic names.
• Set the connection parameters on each service instead of setting them once on the host level
• You would not benefit of the Service Discovery feature since it relies on having the connection parameters on the host level

I don’t see how the idea you are suggesting would improve the configuration experience. Can you explain me how your usage would be if different from what I described?

Personally, I modified the oracle templates commands and services.But ideally I would also like to be able to do this without modifying the plugin.

Are you sure we are talking about modifying the plugin here?

What is your opinion on my previous message?

Is your configuration workload not increased by this change of commands and templates?

I actually modified the commands to have the port setting at the service level. I have a server which contains several instances (service name) and listening on multiple network ports (ex: @ip:1521 then same ip:1522 then 1523, then 1524, etc...).

I actually had to rework the service templates, it takes a long time to do the first time.

It took a long time to create the custom commands and templates, but do you agree that if you have to monitor a new instance, you’ll have to configure about ten new services instead of just one host?

In my perception, it requires more day-to-day workload to create/modify your services, so I don’t see how this would be an improvement for Centreon users.

This is precisely the problem. creating/duplicating all oracle services on a host by the number of SIDs it contains is not easy to maintain.

I was thinking of something like a macro (ORACLESIDs) where you could fill in several SIDs separated by a comma or something. And when the host services were deployed, they would be automatically created according to the SIDs entered in the macro.  

Regards

For me, a real improvement would be to be able to decide the port at the service level and to be able to have several sid/service names on the same host.

It's a pretty generic configuration to have a single host with multiple sid/service names listening on different listener ports.

We have discussed and this would not be a compatible behaviour with our plugins