search

prometheus / client_golang

Prometheus instrumentation library for Go applications
https://pkg.go.dev/github.com/prometheus/client_golang
Apache License 2.0
5.33k stars 1.17k forks source link

processcollector: Add support for Darwin platform. #1590

Open bwplotka opened 3 weeks ago

bwplotka commented 3 weeks ago

Not a high priority but we could implement metrics for MacOS e.g. using sysctl. Currently we error out (silently by default).

mharbison72 commented 2 weeks ago

https://github.com/prometheus/client_golang/pull/1600 handles most of this, but I didn't add (fixes #1590) to the commit because it would be really nice to get the memory stats too. I'd need to know what's allowable though (3rd party deps, cgo, undocumented APIs), before sinking a lot more time into it though.

bwplotka commented 1 week ago

Yea, ideally none of those 3rd party deps, cgo. Undocumented API might work.

There is always option for others (or us) to create a separate module for darwin statistics/collector. Here we aim for something standard, good enough for majority of users. Thanks!

mharbison72 commented 1 week ago

Yea, ideally none of those 3rd party deps, cgo. Undocumented API might work.

There is always option for others (or us) to create a separate module for darwin statistics/collector. Here we aim for something standard, good enough for majority of users. Thanks!

Can you describe this in a little more please? I think I'm missing something here. (If there's a better forum for a wider discussion, we can move it there). To be clear when I said "undocumented API", I meant from Apple, not something in Go.

I think the fundamental problem here is that there's no built-in mechanism in Go to call into random system libraries like there is on Windows (AFAICT), and they've been resistant to adding that support[1][2]. Given that restriction, we can't access the (undocumented) Apple APIs for getting this info without either cgo or a 3rd party mechanism. (Maybe the noncgo module referenced in the second link is another 3rd party option. It's small and public domain, but well beyond my understanding of Go, so I wouldn't want to try to replicate it.)

Placing this code in another module would just seem to shift the problem, and create additional problems in that process_virtual_memory_bytes and process_resident_memory_bytes could come from one module on some platforms, and a second on darwin. (I think I saw a recent issue mention that the Describe method isn't per-platform, so I think that would have to be fixed up first to do this.)

I don't care too much about the network transfer counters, but the memory usage ones helped me find a memory leak on Windows, so those are worth jumping through some hoops IMHO. I think there are build tags to detect if cgo is enabled, so maybe it can be done in cgo, with a corresponding Go function that causes the metric(s) to not be emitted when cgo is not enabled? Not as nice as just working everywhere, but it would still allow me to cross compile for local builds if I don't care about those metrics at the time.

[1] https://github.com/golang/go/issues/18296 [2] https://groups.google.com/g/golang-nuts/c/Wt6P0BYndvs/m/Uh7WkMRaAQAJ