Introduce configurable management endpoint prefix

[mkouba]

Based on the Avoid polluting the URI namespace with Quarkus endpoints thread.

The prefix should be /quarkus by default.

All extensions that expose non-app endpoints should use this prefix: /quarkus/health, /quarkus/open-api, etc.

[rsvoboda]

I'm not sure it's a good idea.
Many tools expect path at root.

E.g. https://prometheus.io/docs/introduction/first_steps/ :
Prometheus expects metrics to be available on targets on a path of /metrics. So this default job is scraping via the URL: http://localhost:9090/metrics.

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#static_config … just host and port can be specified
https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config … metrics_path can be specified, but it’s global setting so all services must expose data on the same path

MP users are used to standard path at root, they can have tooling around those endpoints.

[kenfinnigan]

While there are certainly tools that expect certain endpoints at root, they can also be configured to use different paths.

Whatever is done here needs to be configurable such that a user can choose whether endpoints go under /quarkus or root. But by default we should have everything under /quarkus

[rsvoboda]

+1 to have configuration option for MP-related and (eventually) Quarkus-specific endpoints at root

/quarkus could help users by listing available endpoints, sort of index page

[XciD]

Could we have another port for internal resource ? like metrics or health ?

So we could use it for local parse (like kubernetes probes or pronmetheus scrape) and just expose the user resources with another port ?

[kenfinnigan]

I think it makes for "management endpoints" to have a configurable path and port.

[ebullient]

Spring Boot 2 also scopes endpoints, placing them under an /actuator/... context root (which is a +1 for @rsvoboda comments above). For some of the sample apps that I make, I provide a simple (easily replaced) index.html file listing provided endpoints for exactly that reason..

I don't know how common it is to separate health/prometheus endpoints on different ports. Yes, it could be configurable, but I don't think it is very common in practice.

With Kubernetes, Prometheus endpoints are discovered dynamically, which removes the static/global configuration worry: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config

(sorry, stumbled on this really old issue from conversation in Zulip..)

[geoand]

Should this now be closed with the advent of /q?

[kenfinnigan]

I believe it can yeah