Spring-cloud-config: If config client health check fails, is the app really down?

Created on 27 Oct 2015  路  4Comments  路  Source: spring-cloud/spring-cloud-config

If it started and connected to config server, but can't now, is it down?

closable

Most helpful comment

+1 for this.

We actually ran into this issue about a week ago when the configuration server could not connect to github. The downstream clients also started reporting "down" status even though they really don't use the configuration server after startup (we are not yet using the refresh scope for dynamic configuration reloads)

I think having the clients contribute a health indicator for the configuration server is a bit aggressive and should be an opt-in feature rather than the default behavior.

All 4 comments

+1 for this.

We actually ran into this issue about a week ago when the configuration server could not connect to github. The downstream clients also started reporting "down" status even though they really don't use the configuration server after startup (we are not yet using the refresh scope for dynamic configuration reloads)

I think having the clients contribute a health indicator for the configuration server is a bit aggressive and should be an opt-in feature rather than the default behavior.

I agree - I don't think the client health check should check the config server. The check is for application default so it doesn't check if the specific config the client was started with is available. It can also cause issues with delaying the health check response significantly if the client is configured with a generous config retry policy. I'd like to see it be opt in too.

See #426

Hello,

I spent some time to figure out why sometimes a lot of my applications suddenly switch from UP to DOWN without real explanation.

I came across this issue and it appears that the explanation of my problems is here. By default, health check of each application includes a health check of the config server.

I see a big drawback checking the config server health. I think it is a kind of SPOF cause as soon as the config server is DOWN for any reason, all client applications switch to DOWN. When you're hosted in a Kubernetes cluster this can be even worse cause all containers that work perfectly are detected as unavailable then killed and restarted... but they can't restart because of the unavailability of the config server... in the blink of an eye, the entire platform goes down because of the failure of the config server.

I was wondering if the current behavior can be challenged (eg : not check config server by default) ? When an application starts, it is normal to consider the config server as mandatory but once started, the application can live without the config server.
I know it is possible to disable this check but I was wondering what was the reason why we check the health of the config server on the client side ?

Was this page helpful?
0 / 5 - 0 ratings