Julien

I think this is a niche use case where we should not invent new protocols etc. I am happy with the current retries process we have, and I would not...

When implementing this it would be great to have those recording rules also able to look at the past. E.g. to calculate urates/rates.

irates

Extra note: do we want this before of after relabelling? I'd say we want this after relabelling so that we can compare with relabelled metrics from previous scrapes.

can we move this one step further and agree on a design? ``` groups: - name: example job: snmp rules: - record: ifHCInOctets:irate6m expr: irate(ifHCInOctets{ {{range $k, $v := $scrapeLabels}}{{$k}}=\"{{$v}}\",{{end}}...

honor_labels/metric_relabel_configs must be out of scope because with them you can get metrics that have no common labels. Or are we ready to limit the scope of the rules to...

That makes writing rules simpler. But how is the data about which timeserie belong to which target recorded, and persisted across restart? I guess we have that for staleness already.

We set the " job: snmp" at the group level, which implies it will run after each scrape of a target in that job

> It isn't, the promql would be adjusted to have matchers for all the target labels added to it. That is then ignoring relabeling/honor_labels ?

> We set the " job: snmp" at the group level, which implies it will run after each scrape of a target in that job Yes scrape config name, so...