Skip to content

Conversation

@boxcee
Copy link

@boxcee boxcee commented Apr 13, 2023

I would like to add some bodies to the /health and /ready endpoints, please.

@boxcee boxcee requested a review from a team as a code owner April 13, 2023 18:27
@boxcee boxcee changed the title Add JSON body to /health and /ready endpoints feat: add JSON body to /health and /ready endpoints Apr 13, 2023
@sergey-melnychuk
Copy link
Contributor

Hi @boxcee , thank you for submitting a PR. I can't help but ask, what is the point of /ready & /health endpoints to respond with any payload and not just with response code?

@boxcee
Copy link
Author

boxcee commented Apr 13, 2023

Hi @boxcee , thank you for submitting a PR. I can't help but ask, what is the point of /ready & /health endpoints to respond with any payload and not just with response code?

Yeah, fair question.

  1. Personal: I want to implement a health check as simple HTTP request, but cannot parse the status code as the solution. The framework doing this only allows to parse the JSON response body.
  2. More general: I have been used to getting a few additional details in my health check. E.g. which component is unhealthy/unready? See the Spring Boot Actuator extension for example: https://www.baeldung.com/spring-boot-actuators#6-health-groups. I think it becomes more human readable and easier to debug.

@sergey-melnychuk
Copy link
Contributor

Personal: I want to implement a health check as simple HTTP request, but cannot parse the status code as the solution. The framework doing this only allows to parse the JSON response body.

What is the framework? I think it is very weird for a framework to not allow getting a status code out of a HTTP response.

More general: I have been used to getting a few additional details in my health check. E.g. which component is unhealthy/unready? See the Spring Boot Actuator extension for example: https://www.baeldung.com/spring-boot-actuators#6-health-groups. I think it becomes more human readable and easier to debug.

This PR adds no such additional information to a health-check nor a readiness probe anyway.

I believe the purpose of having /health and /ready probes is to enable orchestration via tools like K8s. Thus adding any human-readable data there makes no sense IMO, as a client cares only if a response is 200 OK or not.

If you need any custom probes/metrics/etc, you might want to add them (guarded by a feature flag) and expose via metric reporting to some kind of monitoring. But TBH I can't think of what those might be beyond existing reported metrics.

@Mirko-von-Leipzig
Copy link
Contributor

I think it might be nice to have more information for these endpoints. I can see splitting health into several segments like sync, rpc, p2p (oneday) would be useful - especially if one can add specifics when its not-healthy.

Similarly, we could do something like that for ready. It was originally my plan to have the different components register their readiness which would then display this status on this endpoint.

However, all of this is a lot of work for not much benefit at the moment and we are unlikely to devote time to this currently.

As @sergey-melnychuk mentions, having a framework not operate on the HTTP codes at all.. is weird. Which framework is it? And can you elaborate on how you use it?

@boxcee
Copy link
Author

boxcee commented Apr 14, 2023

Perhaps the use of framework here is a bit misleading. I am using a home automation setup for a lot of things at home. Now I am running a pathfinder node in my local network and would like to monitor its health via the automation setup. They have a multitude of integrations for all kinds of sensors, none for this use-case though. So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

I see it is a lot of work to actually implement the additional reporting for health and ready checks.

@Mirko-von-Leipzig
Copy link
Contributor

Mirko-von-Leipzig commented Apr 14, 2023

I am using a home automation setup for a lot of things at home.

Definitely not what I expected 😁

Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Yeah I see. I tried looking through the home automation issues, but I don't see anything related to http status codes so you are probably correct.

Some options:

  1. Keep a fork of pathfinder with your additions - this is of course a pita to maintain as you have to keep up with our releases each time.
  2. Write a small "proxy" server that hosts /health and /ready, forwards those to the actual pathfinder node, and maps the Ok(200) etc responses to json as you need for home assistant. This should actually be relatively small and simple to do in e.g. python / rust.
  3. Convince us to add json-bodies sooner rather than later 😅

I would also open an issue with home-assistant to add support for HTTP codes. Really funny to me that they support arbitrary json strings, but not the literal codes.

@kkovaacs
Copy link
Contributor

So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Would using a command_line binary sensor be an option? That way you could use curl to get the HTTP status code and use that. Like suggested here.

@boxcee
Copy link
Author

boxcee commented Apr 14, 2023

So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Would using a command_line binary sensor be an option? That way you could use curl to get the HTTP status code and use that. Like suggested here.

Hm, what can I say... Thank you! That did the trick.

@Mirko-von-Leipzig
Copy link
Contributor

Mirko-von-Leipzig commented Apr 14, 2023

Heh! Nice job @kkovaacs.

And thanks for reaching out and being proactive with a PR @boxcee.

@boxcee boxcee deleted the add-json-body-to-monitoring-endpoints branch July 17, 2023 07:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants