> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# VictoriaLogs
> Configure alert rules for VictoriaLogs data sources
Monitors queries VictoriaLogs via HTTP, supporting querying raw logs and statistical analysis, and performing threshold evaluation and data exists/missing checks based on results.
## 1. Prerequisites
### Query Modes
Calls `/select/logsql/query` interface, returning two-dimensional table data.
| Config Item | Description |
| --------------- | --------------------------------------------------------------------------------------------------------- |
| Query Statement | e.g., `error \| fields _time, _stream, _msg \| sort by (_time) desc` |
| Return Limit | Limit maximum returned rows, max can be set to 100 |
| Time Range | Specify query time window, e.g., "last 5 minutes" |
| Label Fields | Select stable fields that identify the alert object; other non-value fields become additional information |
| Value Fields | Required in threshold evaluation mode |
Calls `/select/logsql/stats_query` interface, returning Prometheus protocol format data.
| Config Item | Description |
| --------------- | --------------------------------------------------- |
| Query Statement | e.g., `_time:1d \| stats by (level) count(*) total` |
Query statement must include `_time` filter condition (like `_time:5m`), otherwise it will query all data causing performance issues.
VictoriaLogs data source most recommends using "Data Exists Mode", best suited for log scenarios.
## 2. Threshold Evaluation Mode
Both **Query Raw** and **Do Stats** query modes can be used. Examples below explain each.
### 2.1 Query Raw Example
Query statement example:
```
level:ERROR | stats by (level) count(*) total
```
Result looks like:
| level | total |
| ----- | ----- |
| ERROR | 150 |
Configure `level` as a label field and `total` as a value field. If the result contains other columns such as a log sample, those columns are carried with the alert as additional information. Threshold examples:
* Warning: `$A.total >= 50` or shorthand `$A >= 50` (since there's only one value field: total)
* Critical: `$A.total >= 100` or shorthand `$A >= 100` (since there's only one value field: total)
### 2.2 Do Stats Example
Query statement example:
`_time:1d and level:ERROR | stats by (level) count(*) total`
Result follows Prometheus protocol format:
```
total{level="ERROR"} 150
```
Different threshold different level configuration examples:
* Warning: `$A.total >= 50` or shorthand `$A >= 50` (since there's only one metric field: total)
* Critical: `$A.total >= 100` or shorthand `$A >= 100` (since there's only one metric field: total)
### 2.3 Recovery Logic
| Strategy | Description |
| ------------------------------- | ----------------------------------------------------------------------------------------- |
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (e.g., `$A.total < 10`) to reduce flapping |
| **Recovery Query** | Independent query for recovery evaluation, supports `${label_name}` variables |
| **Manual Close** | Keep the alert active until it is closed manually |
## 3. Data Exists Mode
This is the **most recommended VictoriaLogs alert configuration method**, because log scenarios are better suited for "alert when anomalous data exists" mode.
This mode writes all filter logic in VictoriaLogs query; Monitors only determines "whether data is returned".
**Query statement example (Do Stats mode):**
```
_time:15m and level:ERROR | stats by (level) count(*) total | filter total:>10
```
Where `| filter total:>10` filters data with `total` greater than 10. As long as data rows satisfying this condition are returned, Monitors triggers alert; if no data rows satisfy this condition, alert is considered recovered.
Data exists mode also supports configuring recovery: by default, recovery happens when the check query finds no data (the behavior above). You can also configure a recovery query, or choose "Manual close" (keep the alert active until it is closed manually).
With a **Raw log** query, select stable fields such as `service` or `host` as label fields, and keep `_time`, `_msg`, and other log context as additional information. Data exists mode does not require a value field.
If Label fields is empty, every returned field except the value fields becomes a label. Frequently changing timestamps and raw log content may make each log row a different alert object.
See [Query Result Field Mapping](/en/monitors/alert-rules/query-result-fields) for details.
## 4. No Data Mode
No Data mode is used to monitor "logs that should be continuously generated are no longer appearing", common scenarios:
* Application instance no longer producing logs (possibly process exited)
* Log collection pipeline anomaly (like agent down or output blocked)
### Configuration Example
Query statement (**Do Stats** mode):
```
_time:15m and level:INFO | stats by (level) count(*) total
```
Scenario: A service should always have INFO log output; if no INFO logs are generated in the last 15 minutes, trigger alert.
### Recovery Logic
No-data alerts support configuring the **alert ending mode**, which decides how the alert ends:
| Ending Mode | Description |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **End automatically when data reappears** | Default. The alert ends automatically once the data reappears |
| **End when data reappears or the timeout expires** | The alert ends when the data reappears or the automatic close timeout is reached. The timeout is in seconds with a minimum of 1. Available only when the "Alert if previously found data is now missing" mode is enabled |
| **Manual close only** | The alert stays active until you close it manually |
## 5. Getting Original Logs During Alert
Alert query conditions typically use "Do Stats" mode, which doesn't return original logs. Monitors supports configuring "Related Query" in alert rules to additionally query original logs when alert triggers.
"Related Query" results can be rendered in "Notes Description", example:
```
{{- if eq $status "firing" }}
triggered value: {{ $value | printf "%.3f" }}
{{- range $x := $relates.R1}}
{{- range $k, $v := $x.Fields }}
{{- if eq $k "_time" }}
{{ $k }} : {{ timeFormat $v "2006-01-02T15:04:05Z07:00" 8 }}
{{- else }}
{{ $k }} : {{ $v }}
{{- end }}
{{- end }}
{{- end}}
{{- else}}
Recovered
{{- end}}
```