Split health endpoint in two endpoints for overview and detailed status

[snicoll]

Currently /application/health is quite complex as it can display full details or only a single status based on various conditions. In our effort to revisit the actuator in Spring Boot 2, we intend to split the health endpoint in two separate endpoints:

• /application/health is the existing endpoint and shows full details with no additional logic to switch to a single status
• /application/status shows the status (and only that)

Both endpoints can be enabled and/or secured separately.

[mbhave]

If we decide to change the response of /application/health, the Cloud Foundry Apps Manager UI will need to adapt accordingly. Just something to keep in mind when working on this.

[snicoll]

The response will not change. The difference is that either it will provide the full details or nothing at all depending on whether the current user has the right to access the endpoint or not. Does that impact the CF stuff?

[jeffbswope]

Thumbs up but I would suspect most current monitoring tools which care at all expect at least status from the /health endpoint rather than by default connecting with privileges and parsing the full output. We have examples of both here though...

I guess depending on how they discover the endpoint URL those that wanted to could prefer the status endpoint if it exists or be tricked into health=/status if it's configured manually. Which would prevent them from having to be aware which monitored services were 1.x vs 2.x.

[mbhave]

@snicoll thanks for clarifying. In that case, it should not affect the CF behavior. In fact, if /application/health always exposes the full details, we would not longer need CloudFoundryHealthMvcEndpoint.

[philwebb]

@jeffbswope We're planning to add the /application prefix anyway so existing tools would need to migrate from /health to /application/health regardless of the new endpoint.

[jeffbswope]

@philwebb Yes and I think people will be happy with that. I was using shorthand above as we have always used management.context-path=/manage and unsure yet if we move to standard or stay with /manage for 2.x.

In any case thumbs up still -- just wanted to mention the potential impact (on little things outside your control which are perfectly reasonable to impact with a major release!)