Max Inden
Max Inden
> I was wondering if the latest version of yamux could fix that in the PR https://github.com/libp2p/rust-libp2p/pull/3013 Mind testing the pull request on the deployment where you see the errors?
> Very interested in this work Thanks for the interest. Sorry for the silence. I rebased this pull request on https://github.com/prometheus/client_rust/pull/105. I want to try out the new API with...
Tested this patch with `rust-libp2p` and `kademlia-exporter`. While the `Collector` trait is still quite verbose (with `Cow` and `MaybeOwned`), it does function as expected and allows ad-hoc cheap metric generation....
I am closing here. The goal of this pull request has been achieved through #105 and released as an alpha via https://github.com/prometheus/client_rust/pull/116. Thanks for the input everyone. Would appreciate folks...
I am sorry for the trouble @nox. I decided to follow the OpenMetrics specification. In the long run I hope for the ecosystem (e.g. your dashboards) to converge on that...
With https://github.com/prometheus/client_rust/pull/105 merged and released, this is resolved.
Referencing https://github.com/nox/prometools/blob/main/src/histogram.rs by @nox here. Again, I am in favor of supporting this natively.
With https://github.com/prometheus/client_rust/pull/105 I don't think we should proceed here, i.e. I don't see the value of replacing the new traits. @nox I am closing here for now. Please comment here...
Resolved with https://github.com/prometheus/client_rust/pull/98.
I don't think "never" is correct. One use-case I can come up with is exposing ones listening address as an info metric. See e.g. https://github.com/kubernetes/kube-state-metrics/issues/498 as an example on how...