Introduce componentType that refers a health check service for recursive health checking

[ThB-bmiag]

Usually, our service architecture is recursivly depending on some levels of services and components. For every service, you could try to write down the dependent components services, but some of them depend on the same ressources, and some components are not directly related, but behind other servers. Therefore, I'd like to be able to specify components of type "service" (or similar) recursively refering a health check structure with its own components and so on.

[kalexmills]

You can do this recursively and then flatten the structure into the current json/healthcheck format. I do not see why the format itself needs to be recursive, as this will just complicate the specification and make it harder to parse.

[smoyer64]

Somewhat related to #51

I should also note that as we've implemented this in our services, we're moving away from returning the whole hierarchy as it's turning into a presentation concern (a nice UI). What's important is that each service return a top-level status calculated from its individual checks ... and that impacts are clearly stated.

[ThB-bmiag]

Quite often, services depend on some other services. Ususally, I just want to know whether the main service works and - if not, what services causes it to fail.
Maybe I want a drilldown in the second step, maybe the information is just enough. Therefore I don't want to show the entire stack all the way down to my basic hardware (quite often, it's not even allowed to show it for security reasons).

And yes: #51 is basically the same question/propose - sorry for doubling, this can be closed than...

[smoyer64]

I agree ... and we add a link to the underlying service's healthcheck end-point in each of the checks. What I'm saying is that we've realized that a) returning the entire hierarchy can be intensive and it's better to keep it smaller b) if it's another service that's acting on the healthcheck, it generally only cares about the status of its directly-dependent services and c) when a human wants to drill-down, it's better to do that in the UI.

So putting the links in the checks makes it dirt simple for the UI to drill-down ... it can do it eagerly and display a hierarchy or it can be lazy and display the next level of the hierarchy when a human clicks on it.

[kalexmills]

Off topic, perhaps, but is it a required part of this specification that each link returned by the healthcheck also respond with content of type application/healthcheck+json?

Should it be?

[smoyer64]

@kalexmills I didn't read the specification that way but it's an important clarification.

[kalexmills]

It goes without saying that if the links do not return the same content-type, the sort of recursive checking discussed here will be hindered.

Might be worth opening an issue to resolve.