Skip to main content
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.
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:
Result looks like: 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:
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

​
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):
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 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):
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:

​
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: