Skip to content

Commit

Permalink
Add Configuring Rules (#1826)
Browse files Browse the repository at this point in the history
Signed-off-by: Xiang Dai <764524258@qq.com>
  • Loading branch information
daixiang0 authored and bwplotka committed Dec 18, 2019
1 parent db8f347 commit 612f533
Showing 1 changed file with 84 additions and 0 deletions.
84 changes: 84 additions & 0 deletions docs/components/rule.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,90 @@ For Ruler the read path is distributed, since most likely Ruler is querying Than
This means that **query failure** are more likely to happen, that's why clear strategy on what will happen to alert and during query
unavailability is the key.


## Configuring Rules


Rule files use YAML, the syntax of a rule file is:

```
groups:
[ - <rule_group> ]
```

A simple example rules file would be:

```
groups:
- name: example
rules:
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)
```

<rule_group>

```
# The name of the group. Must be unique within a file.
name: <string>
# How often rules in the group are evaluated.
[ interval: <duration> | default = global.evaluation_interval ]
rules:
[ - <rule> ... ]
```

Thanos supports two types of rules which may be configured and then evaluated at regular intervals: recording rules and alerting rules.

### Recording Rules

Recording rules allow you to precompute frequently needed or computationally expensive expressions and save their result as a new set of time series. Querying the precomputed result will then often be much faster than executing the original expression every time it is needed. This is especially useful for dashboards, which need to query the same expression repeatedly every time they refresh.

Recording and alerting rules exist in a rule group. Rules within a group are run sequentially at a regular interval.

The syntax for recording rules is:

```
# The name of the time series to output to. Must be a valid metric name.
record: <string>
# The PromQL expression to evaluate. Every evaluation cycle this is
# evaluated at the current time, and the result recorded as a new set of
# time series with the metric name as given by 'record'.
expr: <string>
# Labels to add or overwrite before storing the result.
labels:
[ <labelname>: <labelvalue> ]
```

### Alerting Rules

The syntax for alerting rules is:

```
# The name of the alert. Must be a valid metric name.
alert: <string>
# The PromQL expression to evaluate. Every evaluation cycle this is
# evaluated at the current time, and all resultant time series become
# pending/firing alerts.
expr: <string>
# Alerts are considered firing once they have been returned for this long.
# Alerts which have not yet fired for long enough are considered pending.
[ for: <duration> | default = 0s ]
# Labels to add or overwrite for each alert.
labels:
[ <labelname>: <tmpl_string> ]
# Annotations to add to each alert.
annotations:
[ <labelname>: <tmpl_string> ]
```

## Partial Response

See [this](query.md#partial-response) on initial info.
Expand Down

0 comments on commit 612f533

Please sign in to comment.