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/CABbyFmodP7qz9kZuM2xPPsLEzPpAZxk4hZuypT7O1xfSnQbaMQ%40mail.gmail.com.
