Remember previously seen list keys by pattern

[roobre]

Describe the problem

Simliar to #472, I think there is a use case in making the length/size of certain keys "sticky". Unlike in the issue reported above however, I'm facing this problem on a system where the keys I'm interested in keeping are somewhat predictable (i.e. have a prefix), but are not entirely deterministic.

I think it would be great if we could supply a glob pattern of keys that the exporter should remember, something like -remember-keys. The exporter could store the name of keys matching this glob in memory, and fill their value with zero if they are not found in the next scrape.

Implementation-wise, it should not be very intrusive, as it should only be a matter of 1) appending the list of previously-seen metrics here, and adding metrics to the previously-seen list on scrape.

I can work on a PR for this feature if you think is something valuable to have.

What version of redis_exporter are you running? Please run redis_exporter --version if you're not sure what version you're running. [ ] 0.3x.x [x] 1.x.x

Additional context

To elaborate a bit on the use case in case it helps: I'm using a small number of redis lists as queues for different jobs that need to be processed. The keys for these lists all fall under the same pattern (e.g. requests-), but their names depend on some configuration: There might be different queues for different environments and/or priorities (requests-dev-low, requests-prod-low, requests-prod-high, etc.). While it is possible to feed all those in -check-single-keys, this creates two sources of truth for a potentially alert-able metric, which would be great if it could be avoided.

[oliver006]

I don't think introducing "state" is a good idea for the exporter (or prom metrics collection in general). IMO if your metrics aren't deterministic then that's something to figure out first. Plus keeping state will work poorly with how scraping multiple targets with one exporter is being done right now (e.g. a new Exporter is created and then tossed for each target).

I agree that two sources of truth for the configs are a bad thing. But I think the more prometheus-ish way to handle this is to treat "null" values as zeros (or whatever default value makes sense) instead of generating artificial all-zero timeseries.

[roobre]

I don't think introducing "state" is a good idea for the exporter

I think that's a fair point.

In my case, metrics are deterministic, but derived from configuration, which is a bit unfortunate :(

I'll check if there's a way to make prometheus fill the null with zeroes while keeping the labels, which I couldn't figure out last time 👍🏻