search

prometheus-community / node-exporter-textfile-collector-scripts

Scripts for node-exporter's textfile collector
Apache License 2.0
488 stars 185 forks source link

report the apt cache timestamp #182

Closed anarcat closed 11 months ago

anarcat commented 11 months ago

We use the pkgcache.bin modification time as a heuristic, but there might be a better way to do this.

We also silently ignore errors when pulling that file to avoid broken systems from breaking the other metrics. I believe this will lead to a null metric which is probably what we want anyway.

A possible improvement to this would be to individually inspect the InRelease files and report the mirror's timestamps as well, but that's more involved. It's also not a priority compared to this fix, because we want the update timestamp if we remove the apt update run (in #181).

Closes: #180

anarcat commented 11 months ago

merged your suggestion in the commit, along with a credit in commitlog, should be ready to merge now.

julian-klode commented 10 months ago

This has all a bit too fast for me to actually give any feedback (I'm afk all week except this morning more or less), but pkgcache.bin will also get updated whenever you install or upgrade or remove a package. srcpkgcache.bin is rebuilt whenever the sources.list changes, you ran clean, or the lists actually changed.

The best approach arguably is to check /var/lib/apt/periodic/update-success-stamp to see when the last succesful update was - but it is only set by the periodic script, so that only makes sense if the option is set (querying that with apt_pkg.init_config(); apt_pkg.config["APT::Periodic::Update-Package-Lists"] is nicest if you want to use python3-apt, but could do apt-config get too).

The best proxy otherwise is just the mtime of the /var/lib/apt/lists directory as we always rename() files from the partial directory into there, so it should always be updated as far as I understand directory modification times. The modification times of the files meanwhile are the modification times on the server and hence not meaningful.

This is a common issue that other tools also have and APT itself will need to deal with, I think we're going to end up adding actual stamp files to the apt code itself so you can always tell when the last update was and whether there were errors. Maybe just dump a (machine-readable) update.log in there, once we have machine-readable error codes.

anarcat commented 10 months ago

great feedback @julian-klode - i've opened #183 to tweak this properly.