D4Science Infrastructure

Munin will be dismissed in a not so distant future, I hope. I'll add the node to the gcore ganglia cluster.

About the http check: is there a 'standard' URL to check the gcore nodes status? I see that the majority of the gcore checks are simply a test that the port is open.

Andrea Dell'Amico wrote:

Munin will be dismissed in a not so distant future, I hope. I'll add the node to the gcore ganglia cluster.

ok

About the http check: is there a 'standard' URL to check the gcore nodes status? I see that the majority of the gcore checks are simply a test that the port is open.

Yes, this is true but at the moment, I think, we don't have a better check for this type of service. @gianpaolo.coro@isti.cnr.it have you any idea about this?

Unfortunately, I don't have any information about this, especially since this is an old gCube (WSDL-based) service.
Maybe a call to the IS could do the job. For example, if there was an Out-of-Memory error, the service should not be able to update its status on the IS and this could result from the interrogation to the IS. @lucio.lelii@isti.cnr.it is there such a REST-like check? Alternatively, is there a means to monitor the machine service status in another way than asking to the service?

If the WSDL lives at a fixed position, the nagios check could try to fetch it.
A call to the IS to check a service that lives elsewhere seems too convoluted to me.

the simpler solution is to ask for the wsdl of one of the base services in gcore (eg. http://node1.d.d4science.research-infrastructures.eu:8080/wsrf/services/gcube/common/vremanagement/GHNManager?WSDL)

@lucio.lelii@isti.cnr.it could this solution be generalized for all ghn containers?

Yes, the ghnManager is installed on all gCore container

I think we could progressively migrate all checks "port based" to checks "wsdl based" , for every container gCore in production environment. If you agree on this, I'm going to open a new ticket with a list of all container involved in this task.