prometheus-community
Support host prefix for apt_info.py
This will allow us to run apt_info.py on the host from the container.
docker run --rm -it --entrypoint bash -v "/:/hostfs" ubuntu:22.04 -c 'apt update && apt install -y python3-prometheus-client python3-apt curl && curl https://raw.githubusercontent.com/prometheus-community/node-exporter-textfile-collector-scripts/7aaf51790bf19911ebcaa49f6474b26bd04b3910/apt_info.py -o /tmp/apt_info.py && APT_HOSTPREFIX=/hostfs/ python3 /tmp/apt_info.py'
@dswarbrick Why? python3-prometheus-client python3-apt dependencies are installed only in the container
What advantage does running this script in Docker actually bring you? It seems like an unnecessarily complicated setup.
Assuming it's a Debian or Ubuntu host, these scripts are packaged as prometheus-node-exporter-collectors - complete with systemd service to run it periodically.
Ok, I will try a different approach... There are people ( https://unix.stackexchange.com/questions/261165/change-cache-location-path-for-apt ) having apt dir elsewhere than in the default path, this PR will allow supporting different apt-cache paths.
I can understand the motivation to support a non-standard apt cache location, and would accept that being implemented via a command-line option.
I still don't understand your motivation to run this script in a container, considering the hoops that you have to jump through in order to make it work. It is designed to operate on the host's apt cache, and can run as an unprivileged user. Why do you feel the need to sandbox it in a container?
If you are really determined to run this script in a container, maybe mapping the host's entire rootfs to /hostfs is not the right way to go about it (and also IMHO defeats the purpose of running in a container). Maybe consider instead mapping the handful of paths required by the script (e.g. /run, /var/cache/apt) to their normal locations within the container.
I would also like to see this feature implemented.
I'm running my node exporter via Kube Prometheus Stack directly inside Kubernetes. Including all other monitoring related stuff. So my nodes already have the the root file system mounted to other node exporter containers.
Therefore I don't want to do a two-pronged approach and install this script directly on the node.
I can understand the motivation to support a non-standard apt cache location, and would accept that being implemented via a command-line option.
@dswarbrick
I've implemented this via command-line option: #178
@lukasmrtvy I've created an exporter using my changes of the PR #178.
But also using an environment variable to pass it to the script.
My exporter (https://github.com/egvimo/apt-exporter) runs inside a Kubernetes cluster as a DaemonSet using the Prometheus ServiceMonitor to collect the metrics.
