Microprofile /health endpoint does not distinguish by application in the health endpoint url

[dbnex14]

In Spring, the /health end point is separated by application. So if I have 10 applications on same server, I can access /health, /metrics etc endpoints for each application separately like:

http://myServer/app1/acutator/health
http://myServer/app2/acutator/health
http://myServer/app3/acutator/health
...
http://myServer/app10/acutator/health

This is great since I know exactly for which application I cam checking health status for.

However, in Microprofile, there seem to be no such distinction and there is only a generic /health endpoint like:

http://myserver/health

, and that reports:

{"checks":[],"status":"UP"}

So, it does not tell me for which application is status up or down.

[xstefank]

Unfortunately, this is explicitly not defined as we need an overall strategy for the MicroProfile as whole (as you pointed, same scenario for /health, /metrics, /openapi). So the specification explicitly says:

The current version of the MicroProfile Health specification does not define how the defined endpoints may be partitioned in the event that the MicroProfile runtime supports deployment of multiple applications. If an implementation wishes to support multiple applications within a MicroProfile runtime, the semantics of individual endpoints are expected to be the logical AND of all the application in the runtime. The exact details of this are deferred to a future version of the MicroProfile Health specification.
in https://download.eclipse.org/microprofile/microprofile-health-3.1/microprofile-health-spec-3.1.html#_rationale. The MicroProfile strategy so far is to support only one application per server as it is intended in the microservices architecture.

More information can be found in eclipse/microprofile#168.

[dbnex14]

Unfortunately, this is explicitly not defined as we need an overall strategy for the MicroProfile as whole (as you pointed, same scenario for /health, /metrics, /openapi).

Exactly, it should be provided for all endpoints, not only /health. I am using only health here as an example. Yes, it is about Microprofile in general, not just /health endpoint as Spring did it by providing actuator endpoint by-the-application.
It is a smell and sign of a design flaw assuming everyone will go microservices one day.

So the specification explicitly says:

The current version of the MicroProfile Health specification does not define how the defined endpoints may be partitioned in the event that the MicroProfile runtime supports deployment of multiple applications. If an implementation wishes to support multiple applications within a MicroProfile runtime, the semantics of individual endpoints are expected to be the logical AND of all the application in the runtime. The exact details of this are deferred to a future version of the MicroProfile Health specification. in https://download.eclipse.org/microprofile/microprofile-health-3.1/microprofile-health-spec-3.1.html#_rationale. The MicroProfile strategy so far is to support only one application per server as it is intended in the microservices architecture.

More information can be found in eclipse/microprofile#168.