You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by emschwartz March 7, 2023
Should autometrics libraries automatically or optionally start a server that exports metrics on a default port + path?
Prometheus and OpenTelemetry libraries in different languages seem to have a mixed view on this. Some expect you to add the listener yourself while others do it automatically.
Standardizing this across languages would help reduce the configuration needed for any additional tooling we build around autometrics. For example, we could ship a default Prometheus config and/or config files for hosted Prometheus services like Fly.io's.
That said, we might want to make this optional (though not sure if it's opt-in or opt-out). I personally find it surprising that a library I import would open an listener on a port without my explicitly telling it to.
Unfortunately, if we do this, this is another place where OpenTelemetry, OpenMetrics, and Prometheus diverge 🤦.
Discussed in https://github.com/orgs/autometrics-dev/discussions/7
Originally posted by emschwartz March 7, 2023
Should autometrics libraries automatically or optionally start a server that exports metrics on a default port + path?
Prometheus and OpenTelemetry libraries in different languages seem to have a mixed view on this. Some expect you to add the listener yourself while others do it automatically.
Standardizing this across languages would help reduce the configuration needed for any additional tooling we build around autometrics. For example, we could ship a default Prometheus config and/or config files for hosted Prometheus services like Fly.io's.
That said, we might want to make this optional (though not sure if it's opt-in or opt-out). I personally find it surprising that a library I import would open an listener on a port without my explicitly telling it to.
Unfortunately, if we do this, this is another place where OpenTelemetry, OpenMetrics, and Prometheus diverge 🤦.
The text was updated successfully, but these errors were encountered: