2

I have a microservice, lets call it microservice A. It talks to another microservice's REST endpoint, lets call that one microservice B.

I'm monitoring the health of microservice A using the Springboot actuator health endpoint.

I've had a code review comment that says that microservice A 'should' also be checking the health of microservice B's REST endpoint.

This doesn't seem quite right to me. To my understanding microservices should be autonomous and have a bounded context. ie microservice A should only be concerned with it's own health, A's health is A's responsibiilty and B's health is B's responsibily.

Does my understanding sound correct? Or have I missed something?

Johnny Alpha
  • 510
  • 1
  • 4
  • 7

3 Answers3

3

I think this is unusual. If service B has failed the health check then presumably calls to service B will result in the appropriate HTTP status code (404, 500 etc), and if that's the case then service A can raise it's own exception or handle the outage of service B gracefully (if that's possible).

So there is no need in a separate health check, it is the response code returned as a result of the call to service B that matters here.

gbro3n
  • 481
  • 2
  • 8
0

To answer this question, we could compare the approaches.

Reasons to Monitor Services

  1. Monitoring system signalling as a failure of micro service B. This helps the ops (or dev) team to down to business to quickly fix the issue.
  2. Monitoring system signalling as a failure of micro service A and B. Generally there is a map of functionalities to one or more micro services. So this helps the customer support (and management) to know which functionaries are not working.

Conclusion

So considering method 1 and 2, there is value in both the ways. Your company (or team) should choose one method and follow that consistently.

I would prefer to implement it as mentioned in method 2 because...

  • Easier to Implement.
  • There is more business value in it, as this could help customer support (and management) to know functionalities that are not working.
  • This also does not make it too difficult for the ops (or dev) team to find the error.
Nachiappan Kumarappan
  • 1,404
  • 1
  • 9
  • 19
  • 1
    Option 2 doesn't seem right to me as microservice A is taking responsibilty for microservice B's healthcheck. If you replace A and B with Cat and Dog :) Then the Cat service would be handling the Dog's business and vice versa! Dogs should do dog things and cats should do cat things! Dogs do not meow in the real world! The rule that I know is A is responsible for A things and B is responsible for B things. Or are the rules different when it comes to monitoring? – Johnny Alpha Oct 08 '19 at 11:06
  • 1
    If microservice B (Dog) is not working properly, then microservice A (Cat) that is dependent on microservice B (Dog) can not work. Would you say microservice A is working when database of A is down? Microservice A can get its data from a database or another service. – Nachiappan Kumarappan Oct 08 '19 at 11:12
  • Hmm A's private (micro) database is within A's bounded context, B is not according to the principles of DDD. – Johnny Alpha Oct 08 '19 at 11:51
  • I agree that the intention of DDD is to separate the services based on business functionalities. Now service A is depending on service B to full fill its business requirement. Can service A full fill its business requirements when service B is down? If service A can not full fill it's business requirements for what ever reason, then I would like to mark service A is down in monitoring so that impacted business requirements are clear. While monitoring I need to when business requirements of A is not met. I will get in to the reason if its a dependency failure or database failure later. – Nachiappan Kumarappan Oct 08 '19 at 14:33
0

The answer will depend on how the reviewer understood 'checking the health of microservice B's REST endpoint'. If service A needs service B to do its work, service A not working will actually cause cause service A to not work. Fixing it should be the responsibility of whoever maintains service B, but service A clearly is affected and you want to know that.

Now, you may say that it should be service B's responsibility to notice there was a problem. However, the definition of 'service B is working' may be different for service A and for service B. Service B may have many different clients, and each may require a different SLA. A response time of 200 ms may be OK for one service, but too slow for another. Centralizing all this knowledge at team B is not practical (especially since these requirements may change and may even the set of services that depend on service B), so it's easier for the client (service A) to check such metrics. Of course, they must communicate with team B and can't unilaterally require them to fulfill some arbitrary SLA.

Another issue is that due to network latencies etc., parameters measured on the servers's (service B) side, may be different than measured at the client (service A). For example, if there is a problem with the network, monitoring on server side may say that service B is up and running, but it might not be accessible from service A, or the response time may be very high due to network lag. So, you need monitoring of service B both at service B (this is clearly more important) and at service A (to handle some rarer cases).

Michał Kosmulski
  • 3,474
  • 19
  • 18