cloudflare/pint
Publicmirrored from https://github.com/cloudflare/pintAvailable
docs/checks/yaml/parse.md
77lines · modecode
| 1 | --- |
| 2 | layout: default |
| 3 | parent: Checks |
| 4 | grand_parent: Documentation |
| 5 | --- |
| 6 | |
| 7 | # yaml/parse |
| 8 | |
| 9 | You will only ever see this check reporting problems if a file containing |
| 10 | Prometheus rules to check doesn't parse as valid [YAML](https://yaml.org/), |
| 11 | meaning that pint is unable to read any rules from that file or when |
| 12 | some fields are using the wrong type. |
| 13 | |
| 14 | This check will also report errors for files that cannot be read at all, |
| 15 | for example broken symlinks or files with insufficient permissions. |
| 16 | |
| 17 | This includes basic YAML parser checks but will also fail if a rule |
| 18 | block contains duplicate keys, example: |
| 19 | |
| 20 | ```yaml |
| 21 | - record: foo |
| 22 | expr: sum(my_metric) |
| 23 | expr: sum(my_metric) without(instance) |
| 24 | ``` |
| 25 | |
| 26 | Syntax checks enforced by pint are more strict than what Prometheus uses, |
| 27 | so a rule definition that fails pint checks might still be parsed by |
| 28 | Prometheus. This is because pint enforces that all fields have the correct type. |
| 29 | For example all annotations are expected to be strings, but the YAML parser |
| 30 | will load any value that can be represented as a string, for example a number: |
| 31 | |
| 32 | ```yaml |
| 33 | - alert: Foo |
| 34 | expr: up == 0 |
| 35 | annotations: |
| 36 | priotity: 1 |
| 37 | ``` |
| 38 | |
| 39 | The above rule will work in Prometheus but, for example, if you try to parse |
| 40 | such file using Python to find all rules where `priority` is `"1"` it will skip it, |
| 41 | because Python doesn't know the schema of rule file, so it returns whatever types |
| 42 | it finds: |
| 43 | |
| 44 | ```python |
| 45 | import yaml |
| 46 | |
| 47 | with open("rules.yaml") as f: |
| 48 | for rule in yaml.safe_load(f): |
| 49 | if rule["annotations"]["priority"] == "1": |
| 50 | ... |
| 51 | ``` |
| 52 | |
| 53 | This kind of type confusion can be even more problematic because YAML will |
| 54 | automatically convert certain string values to boolean, for example: |
| 55 | |
| 56 | ```yaml |
| 57 | - alert: Foo |
| 58 | expr: up == 0 |
| 59 | annotations: |
| 60 | critical: no |
| 61 | ``` |
| 62 | |
| 63 | In the above YAML will parse `no` as `false`. |
| 64 | There are other well known gotchas that are caused by YAML complex parsing rules |
| 65 | and the best way to avoid these is to always use explicit types for string. |
| 66 | |
| 67 | ## Configuration |
| 68 | |
| 69 | This check doesn't have any configuration options. |
| 70 | |
| 71 | ## How to enable it |
| 72 | |
| 73 | This check is enabled by default. |
| 74 | |
| 75 | ## How to disable it |
| 76 | |
| 77 | You cannot disable this check. |
| 78 | |