open-telemetry
Don't force reliance on Prometheus HTTP Server
👋🏼 https://github.com/open-telemetry/opentelemetry-java/pull/4185 As it seems there's a desire for feedback on this. My first inclination is that mandating a particular HTTP server is restrictive. By limiting consumption of the MetricReader to the Prometheus Collector anyone using alternative HTTP Frameworks can easily keep their applications integrated. This is actually my usecase 😓
Originally posted by @hdost in https://github.com/open-telemetry/opentelemetry-java/discussions/4235#discussioncomment-2297369
Hi @hdost - sorry for missing this issue from so many months ago. While the built-in server is meant to be easy to get going, I agree that being able to use a different HTTP framework is good, and is what I'd do in my apps too. We'd probably want to add a byte[] serialize type of method instead of encoding into a collector for that use case, which allows using our optimized serialization code. Would that satisfy your use case?
@anuraaga I guess that depends, I would need to think a bit more as potentially there might be selectors which could be useful. Especially as there may be potential want/need in the future to export in Protobuf Prometheus Format for Sparse Histograms
Thanks for the context @hdost - my understanding was that OTel settled on the text protocol for Prometheus via the push there in OpenMetrics. If there is community consensus for supporting protobuf as well, then we would definitely need to add support for marshaling it here too.
@anuraaga Going back to this. I am trying to think more about how we could utilize the serializer. Would it make sense to make the serializer public? Perhaps we could do a contrib instead that's just Serializer exporter.
@anuraaga I've hit this issue as well where actually having the PrometheusCollector would be a much more flexible choice compared to the PrometheusHttpServer.
In my use case I'm replacing dropwizard with opentelemetry. To keep both running on the same prometheus server, we basically need the PrometheusCollector to use it with the prometheus java client.
After talking internally I could also be desirable to make it more compatible with explicit parameter by being able to pass in a registry
Take a look at opentelemetry-java-contrib#660, which adds PrometheusCollector as a published component in opentelemetry-java-contrib. It could use another maintainer if @hdost or @nicu-da are interested.
I'm going to close this now that opentelemetry-java-contrib#660 is merged. If that is still insufficient, we can reopen this issue to discuss options for adding a byte[] serialize method to allow use with other HTTP servers.