cloudflare/pint
Publicmirrored from https://github.com/cloudflare/pintAvailable
docs/checks/group/interval.md
89lines · modecode
| 1 | --- |
| 2 | layout: default |
| 3 | parent: Checks |
| 4 | grand_parent: Documentation |
| 5 | --- |
| 6 | |
| 7 | # group/interval |
| 8 | |
| 9 | This check will warn when a rule group declares an `interval` value greater |
| 10 | than 5 minutes. |
| 11 | |
| 12 | Prometheus evaluates rules based on the group `interval` and each evaluation |
| 13 | becomes a sample for the resulting time series of a recording rule or a |
| 14 | potential alert state change for an alerting rule. |
| 15 | |
| 16 | If you set the group `interval` to a value greater than 5 minutes you will |
| 17 | end up with gaps in the recording rule results when querying them, because |
| 18 | Prometheus defaults to a 5 minute query lookback. See the |
| 19 | [staleness](https://prometheus.io/docs/prometheus/latest/querying/basics/#staleness) |
| 20 | section of the Prometheus documentation for details. |
| 21 | |
| 22 | Any sample older than 5 minutes is considered stale and won't be returned by |
| 23 | instant queries, so a recording rule that only produces a sample every |
| 24 | 10 minutes will appear to be missing for half of that time when queried. |
| 25 | |
| 26 | For alerting rules, a long interval will also cause flapping alerts, because |
| 27 | the alert state is only re-evaluated every `interval`. Between evaluations |
| 28 | the alert can resolve and then fire again on the next tick, unless you also |
| 29 | set `keep_firing_for` to a value greater than or equal to the group |
| 30 | `interval`. |
| 31 | |
| 32 | Example rule group that will trigger this check: |
| 33 | |
| 34 | ```yaml |
| 35 | groups: |
| 36 | - name: example |
| 37 | interval: 10m |
| 38 | rules: |
| 39 | - record: job:up:sum |
| 40 | expr: sum(up) by(job) |
| 41 | ``` |
| 42 | |
| 43 | To fix this problem, either lower the `interval` to `5m` or less, or, for |
| 44 | alerting rules, set `keep_firing_for` to a value greater than or equal to |
| 45 | the group `interval`. |
| 46 | |
| 47 | ## Configuration |
| 48 | |
| 49 | This check doesn't have any configuration options. |
| 50 | |
| 51 | ## How to enable it |
| 52 | |
| 53 | This check is enabled by default. |
| 54 | |
| 55 | ## How to disable it |
| 56 | |
| 57 | You can disable this check globally by adding this config block: |
| 58 | |
| 59 | ```js |
| 60 | checks { |
| 61 | disabled = ["group/interval"] |
| 62 | } |
| 63 | ``` |
| 64 | |
| 65 | You can also disable it for all rules inside given file by adding |
| 66 | a comment anywhere in that file. Example: |
| 67 | |
| 68 | ```yaml |
| 69 | # pint file/disable group/interval |
| 70 | ``` |
| 71 | |
| 72 | Or you can disable it per rule by adding a comment to it. Example: |
| 73 | |
| 74 | ```yaml |
| 75 | # pint disable group/interval |
| 76 | ``` |
| 77 | |
| 78 | ## How to snooze it |
| 79 | |
| 80 | You can disable this check until given time by adding a comment to it. Example: |
| 81 | |
| 82 | ```yaml |
| 83 | # pint snooze $TIMESTAMP group/interval |
| 84 | ``` |
| 85 | |
| 86 | Where `$TIMESTAMP` is either [RFC3339](https://www.rfc-editor.org/rfc/rfc3339) |
| 87 | formatted or `YYYY-MM-DD`. |
| 88 | Adding this comment will disable `group/interval` *until* `$TIMESTAMP`, after that |
| 89 | check will be re-enabled. |