Prometheus exporter implies it will run a server, but doesn't

[Sushisource]

The prom exporter options imply it will run a server. After all, it exposes options to configure a port, host, etc: https://docs.rs/opentelemetry-prometheus/0.9.0/opentelemetry_prometheus/struct.ExporterBuilder.html#method.with_port

It doesn't do that, though, which is deeply confusing combined with the lack of top-level documentation. It makes sense why it doesn't run a server. You'd need to pull in a bunch of deps to do so.

But... it also doesn't really make much sense at all to configure a host or a port for something that isn't going to run a server anyway.

https://github.com/open-telemetry/opentelemetry-rust/blob/main/examples/hyper-prometheus/src/main.rs sheds some light on how it's meant to be used (and at minimum should be referenced from the crate docs for the prometheus exporter) -- but even the example demonstrates the disconnect between the exporter having host/port options, and actually running a server. The most reasonable thing you could expect to happen here is the hyper example would use the host() and port() methods when binding, but it just chooses it's own thing.

I'd suggest two things:

1. Add some top level docs to the prometheus exporter crate describing how it's used
2. Don't even bother having host/port options on the exporter. Ultimately they're the job of some other abstraction that makes use of the exporter.

I'm happy to make a PR to contribute these fixes

[TommyCpp]

The spec provides two env vars https://github.com/open-telemetry/opentelemetry-specification/pull/1021 to allow users to specify the port and host. We intended to save the value of the host and port into exporter so that users can use those later.

Docs updates are always welcome. Feel free to open a PR

[realtimetodie]

@Sushisource Why should an exporter even run a server? An exporter is primarily a client.

[morigs]

@diceride there are two types of exporters: push-based and pull-based. Push-based use a client to send data, and pull-based use a server to expose data. Prometheus normally is pull-based, thus it should start the server to expose metrics in prometheus format. Actually, opentelemetry-go and opentelemetry-js start server for Prometheus exporter. I believe opentelemetry-rust should do this too.

[Flowneee]

Actually, opentelemetry-go and opentelemetry-js start server for Prometheus exporter. I believe opentelemetry-rust should do this too.

@morigs But this would be very inconvenient if your application is already a HTTP server. Should prometheus exporter run on different port? Or should I somehow merge them?

I believe proper solution would be making such server a separate crate and optionally re-importing it from opentelemetry-prometheus.

[morigs]

@Flowneee spec explicitly specifies which port prometheus exporter should listen on. So opentelemetry-js creates a separate server for this. But the exporter itself is in the separate package.

[cdesch]

Does the current default Prometheus exporter push currently, given the host and port as the destination?

[jtescher]

This config has now been removed