Overview de capacidades
Ongrid está organizado como un stack de 4 capas. La división existe porque cada capa tiene una cadencia de actualización distinta, un blast radius distinto y una postura de auditoría distinta — colapsarlas produjo el anti-patrón del "agente de IA que se hace ssh por ahí" en el que fallaron los primeros prototipos.
Por qué importa para los operadores
La mayoría de las features transversales abajo (audit, gating por rol, swap de provider en caliente, recorrido de blast-radius) viven en una capa específica. Si tienes una pregunta "X no funciona", la capa que esta página le asigna es donde vive su config.
Las cuatro capas
L1 — Cluster
La infraestructura física o virtual: hosts, el proceso manager, el stack embebido MySQL / Prometheus / Loki / Tempo / Grafana / Qdrant, y el broker de túnel bidireccional geminio.
Ongrid NO abstrae esta capa — no hay esquema de inventario, no hay CMDB. Los hosts se descubren cuando un agente de edge marca a casa. La capa de cluster es "todo lo que el binario del manager toca en runtime".
L2 — Túnel del edge + device-direct
Cada host corre un binario ongrid-edge que establece una única conexión geminio saliente al manager. El túnel multiplexa:
- RPCs reversos — llamadas manager → edge invocando un skill en el host (
Caller.Call(ctx, edgeID, method, body),internal/manager/biz/aiops/tools/registry.go:34). - Streams WebSSH — tráfico interactivo de terminal sobre una clase de stream dedicada, ver WebShell.
- Señalización de plugin — un canal de control que le dice al edge qué sub-plugins (
promtail,otelcol,node-exporter) lanzar.
La idea de "device-direct" es la apuesta definitoria de L2: el manager direcciona hosts reales, no abstracciones de servicio. Cuando el agente dice "reinicia nginx en edge-prod-04", exactamente un host corre el comando.
L3 — Intelligence
El agente ReAct con kernel de grafo, el registry de tools, el registry de personas, la base de conocimiento y el router de provider LLM. Vive enteramente del lado del manager, habla con L2 solo a través del toolbag.
Archivos clave:
internal/manager/biz/aiops/tools/— 30+ BaseTools, las manos del LLM.internal/pkg/llm/—MultiClient,RoutingChatModel,BudgetChecker.internal/manager/biz/knowledge/— Qdrant + vault + upload.
L4 — Alerting
Evaluación de reglas, ciclo de vida de incidentes, fan-out auto-RCA, routing por canal, inhibición. Manejado por las señales de Prometheus + Loki + Tempo que L1 recolecta, y escribe de vuelta a través de L3 (la persona investigator) cuando un incidente dispara.
Archivos clave:
internal/manager/biz/alert/pipeline.go— el tick del evaluator.internal/manager/biz/alert/investigator/usecase.go— auto-RCA.
Matriz de capacidades
| Capacidad | Capa | Página |
|---|---|---|
| Reglas de alerta (8 métrica + 6 log/traza kinds) | L4 | Alertas |
| Análisis automático de causa raíz al disparar incidente | L3 + L4 | RCA |
| Embed de Prometheus + Grafana | L1 | Monitoring |
| Búsqueda de logs Loki + alertas de log | L1 + L4 | Logs |
| Búsqueda de trazas Tempo + alertas de traza | L1 + L4 | Trazas |
| Grafo de servicios / devices con recorrido de blast-radius | L3 | Topología |
| RAG contra vault + tus propios repos | L3 | Conocimiento |
| 30+ tools de host / observabilidad / conocimiento | L2 + L3 | Skills |
| WebSSH con grabación de sesión completa | L2 | WebShell |
Qué no es esta página
Este es el overview orientado al operador. Para la justificación de diseño (por qué se mantuvo PromQL como predicado canónico, por qué el edge marca hacia afuera, por qué remote_write se prefiere sobre scrape) ver el índice ADR/HLD en el árbol docs/ del repo de GitHub.
Ver también
- Arquitectura — la misma división de 4 capas expresada como diagrama de despliegue.
- Conceptos — vocabulario (edge, device, incidente, persona, scope).
- Esquema de reglas de alerta — el wire format de las filas de regla que resume la página de Alertas.