refactor: system backups page#101
Draft
andre8244 wants to merge 5 commits into
Draft
Conversation
Builds the operational alerts surface on top of Mimir Alertmanager: a
single paginated list endpoint plus per-system silence management,
resolved-alert history, and aggregations the UI uses to render the
overview page.
Endpoints:
- GET /alerts (cross-hierarchy / single-tenant / sub-tree scoping,
multi-value label filters, sorting on starts_at/severity/alertname,
pagination with stable fingerprint tiebreaker)
- GET /alerts/history (paginated alert_history rows with date range)
- GET /alerts/totals / /trend / /stats (severity buckets, time-series
deltas, top-N alertname/system_key, MTTR/MTBF)
- GET /alerts/{fingerprint}/activity (silence/unsilence audit timeline,
populated transparently by the silence endpoints)
- GET /systems/{id}/alerts and friends scoped to a single system
Each alert in the list is enriched with a local-DB system object
(id/name/type) so the frontend doesn't need a per-row round-trip.
Per-tenant fan-out failures are surfaced as warnings rather than
failing the whole request.
Gated on the existing read:systems / manage:systems permissions:
read for the list endpoints, manage for silence create/update/delete.
Adds POST/GET/DELETE /alerts/config — every organization saves its own
layer; the effective Mimir YAML for any tenant is the server-side merge
of all layers walking up the hierarchy from the tenant to the Owner.
The merge stays internal: /alerts/config exposes only the caller's own
row, never an inherited or merged view (no leakage of upstream
recipients or secrets to descendants).
Model is flat and recipient-centric:
enabled: {email, webhook, telegram} tri-state per layer
email_recipients: [{address, severities[], language, format}]
webhook_recipients: [{name, url, severities[]}]
telegram_recipients: [{bot_token, chat_id, severities[]}]
Per-recipient severities=[] means "all severities". Email recipients
additionally carry language (en|it) and format (html|plain) which the
template renderer turns into per-email_configs overrides:
- format=html emits our html template + our text fallback (multipart)
- format=plain emits our text template plus html: '' (the empty html
is mandatory — Alertmanager otherwise falls back to its built-in
HTML body and overrides ours with the generic "Sent by Alertmanager")
Rendering fans out a receiver per severity (critical/warning/info);
recipients with severities=[] land on every per-severity receiver. The
builtin alert-history webhook is always attached at the top of the
routes (continue: true) so history persists regardless of config.
Additive-only contract: descendants can ADD recipients but cannot
disable channels enabled by ancestors. The server normalises any
explicit false in enabled.{email,webhook,telegram} from non-Owner
layers to null on storage. Save+propagate is serialised per-org via an
in-process mutex; per-tenant push failures land in warnings[] without
failing the save. Body capped at 1 MiB; oversized requests get 413.
Gated on the dedicated alerts resource (read:alerts for GET,
manage:alerts for POST/DELETE) — admin/super only by default.
Includes:
- models/alerting.go: flat shape + Validate
- services/alerting/{merge,template,embed,effective,provision,redaction}.go
- migration 024_add_alert_config_layers
- entities/local_alert_config_layers.go (repo)
- middleware/body_limit.go
- logger/helpers.go: LogBusinessOperationDetails for audit snapshots
- methods/alerting.go: ConfigureAlerts/GetAlertingConfig/DisableAlerts
- methods/{customers,distributors,resellers}.go: provision sig change
- openapi.yaml: schemas + endpoints + 6 request examples + response examples
- templates: per-language dispatchers (alert_<lang>.html|txt|subject)
plus telegram_<lang>.message
The user-facing alerting docs and the AGENTS reference were stuck on
the previous shape (global mail_addresses/webhook_receivers + per-
severity + per-system overrides + per-tenant email_template_lang).
Rewrite the 'Alerting Configuration' section in both en and it locales
to describe the new layer model:
- flat shape: enabled tri-state + email_recipients/webhook_recipients/
telegram_recipients with per-recipient severities[]
- email recipients additionally carry language (en|it) and format
(html|plain)
- merge across the org hierarchy stays server-side; /alerts/config
returns only the caller's own layer (no inherited / merged view)
- additive-only contract; non-Owner explicit false on enabled.X is
normalised to null at save time
- RBAC: the Alerting Configuration tab is gated on read:alerts /
manage:alerts (admin/super only); the alerts list stays on
read:systems / manage:systems
Refresh the Telegram step-3 example to use the new shape and update
the email-notifications section to reflect per-recipient language and
format. Realign AGENTS.md §3.5 with the same wording.
…GET /alerts Stamp system_type at ingest (collect) alongside the other system_* labels and drop the per-request DB lookup that enriched each alert with a separate system object. Saves a SELECT on every GET /alerts and removes a redundant field the frontend never read.
Contributor
|
🔗 Redirect URIs Added to Logto The following redirect URIs have been automatically added to the Logto application configuration: Redirect URIs:
Post-logout redirect URIs:
These will be automatically removed when the PR is closed or merged. |
Contributor
🚨 Breaking My API change detectedStructural change detailsAdded (1)
Modified (10)
Powered by Bump.sh |
80211a6 to
f7d17d2
Compare
f7d17d2 to
a9c986f
Compare
74168a3 to
08a07dd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 Description
Refactor System backups page
Related Issue: #83
🚀 Testing Environment
To trigger a fresh deployment of all services in the PR preview environment, comment:
Automatic PR environments:
✅ Merge Checklist
Code Quality:
Builds: