Discussion: Further output options

I already talked with @matthiasbeyer about it; I think having other output options than files would be a good idea. I'm especially looking at time series databases, and even more specificalle, InfluxDB. Depending of how much flexibility should be left to the user, it might need to be possible to configure several outputs, similar to the items:

[[output]]
type = "influxdb"
host = "127.0.0.1"
port = "8086"
credential.db = "antikoerper"
credential.user = "ak"
credential.pw = "sdkfjsadlfkjsadlfkja"

[[output]]
type = "file"
path = "/var/log/antikoerper"

However, offering other outputs, and, more importantly databases which might only understand numeric output, the current "get the output and throw it into the file" way of doing it is no longer enough. For this, the output must be somewhat digested, so only the numbers remain.
One way to digest output, which the program (antikoerper) cannot possibly know what it will look like, is to let the user provide a regular expression to be used on the output. I've already made some experiences doing something like this by writing aklog-server.
Here how I think it could look like configuration-wise:

[[items]]
key = "load"
type = "file"
path = "/proc/loadavg"
digest_regex = "(?P<load1m>\\d+\\.\\d\\d)\\s(?P<load5m>\\d+\\.\\d\\d)\\s(?P<load15m>\\d+\\.\\d\\d).*"

Note: afaik, the double \ are necessary because they are eaten up when the toml is parsed. Every named match is expected to be a number. Regex's are not always perfect, and output may be faulty, so a not matching regex should be given to the user as a warning or at max an error. digest_regex may be kept optional; if it's missing, the raw output may be considered ok (e.g. the contents of /sys/.../thermal_zone*/temp)

After the data is extracted, it needs to be forwarded to the backend and/or written to a file; Doing an abstraction over the output (with a trait?) will most likely be necessary.

anti-koerper / antikoerper

Discussion: Further output options #34