Mimir integration

[gsanchietti]

📋 Description

This pull request adds Alertmanager integration based on Grafana Mimir, backend APIs for alert configuration and inspection, resolved-alert history persistence, automatic LinkFailed monitoring, Telegram notification support, and system-level silence actions for active alerts.

Backend API (/api/alerts)

• GET /api/alerts/config — retrieve the current alerting configuration from Mimir as structured JSON or redacted YAML
• POST /api/alerts/config — apply a new alerting configuration
• DELETE /api/alerts/config — replace the tenant configuration with a blackhole-only config while keeping the built-in history webhook active
• GET /api/alerts — list active alerts with optional filters (state, severity, system_key)
• GET /api/alerts/totals — return active alert counters plus resolved-history totals
• GET /api/alerts/trend — return resolved-alert trend data for the selected period
• GET /api/systems/:id/alerts — list active alerts for a single system
• POST /api/systems/:id/alerts/silences — create a silence for a single active system alert
• GET /api/systems/:id/alerts/history — return paginated resolved-alert history for a single system

Alerting configuration

• AlertingConfig supports global settings, per-severity overrides, per-system overrides, and Telegram integration
• SMTP settings are injected server-side
• Telegram bot token is stored encrypted and managed per-organization
• The built-in history webhook is always included in the generated Alertmanager config
• Email templates are available in English and Italian
• Telegram message templates support HTML formatting
• Backend access to alerting configuration and active-alert APIs is scoped through the authenticated user plus the organization_id query parameter where required by the current handlers

Collect service

• POST /api/alert_history receives Alertmanager webhooks and stores resolved alerts in PostgreSQL
• Bearer-token authentication is enforced through ALERTING_HISTORY_WEBHOOK_SECRET
• POST /api/services/mimir/alertmanager/api/v2/alerts proxies authenticated systems to Alertmanager with X-Scope-OrgID derived server-side
• When a system posts alerts through the collect proxy, labels.system_key is always overwritten with the authenticated system value
• Additional system and organization context labels are injected when missing
• POST /api/services/mimir/alertmanager/api/v2/silences proxies authenticated systems to Alertmanager with tenant scoping enforced by the server

Frontend

• The system detail active-alerts card exposes a silence action for users with manage:systems
• The silence flow uses a small confirmation modal with an optional comment and refreshes the active-alerts card after success
• Alert history is displayed with pagination and filtering

LinkFailed monitoring

• The heartbeat monitor checks every 60 seconds
• Systems move to inactive after exceeding HEARTBEAT_TIMEOUT_MINUTES
• A LinkFailed alert is automatically posted when a system fails to communicate
• The alert is resolved automatically when the system becomes active again
• Race conditions between heartbeat ingestion and system status updates are handled defensively

Notification channels

• Email notifications (SMTP) with configurable per-severity recipients
• Telegram notifications with HTML-formatted messages
• Webhook notifications with customizable payloads
• Per-organization configuration and per-severity overrides

Tooling and docs

• services/mimir/scripts/alerting_config.py manages alerting config and alert queries through the MY API
• services/mimir/scripts/alert.py fires, resolves, silences, and lists alerts through the collect proxy
• OpenAPI, database schema, migrations, tests, and docs cover the new alerting surface
• Telegram bot configuration guide added to alerting documentation

🧪 Validation

• cd backend && make pre-commit
• cd collect && make pre-commit
• cd frontend && npm run pre-commit

Related issue

Implements requirements from #72 (Alarm Management - Alertmanager Integration)

[github-actions]

🔗 Redirect URIs Added to Logto

The following redirect URIs have been automatically added to the Logto application configuration:

Redirect URIs:

• https://my-frontend-qa-pr-42.onrender.com/login-redirect
• https://my-proxy-qa-pr-42.onrender.com/login-redirect

Post-logout redirect URIs:

• https://my-frontend-qa-pr-42.onrender.com/login
• https://my-proxy-qa-pr-42.onrender.com/login

These will be automatically removed when the PR is closed or merged.

[github-actions]

🤖 My API structural change detected

Preview documentation

Structural change details

Added (20)

• DELETE /alerts/config
• DELETE /services/mimir/alertmanager/api/v2/silences/{silence_id}
• DELETE /systems/{id}/alerts/silences/{silence_id}
• GET /alerts
• GET /alerts/config
• GET /alerts/totals
• GET /alerts/trend
• GET /services/mimir/alertmanager/api/v2/alerts
• GET /services/mimir/alertmanager/api/v2/silences
• GET /services/mimir/alertmanager/api/v2/silences/{silence_id}
• GET /systems/{id}/alerts
• GET /systems/{id}/alerts/history
• GET /systems/{id}/alerts/silences
• GET /systems/{id}/alerts/silences/{silence_id}
• POST /alert_history
• POST /alerts/config
• POST /services/mimir/alertmanager/api/v2/alerts
• POST /services/mimir/alertmanager/api/v2/silences
• POST /systems/{id}/alerts/silences
• PUT /systems/{id}/alerts/silences/{silence_id}

Powered by Bump.sh

[gsanchietti]

update deploy

[github-actions]

🚀 Build triggers updated!

All .render-build-trigger files have been automatically updated to ensure fresh deployments of all services in the PR preview environment.

[andre8244]

IIUC pagination is missing in GET /api/alerts and GET /api/systems/:id/alerts

[github-actions]

🗑️ Redirect URIs Removed from Logto

The following redirect URIs have been automatically removed from the Logto application configuration:

Redirect URIs:

• https://my-proxy-qa-pr-42.onrender.com/login-redirect

Post-logout redirect URIs:

• https://my-proxy-qa-pr-42.onrender.com/login

Cleanup completed for PR #42.