Monitoring

Ongrid livre un pipeline de monitoring fonctionnel out of the box et est conçu pour s'incliner vers le vôtre quand vous en avez un.

Le plan de données

edge:
  hostmetrics, procmetrics, node-exporter  ─┐
                                            │  remote_write (HTTPS direct)
                                            ▼
                                       ┌─────────┐
                                       │  Prom   │  (default: bundled)
                                       └────┬────┘
                                            │ query_range / instant
                                            ▼
                                  ┌──────────────────────┐
                                  │  manager:            │
                                  │   - alert evaluator  │
                                  │   - query_promql     │
                                  │   - /api/grafana     │
                                  └──────────────────────┘

Le défaut est un Prometheus embarqué tournant dans le docker-compose à prometheus:9090. Les edges poussent directement vers lui sur HTTPS — pas de scrape, pas de découverte de nœuds. C'est la séparation plan-de-données / plan-de-contrôle d'ADR-014 : le tunnel geminio porte le contrôle, la télémétrie va en direct.

Pourquoi en direct, pas via le tunnel

À une cardinalité ≥ 5 k séries/sec sur une install de 50 hosts, multiplexer remote_write à travers le tunnel de contrôle geminio s'étouffait. Le remote_write direct retire le manager du chemin chaud et laisse le write-ahead-log de Prom gérer le buffering d'ingestion. Le compromis est un endpoint HTTPS de plus à exposer ; voir Installation serveur pour le snippet de reverse-proxy nginx.

Built-in vs Prom externe

Les deux modes sont de première classe.

Built-in (défaut)

docker compose up amène prometheus:v2.55 avec --web.enable-remote-write-receiver. Le stockage est un volume nommé ongrid_prom_data. La rétention est par défaut à 15j — ajustez via PROMETHEUS_RETENTION dans .env.

Le manager lui parle à http://prometheus:9090 via l'env ONGRID_PROM_QUERY_URL. Pas d'autre config nécessaire.

Externe

Pointez ONGRID_PROM_QUERY_URL vers votre propre endpoint de requête Prom / VictoriaMetrics / Thanos. Les edges continuent à remote_write — pointez-les vers votre URL d'ingest en settant le remote_write_url par edge dans la config plugin Edge (internal/manager/biz/edge/plugin_config.go).

Le Prom cloud-embarqué peut rester en marche comme Prom d'« auto-observabilité » qui ne scrape que le manager lui-même (les métriques self-obs d'ADR-026 y vivent). Les alertes qui ont besoin des deux moitiés peuvent être définies deux fois avec des match_scope_types différents.

Le chemin de requête

Deux consommateurs, un client.

Evaluator d'alerte

PipelineEvaluator.evaluatePromQuery tourne l'Expr de chaque règle metric_raw activée sur un tick. Les opérateurs de comparaison de PromQL (up == 0, cpu_pct > 90) SONT le prédicat — Prom drop les séries non-matchantes de la réponse, donc l'evaluator part juste un incident par entrée de vecteur renvoyée et balaye le reste lors du sweep de récupération du tick suivant.

// pipeline.go:269
res, err := e.prom.Query(ctx, rule.Expr, now)
// ...
for _, ent := range entries {
    dedupeKey := fmt.Sprintf("pipeline:%s:%s", rule.RuleKey, labelSetKey(ent.Metric))
    // ... RecordFiring + notify
}

L'outil query_promql

Le LLM reçoit un BaseTool appelé query_promql qui prend une requête instant ou range et renvoie le JSON vector / matrix. La persona investigator l'utilise comme sa sonde de métriques principale ; le chat coordinator l'utilise chaque fois que vous demandez « quel est le cpu sur edge-prod-04 maintenant ? ».

Le schéma vit dans query_promql_basetool.go ; le moteur sous-jacent est internal/pkg/promquery.

Grafana embarqué

Le compose livre Grafana à grafana:3000. Le manager le proxify sous /api/grafana/* (auth vérifiée au proxy) pour que MonitorPanel.tsx de la SPA puisse embarquer des iframes en un clic — pas de login Grafana séparé.

Out of box, le manager mirroir les définitions de panel de monitoring internes dans Grafana via biz/grafana/Service sur un tick de sync. Les opérateurs éditent les panels dans Grafana (l'éditeur riche), le manager les reprend. La page MonitorEditor dans la SPA est un mince read-then-redirect qui ouvre l'éditeur de panel Grafana pré-rempli avec la série pertinente.

Credentials Grafana

Le Grafana embarqué est livré avec admin / admin. Changez avant exposition. Voir Check-list du premier démarrage.

Auto-observabilité

ADR-026 a câblé /metrics sur le manager + 6 alertes baseline (spike de tokens LLM, stall de l'evaluator d'alertes, tempête de déconnexion de tunnel, lag d'audit-log, backlog d'investigator, latence RCA p99). Celles-ci sont seedées au premier démarrage dans les tables rules + dashboard et ré-asserties à chaque upgrade.

Le Prom embarqué scrape le /metrics du manager. Le mode Prom externe vous demande d'ajouter une cible de scrape à manager:9100 (défaut ONGRID_METRICS_ADDR).

Voir aussi

• Alertes — les types de règles qui interrogent Prom.
• Traces — le générateur spanmetrics qui réécrit les séries traces_spanmetrics_* dans le même Prom.
• Logs — le pipeline parallèle pour Loki.
• Variables d'environnement — chaque bouton ONGRID_PROM_* et PROMETHEUS_*.