Skip to content

기능 개요

Ongrid 는 4-레이어 스택으로 조직됩니다. 이 분할이 존재하는 이유는 각 레이어가 다른 업데이트 주기, 다른 영향 범위, 다른 감사 자세를 갖기 때문 — 합치면 초기 프로토타입이 실패한 "여기저기 ssh 하는 AI 에이전트" 안티 패턴이 생깁니다.

운영자에게 왜 중요한가

아래 cross-cutting 기능 (감사, role 게이팅, 핫 provider 스왑, 영향 범위 워크) 의 대부분은 특정 레이어에 있습니다. "X 가 동작하지 않음" 질문이 있다면 이 페이지가 할당한 레이어가 설정이 있는 곳입니다.

네 레이어

L1 — Cluster

물리 또는 가상 인프라: 호스트, 매니저 프로세스, 임베디드 MySQL / Prometheus / Loki / Tempo / Grafana / Qdrant 스택, 양방향 geminio 터널 브로커.

Ongrid 는 이 레이어를 추상화하지 않습니다 — 인벤토리 스키마, CMDB 가 없습니다. 호스트는 edge 에이전트가 다이얼할 때 발견됩니다. 클러스터 레이어는 "매니저 바이너리가 런타임에 건드리는 모든 것" 입니다.

L2 — Edge 터널 + 디바이스 직접

각 호스트는 매니저로 단일 아웃바운드 geminio 연결을 수립하는 ongrid-edge 바이너리 하나를 실행. 터널이 멀티플렉스:

  • 리버스 RPC — 매니저 → edge 호출이 호스트의 기능을 호출 (Caller.Call(ctx, edgeID, method, body), internal/manager/biz/aiops/tools/registry.go:34).
  • WebSSH 스트림 — 전용 스트림 클래스 위의 대화형 터미널 트래픽, WebShell 참고.
  • 플러그인 시그널링 — edge 가 어떤 서브 플러그인 (promtail, otelcol, node-exporter) 을 스폰할지 알려 주는 컨트롤 채널.

"디바이스 직접" 아이디어는 L2 의 정의적 베팅: 매니저는 서비스 추상이 아닌 실제 호스트를 주소. 에이전트가 "edge-prod-04 에서 nginx 재시작" 이라고 말하면 정확히 한 호스트가 명령을 실행합니다.

L3 — Intelligence

그래프 커널 기반 ReAct 에이전트, 도구 레지스트리, persona 레지스트리, 지식 베이스, LLM provider 라우터. 전체가 매니저 측에 거주, 도구 가방을 통해서만 L2 와 대화.

핵심 파일:

L4 — Alerting

규칙 평가, incident 생명주기, 자동 RCA 팬아웃, 채널 라우팅, 억제. L1 이 수집하는 Prometheus + Loki + Tempo 신호로 구동되며, incident 발화 시 L3 (investigator persona) 를 통해 다시 씁니다.

핵심 파일:

기능 매트릭스

CapabilityLayerPage
알림 규칙 (8 metric + 6 log/trace kind)L4알림
Incident 발화 시 자동 근본 원인 분석L3 + L4RCA
Prometheus + Grafana 임베드L1Monitoring
Loki 로그 검색 + 로그 알림L1 + L4로그
Tempo 트레이스 검색 + 트레이스 알림L1 + L4트레이스
영향 범위 워크가 있는 서비스 / 디바이스 그래프L3토폴로지
Vault + 자체 저장소에 대한 RAGL3지식 베이스
30+ 호스트 / 가관측성 / 지식 도구L2 + L3기능
전체 세션 녹화가 있는 WebSSHL2WebShell

이 페이지가 아닌 것

이것은 운영자 대면 개요입니다. 설계 근거 (왜 PromQL 이 표준 predicate 로 유지됐는지, 왜 edge 가 다이얼 아웃하는지, 왜 scrape 보다 remote_write 가 선호되는지) 는 GitHub 저장소의 docs/ 트리에 있는 ADR/HLD 인덱스를 참고하세요.

같이 보기