Thanks! Filed https://github.com/prometheus/client_golang/issues/842.
On Saturday, March 6, 2021 at 7:20:25 AM UTC-5 [email protected] wrote: > This sounds awesome to me. I'm glad to see some Prometheus love from the > Go team. > > If you would please file an issue on the client_golang project, with some > more details on the specific changes you want to make, that would be > perfect. > > Looking forward to seeing this added. > > On Sat, Mar 6, 2021 at 12:37 AM 'Michael Knyszek' via Prometheus > Developers <[email protected]> wrote: > >> Hey Prometheus devs, >> >> My name is Michael and I work on the Go runtime at Google. >> >> I wanted to send out a message to the mailing list regarding my intent to >> add support for reading metrics exported by the runtime/metrics package >> <https://golang.org/pkg/runtime/metrics/> in the Go client >> <https://github.com/prometheus/client_golang>. The goal of this new >> package is to allow the runtime to export implementation-specific metrics. >> This is useful both for users to gain greater insight into their >> application's behavior, and for the Go team in understanding performance >> issues, bugs, and places where we can improve. The core API works a lot >> like ReadMemStats, but the set of metrics available is significantly more >> dynamic. >> >> I took a look at the codebase, and AFAICT this switch should be >> relatively straightforward, and pretty much just amounts to providing a >> second goCollector >> <https://github.com/prometheus/client_golang/blob/master/prometheus/go_collector.go> >> that's >> used for Go 1.16+. I decided to send a message out to the mailing list >> because this involves a little bit of refactoring and a medium amount of >> code, and I didn't want to just show up with a big ol' PR. Does this plan >> of action sound reasonable to y'all? >> >> I figure a second goCollector should be OK, because the new one will >> generally be simpler than the existing one. For instance, a lot of the >> hand-coded data about what each metric means is now available at runtime, >> like metric descriptions. Metric names can also be programmatically >> generated, because the runtime/metrics keys are already namespaced. >> Furthermore, the runtime/metrics package's Read method does not >> stop-the-world, so all the logic that's working around ReadMemStats' high >> latency can pretty much disappear in the new goCollector. I figure it will >> still be worthwhile to re-export some of the metrics under their old names >> too to avoid breaking dashboards, but I don't know how much of a concern >> that is here. >> >> Anyway, please let me know what you think! >> >> Thank you, >> Michael >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/14eb46d5-5bae-4823-afba-c8aeac32c504n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/prometheus-developers/14eb46d5-5bae-4823-afba-c8aeac32c504n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/18deaa31-bac1-4a20-93f4-d13559563908n%40googlegroups.com.
