cloudflare/pint
Publicmirrored from https://github.com/cloudflare/pintAvailable
docs/checks/alerts/template.md
76lines · modecode
| 1 | --- |
| 2 | layout: default |
| 3 | parent: Checks |
| 4 | grand_parent: Documentation |
| 5 | --- |
| 6 | |
| 7 | # alerts/template |
| 8 | |
| 9 | This check validates templates used in annotations and labels for alerting rules. |
| 10 | See [Prometheus docs](https://prometheus.io/docs/prometheus/latest/configuration/template_reference/) |
| 11 | for details of supported template syntax. |
| 12 | |
| 13 | This check will also inspect all alert rules and warn if any of them |
| 14 | use query return values inside alert labels. |
| 15 | Two alerts are identical if they have identical labels, so using |
| 16 | query value will generate a new unique alert every time it changes. |
| 17 | If alerting rule is using `for` it might prevent it from ever firing |
| 18 | if the value keeps changing before `for` is satisfied, because |
| 19 | Prometheus will consider it to be a new alert and start `for` tracking |
| 20 | from zero. |
| 21 | |
| 22 | If you want to include query value in the alert then use annotations |
| 23 | for that. Annotations are not used to compare alert identity and so |
| 24 | the value of any annotation can change between alert evaluations. |
| 25 | |
| 26 | See [this blog post](https://www.robustperception.io/dont-put-the-value-in-alert-labels) |
| 27 | for more details. |
| 28 | |
| 29 | This check will also warn if an annotation template uses `.Value` to display |
| 30 | the result of a query that uses `rate()`, `irate()`, or `deriv()` without |
| 31 | applying one of the `humanize` template functions. These functions produce |
| 32 | very small floating point numbers that are hard to read without formatting. |
| 33 | |
| 34 | ## Configuration |
| 35 | |
| 36 | This check doesn't have any configuration options. |
| 37 | |
| 38 | ## How to enable it |
| 39 | |
| 40 | This check is enabled by default. |
| 41 | |
| 42 | ## How to disable it |
| 43 | |
| 44 | You can disable this check globally by adding this config block: |
| 45 | |
| 46 | ```js |
| 47 | checks { |
| 48 | disabled = ["alerts/template"] |
| 49 | } |
| 50 | ``` |
| 51 | |
| 52 | You can also disable it for all rules inside a given file by adding |
| 53 | a comment anywhere in that file. Example: |
| 54 | |
| 55 | ```yaml |
| 56 | # pint file/disable alerts/template |
| 57 | ``` |
| 58 | |
| 59 | Or you can disable it per rule by adding a comment to it. Example: |
| 60 | |
| 61 | ```yaml |
| 62 | # pint disable alerts/template |
| 63 | ``` |
| 64 | |
| 65 | ## How to snooze it |
| 66 | |
| 67 | You can disable this check until a given time by adding a comment to it. Example: |
| 68 | |
| 69 | ```yaml |
| 70 | # pint snooze $TIMESTAMP alerts/template |
| 71 | ``` |
| 72 | |
| 73 | Where `$TIMESTAMP` is either [RFC3339](https://www.rfc-editor.org/rfc/rfc3339) |
| 74 | formatted or `YYYY-MM-DD`. |
| 75 | Adding this comment will disable `alerts/template` *until* `$TIMESTAMP`, after which |
| 76 | the check will be re-enabled. |
| 77 | |