processcollector: Add support for Darwin platform.

[bwplotka]

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

[mharbison72]

#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]

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]

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] golang/go#18296
[2] https://groups.google.com/g/golang-nuts/c/Wt6P0BYndvs/m/Uh7WkMRaAQAJ