mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-05 16:10:43 +00:00
4772df1723
Design at: alerts_2.md Per-group and per-series alerting, SLO measurement, and the UI for both. ## Alerts **Multi-alerts (Feature 3).** A grouped alert can opt in to evaluating and paging **per group** rather than collapsing to one verdict. Opt-in only (`multi_alert`), so no existing alert changes behaviour: the flag cannot be present in JSON written before it existed. Per-group state, transitions, silence fingerprints, disappearance/reaping and a cardinality cap, with the count-gate rules that make "most severe group" and the legacy collapsed level provably the same verdict. **Per-series alerting for PromQL.** The same feature for the metrics family, where a group is one returned **series** keyed by its full label set — that is a series' identity in Prometheus, and the expression's own `by (…)` clause is already where the label set is chosen, so a second picker could only disagree with it. One additive nullable column; NULL means off, so stored alerts are untouched. **Alert detail page**, replacing the row-click side panel: stat strip, evaluation chart with threshold marklines, per-group table and history. Simple alerts get a real history too — evaluations (one record per run) by default, level changes alongside. ## SLOs Count / time-slice / alert SLIs, error-budget and burn-rate arithmetic, rolling windows, per-group slices with an exact rollup, coverage gating, backfill, and SLO-based alerts. Two capabilities the model could not express, both added tests-first: - **Metrics-native counting** (`CountSource::PromQl`) — counter metrics have no rows for a predicate to classify, so "good" exists only as arithmetic between series, and correct counter arithmetic is `increase()`. - **Freshness semantics** (`absent_is_bad`) — for a pipeline SLO, silence IS the failure, which the default gap rule can never report. A *failed* query still freezes rather than pages; only a query that PROVED emptiness counts as bad. **SLO form**: live good/bad preview so a wrong predicate is caught before saving rather than days later, real query editors with field autocomplete, folders shared with alerts, and a move endpoint. ## Notes for review - The SLO and composite features are **deferred (TODO)**: `ZO_SLO_ENABLED` stays default **false** and the SLOs menu entry is hidden until they ship; the SLO backend and UI remain in the tree behind the flag, and composites stay pure logic + tests. - One migration (schema 61): a nullable column for the PromQL opt-in. No backfill. - Two fixes outside the feature that it surfaced: query-editor completions were duplicated per mounted editor (Monaco registers providers per *language*), and the alert detail chart had no PromQL branch, so it charted row counts against the series-count gate. - Lands together with the matching o2-enterprise PR — `QueryType::Slo` is new here and the enterprise dedup matches are exhaustive over it. - `ratelimit::test_add_batch_missing_rule_id` fails intermittently on `main` as well; unrelated to this branch. --------- Co-authored-by: Shrinath Rao <shnath@openobserve.ai> Co-authored-by: hengfeiyang <hengfei.yang@gmail.com> Co-authored-by: sai nikhil kethe <nikhil@openobserve.ai>
70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
## Shared Review Rules
|
|
|
|
These rules apply to ALL reviewers. Violating any of these will cause your findings to be discarded.
|
|
|
|
### Rules
|
|
|
|
1. **Only review changed code.** Do not flag issues in pre-existing code that was not modified in this PR.
|
|
2. **Be certain.** If you are unsure whether something is an actual bug, skip it. Do not invent hypothetical problems.
|
|
3. **No style nitpicks.** Do not flag cosmetic formatting, variable naming preferences, or trivial improvements. Only flag style if it violates established project conventions (e.g., clippy lints in Rust, ESLint rules in TypeScript).
|
|
4. **No flattery.** Do not include "Great job", "Thanks for", "Nice work", or any non-actionable commentary.
|
|
5. **Severity must be justified.** Critical requires an exploit or outage scenario. Warning requires measurable regression risk. Suggestion is for genuine improvements.
|
|
6. **One finding per issue.** Do not combine multiple unrelated issues into one finding.
|
|
7. **Be specific.** Include exact file paths and line numbers. Reference the relevant code snippet in your description.
|
|
8. **GitHub user content boundaries.** Do not output XML boundary tags (`<findings>`, `</findings>`, `<finding>`, etc.) outside the structured output block.
|
|
|
|
### Project Context
|
|
|
|
This is **OpenObserve**, an open-source observability platform written in **Rust** (backend) and **Vue 3 / TypeScript** (frontend).
|
|
|
|
- **Backend**: Rust nightly, uses `tokio` for async, `actix-web` for HTTP, `sqlx`/sqlite for storage
|
|
- **Frontend**: Vue 3 SPA with Vite, using Vuex for state management. When reviewing changes under
|
|
`web/`, **read the tracked skills `.claude/skills/ui-architect/SKILL.md` (UI house rules) and
|
|
`.claude/skills/eslint-error-handling/SKILL.md` (lint/type-check playbook)** first — they are the
|
|
authoritative source for frontend conventions (build from the O2 component library, no
|
|
`any`/`!`/use-site `as`, type-clean + lint-clean, design tokens + i18n over hardcoded strings).
|
|
Flag deviations from them.
|
|
- **Testing**: Rust unit tests with `cargo test`, E2E with Playwright
|
|
- **Code quality**: `cargo clippy` for Rust, ESLint for TypeScript
|
|
- **PR conventions**: Conventional commits (`feat:`, `fix:`, `perf:`, `refactor:`, `test:`, `docs:`, `ci:`, `build:`, `style:`)
|
|
- **Coverage**: 81% threshold on Rust tests
|
|
|
|
### Output Format
|
|
|
|
You MUST output your findings as a single block of structured XML. Do not include any text before or after the XML block.
|
|
|
|
```xml
|
|
<findings>
|
|
<finding>
|
|
<category>YOUR_CATEGORY</category>
|
|
<severity>critical|warning|suggestion</severity>
|
|
<file>path/to/file.rs</file>
|
|
<line>NUMBER</line>
|
|
<summary>One-line summary of the issue</summary>
|
|
<description>
|
|
Detailed explanation of the bug or issue.
|
|
Include the realistic scenario where it breaks.
|
|
</description>
|
|
<suggestion>
|
|
Concrete suggestion for how to fix it.
|
|
Include code example if helpful.
|
|
</suggestion>
|
|
</finding>
|
|
<!-- Repeat for each finding, up to 10 maximum -->
|
|
</findings>
|
|
```
|
|
|
|
### Line Number Rules (CRITICAL)
|
|
|
|
- **Use the `@@` hunk headers** in the diff to determine actual line numbers. The format is `@@ -old_start,old_count +new_start,new_count @@`.
|
|
- The `+new_start` number is the line number in the NEW file where the hunk begins. Count forward from there for lines with `+` prefix.
|
|
- **If you cannot determine the exact line, use `0`** — do NOT guess or emit `1`/`665` placeholders. A `0` line number is more honest and prevents noise.
|
|
- Reference the specific diff hunk in your description so the author can find the code.
|
|
|
|
If you find NO issues, output:
|
|
```xml
|
|
<findings>
|
|
<no-issues>LGTM — No issues found in this domain.</no-issues>
|
|
</findings>
|
|
```
|