Julien

``` groups: - name: example target_labels: - job: [snmp] - zone: [dmz,internet] rules: - record: ifHCInOctets:irate6m expr: irate(ifHCInOctets[6m]) ```

Without a limitation also on job_name, there would be a penalty on every scrape

Okay so, we would scan the targets when they are created/changed/deleted and also when rules are created/changed/deleted.

Proposed design, after this discussion: ``` groups: - name: example target_labels: - job: [snmp] - zone: [dmz,internet] target_labels_re: - instance: ["nexus.*"] rules: - record: ifHCInOctets:irate6m expr: irate(ifHCInOctets[6m]) ``` - groups'...

so .. ``` target_labels: '{foo="bar",job=~"node|snmp"} ``` The reasoning about having at least one metric is to be sure that the scope of the recording rule can be limited. But indeed...

ping @free #1227 might solve this

Hello, Per dev summit, I'd like to note that we are willing to rethink this and collect all the data regarding rate and xrate: https://docs.google.com/document/d/1vhXKpCNY0k2cbm0g10uM2msXoMoH8CTwrg_dyqsFUKo Based on the data we...

Grafana has introduced over time a new feature: https://grafana.com/blog/2020/09/28/new-in-grafana-7.2-__rate_interval-for-prometheus-rate-queries-that-just-work/ Did you try this out?

For anyone looking at this, there are extensive discussions here too: https://github.com/prometheus/prometheus/pull/1245

Hello, the design doc is being discussed now: https://docs.google.com/document/d/1y2Mp041_2v0blnKnZk7keCnJZICeK2YWUQuXH_m4DVc/edit