Should MP Telemetry require implementations to have a /metrics endpoint?

[donbourne]

We need to decide if we will require MP Telemetry compatible implementations to include a /metrics endpoint that responds with Prometheus/OpenMetrics format metrics data.

A /metrics endpoint could be used by operations teams that want an easy to set up way to collect metrics from a server that doesn't require an OpenTelemetry Collector. It could also be useful for demos where simplicity of setup is important.

OpenTelemetry provides a Prometheus Metrics Exporter (https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/prometheus/) which is a pull metric exporter. While the Prometheus Metrics Exporter is handy for testing, it may not be appropriate, IMO, for MP servers/runtimes that have their own pattern for endpoint and security configuration (eg. how to configure port to use, TLS configuration, RBAC).

Please post your comments with your opinion on whether it is important for MP Telemetry to require implementations to have a /metrics endpoint?

[pdudits]

Prometheus support does seem like a useful feature, especially when migrating away from MP Metrics. I also agree that SDK provided Prometheus implementation does not fit many runtimes.

If the spec would require prometheus support, then it should define another exporter name for it, such as mp.prometheus where the expectation would be that it will make the /metrics endpoint available at runtime's standard HTTP port, just like with MP Metrics.