Visão geral das capacidades
Ongrid é organizado como uma stack de 4 camadas. O split existe porque cada camada tem uma cadência de atualização diferente, um blast radius diferente, e uma postura de auditoria diferente — colapsar tudo produzia o anti-padrão "AI agent que faz ssh por aí" que os protótipos iniciais falhavam em corrigir.
Por que isso importa para operadores
A maioria das features cross-cutting abaixo (auditoria, gate por role, hot swap de provider, walk de blast radius) vive em uma camada específica. Se você tem uma pergunta "X não funciona", a camada que esta página atribui a ele é onde sua config vive.
As quatro camadas
L1 — Cluster
A infra física ou virtual: hosts, o processo manager, a stack embarcada MySQL / Prometheus / Loki / Tempo / Grafana / Qdrant, e o broker de tunnel geminio bidirecional.
O Ongrid NÃO abstrai essa camada — não há schema de inventário, não há CMDB. Hosts são descobertos quando um edge agent disca para casa. A camada de cluster é "tudo que o binário do manager toca em runtime".
L2 — Tunnel de edge + device-direct
Cada host roda um binário ongrid-edge que estabelece uma única conexão geminio outbound ao manager. O tunnel multiplexa:
- RPCs reversos — chamadas manager → edge invocando uma skill no host (
Caller.Call(ctx, edgeID, method, body),internal/manager/biz/aiops/tools/registry.go:34). - Streams WebSSH — tráfego de terminal interativo sobre uma classe de stream dedicada, veja WebShell.
- Sinalização de plugin — um canal de controle que diz ao edge quais sub-plugins (
promtail,otelcol,node-exporter) dar spawn.
A ideia "device-direct" é a aposta definidora do L2: o manager endereça hosts reais, não abstrações de serviço. Quando o agent diz "reinicie o nginx no edge-prod-04", exatamente um host roda o comando.
L3 — Inteligência
O agent ReAct de graph-kernel, o registry de tools, o registry de personas, a base de conhecimento, e o router de provider de LLM. Vive inteiramente do lado do manager, fala com L2 só pela tool bag.
Arquivos-chave:
internal/manager/biz/aiops/tools/— 30+ BaseTools, as mãos do LLM.internal/pkg/llm/—MultiClient,RoutingChatModel,BudgetChecker.internal/manager/biz/knowledge/— Qdrant + vault + upload.
L4 — Alertas
Avaliação de rule, ciclo de vida de incidente, fan-out de auto-RCA, roteamento de canal, inibição. Dirigida pelos sinais Prometheus + Loki + Tempo que o L1 coleta, e escreve de volta pelo L3 (a persona investigator) quando um incidente dispara.
Arquivos-chave:
internal/manager/biz/alert/pipeline.go— o tick do evaluator.internal/manager/biz/alert/investigator/usecase.go— auto-RCA.
Matriz de capacidades
| Capacidade | Camada | Página |
|---|---|---|
| Rules de alerta (8 métrica + 6 log/trace kinds) | L4 | Alertas |
| Auto root-cause analysis em disparo de incidente | L3 + L4 | RCA |
| Prometheus + embed de Grafana | L1 | Monitoramento |
| Busca de log Loki + alertas de log | L1 + L4 | Logs |
| Busca de trace Tempo + alertas de trace | L1 + L4 | Traces |
| Grafo de serviço / device com walk de blast radius | L3 | Topologia |
| RAG contra vault + seus próprios repos | L3 | Conhecimento |
| 30+ tools de host / observabilidade / conhecimento | L2 + L3 | Skills |
| WebSSH com gravação completa de sessão | L2 | WebShell |
O que esta página não é
Esta é a visão geral voltada ao operador. Para a justificativa de design (por que PromQL foi mantido como predicado canônico, por que o edge disca para fora, por que remote_write é preferido a scrape), veja o índice ADR/HLD na árvore docs/ do repo no GitHub.
Veja também
- Arquitetura — o mesmo split de 4 camadas expresso como diagrama de deployment.
- Conceitos — vocabulário (edge, device, incident, persona, scope).
- Schema de rule de alerta — o formato wire das linhas de rule que a página Alertas resume.