Drop /status endpoint

[philwebb]

We've discussed the /health and /status endpoints quite a bit and we were planning to switch them. After some more thought I'm thinking a simple property to enabled/disable the full details on /health might be enough.

The status and health endpoint are so similar in code and concept that I think having them both might actually be confusing. I think offering a single endpoint with a switch might be enough for most users.

If a user is running behind a firewall they can set the property to expose more details. If they are not running behind a firewall they can either stick with hidden details, or configure securirty.

The only use-case we've not covered very well is someone getting an alert from an insecure /health and then wanting to get more details about which specific aspect caused the problem. That seems like a fairly edge case so I'm tempted to see of people complain first.

It's pretty easy for us to re-introduce a new endpoint later. It's much harder for us to take an existing one away.

[pkostrzewa]

@philwebb could I try to switch these endpoints?

[philwebb]

@pkostrzewa Thanks for the offer, but I've already got this one in hand.

[snicoll]

That seems like a fairly edge case so I'm tempted to see of people complain first.

This is a feature of 1.5.x that our users are using (given the number of complains we got that the configuration part was confusing). I don't think dropping this is a good idea.

[bclozel]

Agree with @snicoll, I quite liked the separate endpoint as it made it easier to think about security and addressing two different use cases: automated health checks and incident response.

Now about the edge case side of this, I'd argue the other way around; unless you're deploying your app in an on-premise infrastructure and you can configure actuator on a separate port - any Spring Boot app serving public traffic would miss the health details.

Comparing this with our other issue (re: renaming the health endpoint), I think it's easier to reconfigure the path your health check client sends requests to (like AWS ELB health checks) than configuring it to send authenticated requests.

[philwebb]

I quite liked the separate endpoint as it made it easier to think about security and addressing two different use cases: automated health checks and incident response.

I guess I'm still not convinced that hitting a secured version of /health to get the additional information is something that actually happens during incident response. I don't know, perhaps it is, I'm hoping that this change will cause people that care to shout.

If you think about a monitoring system like Pingdom, the chances are that you want the full details payload to be returned. You want some history to be stored in Pingdom so that if the status changes back to healthy you still know what caused the problem.

I really don't know which way to jump with this one. I still think having both /health and /status feels wrong.

[snicoll]

We have another problem to deal with unfortunately. This change broke the CF integration as we don't show details by default anymore and I think we should as we deploy the endpoint in a separate space so that an administrator has full access regardless of how the app is configured.

(I've just pushed an app with master and I don't get any detail anymore).

[dbacinski]

Separate endpoints for /health and /status is a good idea, one can be used with authentication by humans to audit environment status with details that can contain sensitive data and second one can be used by monitoring tools and stay public.

[philwebb]

@dbacinski Do you currently rely on the existing Spring Boot 1.5 behavior where if you are authenticated you see more details?

[philwebb]

I'm going to close this one again for now. I'm not 100% convinced that removing /status is the right call, but I'm sure it's going to be easier to add it later than take it away. The CF issue has been fixed in #11192 and I've added a new enhancement request to see if a /ping endpoint would be a worthwhile addition (#11191).

[dbacinski]

I am using Spring Boot 2 M6 status and health enpoints. So what is a final result of this ticket? status is removed and only health with full data is available?

[wilkinsona]

status is removed and health is available with or without details depending on the value of the management.endpoint.health.show-details configuration property.

[HaVonTe1]

Hi. I was encouraged by @snicoll to describe my case here.
I have a lot of headache with the change behaviour of the 'health' endpoint.

We use docker swarm and sensu here to monitor our services. Both executing curl requests on /health and evaluating the response code. So no health indicator details necessary.
But as a developer I hardly need the details when something goes wrong and docker swarm is constantly killing my containers because status: down. Without the details I have no clue whats wrong.

So we secured actuator with basic auth. Un-authorized access from sensu / docker results in a handy http response code. Authorized requests from a developer showed the details. Perfect.

But know with Spring Boot 2 this feature is gone. My Admins refuse to make different curl requests separating SB1.5 und SB2.0 services.

Such a 'status' endpoint would solve my issue completely.

update
Showing the details with unauthorized access is sadly not an option. Our admins and security guys are concerned with exposing details like free disk space, version numbers of the rabbitmq, registered services on eureka and so on. I wont be able to argue about that.

update2
To make it more clear. It is sadly not an option to modify the healthcheck commands of docker and sensu to pass proper credentials. The devops refuse to do so. I know: a very poor argument.

[snicoll]

@HaVonTe1 Thanks for the feedback, we discussed about this during our team meeting today and we believe we should at least reconsider some form of support. I've created #11869