Circular dependencies in health check API's

[Bert Vanpeteghem]

Hi,

Considering https://microservices.io/patterns/observability/health-check-api.html

Ideally, the health of a service is determined by its own liveness ("am-i-up")+ the health of its dependencies ("aggregate"). 

We have health checks in place that can do both, but we would like our monitoring service to monitor the aggregate state of the services, so that we are alerted when a service is in a degraded state.

However, in a situation like this, a circular dependency would mean time-outs on the health checks. 

Service X -> Service Y -> Service Z -> Service X

Are we over-complicating things, or using a wrong approach? 

Bert

[Chris Richardson]

The scope of a health check should be limited to the service's infrastructure dependencies,. E.g. database connectivity, etc.

--
You received this message because you are subscribed to the Google Groups "microservices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microservice...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/cf412b12-973c-4813-ad06-707dd8f758f2n%40googlegroups.com.

[Bert Vanpeteghem]

Hi Chris, thanks for answering. 

What's the reasoning behind that?

Shouldn't the service's team be notified if a critical downstream service experiences issues?

Op vrijdag 17 september 2021 om 16:40:20 UTC+2 schreef ch...@chrisrichardson.net:

[Chris Richardson]

Sorry for the delay.

On Thu, Sep 23, 2021 at 2:07 AM Bert Vanpeteghem <vanpeteg...@gmail.com> wrote:

Hi Chris, thanks for answering. 

What's the reasoning behind that?

Shouldn't the service's team be notified if a critical downstream service experiences issues?

Sure. But the monitoring system knows the health of each service. It would be best to ask it. A service should just report its own health.