Should health checks expose /app/health ?

[Emily-Jiang]

In the design, it exposes /app/health and /health. Can we just expose /app/health? In this way, the health check endpoint can be accessible without any confusion. It even work in multiple app environment. This will simplify the spec. @jmesnil what do you think?

[pilhuhn]

I would rather go the other way around and have /health and /health/* This way less "top level" urls are used. Also /health is sort of a standard for health check purposes. Not offering this, leads to more work for the admin running the MP server.

[kwsutter]

FYI, this issue is semi-related to Issue #35 as well. I agree that we need to provide the single /health endpoint initially and then grow it from there (/health/*).

[Emily-Jiang]

@pilhuhn I think /app/health is better as this endpoint will work in any environment. It works even in the environment with multiple app installed. If we just expose one root /health, how do we gather the health status for multiple app environment.

[heiko-braun]

@Emily-Jiang

If we just expose one root /health, how do we gather the health status for multiple app environment?

There is a conceptual mismatch between /health the way the initial authors intended it to be used and your use case of multiple applications on the same runtime.

So far we've been driving this from the assumption that a single failed health check leads to the termination of the computing node. This would tear down all applications on that runtime on that computing node. From this perspective a single /health is sufficient and a further distinction along the lines of /app/health not needed.

If you want to support runtimes with multiple applications installed this would challenge the baseline assumption behind this spec. I am not saying we cannot do this, but I want that we are all on the same page with respect to assumption and constraints of the current design.

[heiko-braun]

From @jmesnil (carried over from #29)

Having a single health endpoint is good to check the overall healthiness of a server (producer in the spec).
However it SHOULD also be possible to check the healthiness of deployments (that could be considered as components of the producer).

The spec should allow to provide further inspection through the health endpoint to check healthiness of a given component.

/health would check the global healthiness
/health/<component> would check the healthiness of the component (through its associated health check procedures).
An app server could then provide different URLS for:

• /health
• /health/<deployment name> -> queries the health check procedures of the deployment
• /health/server -> queries the health check procedures of the app server itself
• /health/server/<subsystem> -> queries the health check procedures of a subsystem of the app server

This has the advantage of keeping the deployment endpoint space clean.
We could also ensure that a call to /health optionally returns a list of links for every available subcomponents.

What do you think?

[Emily-Jiang]

Understood, Heiko. I think @jmesnil is close to what I am thinking.
global /health to aggregate the overall health.
/app/health to display each individual app health status. I don't think we should do /health/server. the /health is to display the node status. We can talk about how easily aggregate the multiple app health status and display under /health.

[heiko-braun]

@Emily-Jiang I am fine with supporting /health and /app/health as long as the following conditions are met:

• Regardless of the entrypoint, the response payload and protocol mappings (i.e. status codes) described in the companion doc remain the same
• The policies to determine the overall outcome remain the same (single failure leads to overall failure)

When this is guaranteed we can treat multiple /app/health responses as composite elements to to a higher level /health response.

[Emily-Jiang]

@heiko-braun agreed.

[heiko-braun]

Thinking further about response composition and URL namespaces, maybe we should guarantee that the composition level is reflected in the URL namespace, i.e:

/health/<x>/<y>/<z> implies that composition guidelines I've described before are applied in the order of:
z outcome determines y outcome determines x outcome determines overall outcome

This way we could provide some leeway for implementors to support composition levels best suited for their runtime. I.e @jmesnil could still do /health/server/<subsystem> if that's reasonable in his specific context, but without compromising the overall protocol consistency.

[pilhuhn]

First I think we are talking Microprofile here with an emphasis on Microservices, so I wonder if the case of one app-server hosting many apps AND running Microprofile is really common.
Second if we do /<app>/health, then it must be clear for each app (developer) that /health within the app namespace is already taken by health checks. On top of /health.

This is why I am advocating to only have one top level /health where app-specific or what ever ones go below /health as this is less polluting the URL name space.

[heiko-braun]

@pilhuhn I do agree on less top level namespaces. I think my latest proposal here reflects that:

/health/<x>/<y>/<z>

[pilhuhn]

@heiko-braun I guessed it from the subsystem example, but wanted to make my point explicit :)

[heiko-braun]

On the last call we've decided to require a single /health in 1.0, hence I am moving this discussion to the next milestone. We can revisit it later.

[dfbadawi]

Should the context be configurable?
Because health is a quite common word for resource.
And since the healthcheck is a system feature (i.e, not business feature), it would be nice if we can configure it to _health or other context.

What do you think?

[antoinesd]

@Emily-Jiang after more than 1 year what is your opinion on this ticket ?