Bug#1010762: ITP: prometheus-systemd-exporter -- Prometheus Exporter for systemd unit metrics

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debi...@lists.debian.org

* Package name : prometheus-systemd-exporter
Version : 0.4.0
Upstream Author : Povilas Versockas <https://github.com/povilasv>
* URL : https://github.com/povilasv/systemd_exporter
* License : Apache-2.0
Programming Lang: Golang
Description : Prometheus Exporter for systemd unit metrics

Prometheus exporter for systemd units, written in Go.

Systemd groups processes, threads, and other resources (PIDs, memory,
etc) into logical containers called units. Systemd-exporter will read
the 11 different types of systemd units (e.g. service, slice, etc) and
give you metrics about the health and resource consumption of each
unit. This allows an application specific view of your system,
allowing you to determine resource usage of an application such as
mysql.service independently from the resources used by other processes
on your system.

----

This overlaps with the already packaged prometheus-node-exporter, but
the node exporter doesn't export per-unit statistics. You can get
global memory usage, but not per application memory usage, for
example. The is *some* overlap with the node exporter because they
both export *some* per unit stats (namely the number of restarts, for
example).

The upstream README also compares this with the
prometheus-process-exporter (also packaged). The process exporter
targets processes, not unit, and needs to be configured to target
specific processes, by name, which is somewhat error-prone.

This could be packaged under the golang team, I suppose.

[Antoine Beaupré]

I tweaked the dh-golang output a little and dumped the result here:

https://salsa.debian.org/go-team/packages/systemd-exporter/

I'm stuck on this error:

dh binary --builddirectory=_build --buildsystem=golang --with=golang
debian/rules binary
dh_update_autotools_config -O--builddirectory=_build -O--buildsystem=golang
dh_autoreconf -O--builddirectory=_build -O--buildsystem=golang
dh_auto_configure -O--builddirectory=_build -O--buildsystem=golang
dh_auto_build -O--builddirectory=_build -O--buildsystem=golang
cd _build && go install -trimpath -v -p 2 github.com/povilasv/systemd_exporter github.com/povilasv/systemd_exporter/systemd
src/github.com/povilasv/systemd_exporter/main.go:7:2: cannot find package "github.com/povilasv/prommod" in any of:
/usr/lib/go-1.18/src/github.com/povilasv/prommod (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/github.com/povilasv/prommod (from $GOPATH)
src/github.com/povilasv/systemd_exporter/systemd/cgroups.go:14:2: cannot find package "github.com/prometheus/common/log" in any of:
/usr/lib/go-1.18/src/github.com/prometheus/common/log (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/github.com/prometheus/common/log (from $GOPATH)
dh_auto_build: error: cd _build && go install -trimpath -v -p 2 github.com/povilasv/systemd_exporter github.com/povilasv/systemd_exporter/systemd returned exit code 1
make: *** [debian/rules:4: binary] Error 25

The first one, I understand, it's a dep that's missing. I am wondering
if I can just vendor that in, because it's just some shim code that's
unlikely to be used by other modules.

The latter I'm confused about. That module is correctly shipped by
golang-github-prometheus-common-dev so it should just work correctly...

Anything I'm missing here?

--
How inappropriate to call this planet 'Earth' when it is quite clearly
'Ocean'.
- Arthur C. Clarke

[Antoine Beaupré]

Control: retitle -1 "RFP: prometheus-systemd-exporter -- Prometheus Exporter for systemd unit metrics"
Control: done -1

I gave up on this project. I was hoping this would provide a per-cgroup
memory view of my system, but it failed at that:

https://github.com/povilasv/systemd_exporter/issues/46

... and quite badly. It turns out it doesn't actually use cgroups (or
systemd, for that matter) for all stats, but only for some. memory, in
particular, it only checks for the "main PID" which fails miserably with
things like cron or apache or postgresql, making it useless for my use
case.

The fact that it has that extra dependency is also annoying enough that
I don't want to go through the work of packaging this just for fun
either.

I'll probably use the process exporter which, starting in bookworm, will
have support for "cgroups" grouping. It doesn't work in older kernels
(ie. bullseye), so I can't quite have exactly what i need now, but it
*does* group processes by name, which is really good enough for now.

a.
--
Sous le projecteur, on ne voit pas les autres.
- Félix Leclerc