Updating client_golang to use the new runtime/metrics package

120 views
Skip to first unread message

Michael Knyszek

unread,
Mar 5, 2021, 6:36:58 PM3/5/21
to Prometheus Developers
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 in the Go client. 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 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


Julien Pivotto

unread,
Mar 6, 2021, 3:13:18 AM3/6/21
to Michael Knyszek, Prometheus Developers
That sounds great, given that we maintain compatibility with old go releases using build tags.

I would keep the old metric names for a while, but do you already have an overview of the 'gap' between the two?

--
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 prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/14eb46d5-5bae-4823-afba-c8aeac32c504n%40googlegroups.com.

Ben Kochie

unread,
Mar 6, 2021, 7:20:25 AM3/6/21
to Michael Knyszek, Prometheus Developers
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.

Michael Knyszek

unread,
Mar 8, 2021, 12:27:20 PM3/8/21
to Prometheus Developers
Reply all
Reply to author
Forward
0 new messages