Aperçu des capacités
Ongrid est organisé en une stack à 4 couches. Le découpage existe parce que chaque couche a une cadence de mise à jour différente, un blast radius différent et une posture d'audit différente — les fondre produit l'anti-pattern de l'« agent IA qui fait des ssh partout » sur lequel les premiers prototypes ont échoué.
Pourquoi cela importe pour les opérateurs
La plupart des features transversales ci-dessous (audit, gating de rôle, swap à chaud de provider, marche de blast-radius) vivent à une couche spécifique. Si vous avez une question « X ne marche pas », la couche que cette page lui attribue est où sa config vit.
Les quatre couches
L1 — Cluster
L'infrastructure physique ou virtuelle : hosts, le processus manager, la stack embarquée MySQL / Prometheus / Loki / Tempo / Grafana / Qdrant, et le broker de tunnel geminio bidirectionnel.
Ongrid n'abstrait PAS cette couche — il n'y a pas de schéma d'inventaire, pas de CMDB. Les hosts sont découverts quand un agent edge se connecte. La couche cluster est « tout ce que le binaire manager touche au runtime ».
L2 — Tunnel edge + accès direct device
Chaque host fait tourner un binaire ongrid-edge qui établit une connexion geminio sortante unique vers le manager. Le tunnel multiplexe :
- RPCs inversés — appels manager → edge invoquant un skill sur le host (
Caller.Call(ctx, edgeID, method, body),internal/manager/biz/aiops/tools/registry.go:34). - Streams WebSSH — trafic terminal interactif sur une classe de stream dédiée, voir WebShell.
- Signalling de plugin — un canal de contrôle qui dit à l'edge quels sous-plugins (
promtail,otelcol,node-exporter) spawner.
L'idée « accès direct device » est le pari définissant de L2 : le manager adresse de vrais hosts, pas des abstractions de service. Quand l'agent dit « redémarre nginx sur edge-prod-04 », exactement un host exécute la commande.
L3 — Intelligence
L'agent ReAct à graph kernel, le registre d'outils, le registre de personas, la base de connaissances et le routeur de provider LLM. Vit entièrement côté manager, parle à L2 uniquement via le sac d'outils.
Fichiers clés :
internal/manager/biz/aiops/tools/— 30+ BaseTools, les mains du LLM.internal/pkg/llm/—MultiClient,RoutingChatModel,BudgetChecker.internal/manager/biz/knowledge/— Qdrant + vault + upload.
L4 — Alerting
Évaluation de règles, cycle de vie d'incident, fan-out auto-RCA, routage de canal, inhibition. Piloté par les signaux Prometheus + Loki + Tempo que L1 collecte, et écrit en retour via L3 (la persona investigator) quand un incident part.
Fichiers clés :
internal/manager/biz/alert/pipeline.go— le tick de l'evaluator.internal/manager/biz/alert/investigator/usecase.go— auto-RCA.
Matrice des capacités
| Capacité | Couche | Page |
|---|---|---|
| Règles d'alerte (8 métriques + 6 types log/trace) | L4 | Alertes |
| Analyse automatique de cause racine au déclenchement d'incident | L3 + L4 | RCA |
| Prometheus + embed Grafana | L1 | Monitoring |
| Recherche de logs Loki + alertes log | L1 + L4 | Logs |
| Recherche de traces Tempo + alertes trace | L1 + L4 | Traces |
| Graphe service / device avec marche de blast-radius | L3 | Topologie |
| RAG contre vault + vos propres repos | L3 | Base de connaissances |
| 30+ outils host / observabilité / connaissances | L2 + L3 | Skills |
| WebSSH avec enregistrement complet de session | L2 | WebShell |
Ce que cette page n'est pas
Ceci est l'aperçu pour opérateurs. Pour la justification de design (pourquoi PromQL a été gardé comme prédicat canonique, pourquoi l'edge sort, pourquoi remote_write est préféré au scrape) voir l'index ADR/HLD dans l'arbre docs/ du repo GitHub.
Voir aussi
- Architecture — le même découpage à 4 couches exprimé comme schéma de déploiement.
- Concepts — vocabulaire (edge, device, incident, persona, scope).
- Schéma de règle d'alerte — le format wire des lignes de règle que la page Alertes résume.