Log analytics
Volumes, categories, patterns and alerting on what the logs say in aggregate.
Logs & Errors → Log Analytics treats logs as a measurement rather than as text.
Setup
Settings → Datasources → ELK. Elasticsearch or OpenSearch endpoint, credentials, and the indices to read.
What it measures
| Volume | Lines per service, per level, over time |
| Categories | Automatically grouped message shapes |
| Top messages | The most frequent lines, per day |
| Error share | Errors as a proportion of all lines |
Categories
Messages are grouped by shape, so user 4821 not found and user 9930 not found are one category with a count rather than two lines.
This is what makes "errors are up" actionable: you get which error is up.
Alerting
Rules on:
- volume — lines per minute above or below a threshold
- error rate — errors as a share of total
- a specific category appearing, or exceeding a count
- silence — a service that has stopped logging
The silence rule is the one people forget and the one that catches the worst outages. A service that stops logging entirely produces no error alert, because there are no errors. It looks perfect.
Volume alerts need a floor
A percentage-based rule on a low-volume service fires constantly. Pair the rate condition with a volume guard — the same pattern as SQL alerts — so a 100% error rate out of two lines does not page anybody.
Cross-source correlation
Log spikes are correlated with deploys, config changes and flag flips from the same window. The correlation says what else happened, never what caused it — it is a lead, not a conclusion.
Related
- Log search — finding an individual line
- Patterns — recurring shapes across sources
- Anomalies — statistical detection rather than thresholds
Where this behaviour lives: backend/internal/worker/elk_sync.go, backend/internal/worker/elk_alert_worker.go. If the code and this page disagree, the code is right — please fix the page.
Part of Logs and errors — What the software said about itself, and what was unusual about it.