Thoughts about storing unit/job statistics

[Philip Withnall <philip@xxxxxxxxxxxxxxx>]

Hello all,

As part of work on a GNOME feature for monitoring how often the user
uses applications (for example, to let them know that they spent 4
hours in the Slack app, or 17 hours playing games), I’m trying to work
out the best way to store data like that.

If we assume the system is using systemd user sessions, then an
application being run is actually a unit being started, and so the data
we want to store is actually the duration of each unit run.

A related issue is that of storing network usage data per unit, to
allow the user to see which apps have been using the most data over the
last (say) month.

If I were to implement this as a separate daemon, it would need to be
active all the time, listening to UnitNew/UnitRemoved/JobNew/JobRemoved
signals from systemd. That seems like a waste of a process. Let’s call
this problem 0.

One approach would be to store this data in the journal, but (problems
1-3):
 1. We can’t control how long the journal data is around for, or even
if it’s set to persist.
 2. This data couldn’t be stored separately (for example, in a separate
journal file) so that the user could delete it all together and
separately from the rest of the journal. (To reset their usage data.)
 3. Querying it from the journal would mean filtering and iterating
through everything else in the journal, which is not going to be the
fastest (although it probably wouldn’t be too bad, and we would be
appending a lot more often than we would be querying).

So I have two questions:
 1. Does this seem like the kind of functionality which should go into
the journal, if it was modified to address problems 1-3 above?
 1a. If not, do you have any suggestions for how to implement it so
that problem 0 above is not an issue, i.e. we don’t have to keep a
daemon running all the time just to record a small chunk of data once
every few minutes?
 2. Does this seem like a subset of a larger bit of functionality,
storing metrics about units and jobs for later analysis, which might be
interesting to non-desktop users of systemd?

Thanks,
Philip

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel