Question: Does this library support metrics on the golang runtime?

[veqryn]

Hi. I have just switched from using both Prometheus and New Relic client golang libraries, to using Open Telemetry. With the Prometheus and New Relic client golang libraries, they export/publish many metrics about the golang runtime itself, all out-of-the-box. Example include basic memory stats, the number of goroutines, the number of threads, and info about garbage collection.

Does this Open Telemetry golang library do this already? And if not, is it planned to be supported?

Problem Statement

It is frustrating that no info about the golang process appears to be published/exported automatically. I also don't see anywhere to hook into this easily.

Proposed Solution

Would be nice if basic information/statistics/metrics about the golang process/runtime get published/exported automatically. Or if there was a package in this library that could be imported to do this automatically.

Prior Art

• https://github.com/prometheus/client_golang
• https://github.com/newrelic/go-agent

[Aneurysm9]

Runtime metrics are provided by instrumentation in the contrib repo. There is also a separate instrumentation for host metrics.

The metrics API and SDK are currently under heavy work in the metrics specification SIG with potentially significant changes coming to the implementations here in the Go library as this was used as an early prototype. I expect that the runtime and host metrics instrumentations will continue to exist in mostly the same form, but I doubt that the specification will lead to automatically enabling any instrumentation without the application author taking steps to do so while configuring the SDK. That said, both the runtime and host metrics instrumentations can be enabled with a single line if no options need to be specified. Call runtime.Start() and you're off to the races.

[veqryn]

Thank you. @Aneurysm9 Do the 'host' metrics work when running as a non-root user inside a container?

[Aneurysm9]

I believe it should. It is effectively a wrapper around gopsutil, which reads from /proc/stat. I'd expect that to work from a process in a cgroup, filtered to the appropriate namespace.