Концепции

Эта страница представляет существительные, которые использует Ongrid, в порядке зависимостей. Если вы прошли Quickstart, конкретная форма уже будет знакома; здесь мы ставим имена на неё.

Edge

Edge — это один работающий процесс ongrid-edge — один на хост. Это unit зачисления, телеметрии и удалённого контроля.

Каждый edge имеет:

server-generated access key (public-ish, идентифицирует edge) и secret key (показан один раз, используется для аутентификации туннеля),
долгоживущее исходящее TCP-соединение к frontier-брокеру на порту 40012,
флот контролируемых plugin subprocess'ов (promtail, node_exporter, process_exporter, otelcol-contrib),
heartbeat, который тикает каждые несколько секунд — когда он останавливается, edge помечается offline после ONGRID_ALERT_EDGE_OFFLINE_THRESHOLD (по умолчанию 90с).

Edge'и адресуются целочисленным edge_id (используется в URL и в agent tool-вызовах) или по name (используется в UI и find_topology_node). Вы можете перечислить их через list_edges, запустить команду на конкретном через bash с edge_id=N, или ограничить PromQL-запрос одним через query_promql с host-меткой.

Важно: edge read-only по умолчанию. Host-side скиллы агента — инспекция (bash, host_probe_*, query_processes, query_logs_tail, host_read_file) — они не мутируют. Write-действия идут через flow WebShell с audit-логированием.

См. установка edge и платформы / linux-edge для конкретных deploy-путей.

Device

Device — более мягкая концепция, чем edge. Где edge мапится 1:1 на процесс ongrid-edge, device — это всё, что Ongrid знает, что участвует в топологии — включая сервисы, виртуальные хосты, k8s-pods и внешние эндпоинты, обнаруженные через SD или импортированные вручную.

Пока UI выставляет device'ы неявно через вьюху Топология. Device — это узел в графе топологии; edge'и, сервисы и обнаруженные внешние системы — все узлы. Скиллы expand_topology и find_topology_node оперируют над device'ами — blast-radius рассуждение зависит от этого графа.

TIP

Если у вас пока только edge'и, ваш граф топологии — это один слой host-узлов. По мере того как скиллы вроде discover_services и интеграции с k8s SD его наполняют, вы увидите service-узлы, появляющиеся над хостами, и внешние эндпоинты сбоку.

Alert rule

Alert rule — это декларативный spec, который срабатывает alert event, когда условие держится на стриме телеметрии.

Модель правил Ongrid — двумерная: правило имеет kind (какой тип данных оно оценивает) и scope (где оценивает).

14 встроенных kind, сгруппированных по data plane:

Plane	Kinds
Host-метрики	`host_cpu`, `host_mem`, `host_disk`, `host_load`, `edge_offline`, `prom_ingest_fail`
Metric/PromQL	`promql_threshold`, `promql_burn_rate`, `promql_absence`
Логи	`log_match`, `log_volume`
Трейсы	`trace_latency`, `trace_error_rate`
Композит	`composite_and` (любые из выше, AND-нутые)

Правила несут:

условие на нативном языке запросов kind,
threshold + for длительность (как долго условие должно держаться до срабатывания),
severity (critical / warning / info),
routing — какие каналы получают уведомления, с опциональным cooldown.

6 встроенных host-правил (host_cpu, host_mem, host_disk, host_load, edge_offline, prom_ingest_fail) засеяны разумными дефолтами из env-переменных ONGRID_ALERT_*, и вы можете включать/выключать их из UI. Кастомные правила живут в MySQL и могут редактироваться свободно.

См. возможность alerts; схема правила задокументирована под Alert rule schema в Reference-сайдбаре.

Incident

Incident — это higher-order группировка alert-event'ов, которые принадлежат той же operational-истории. Где alert срабатывает каждый раз, когда условие держится, incident создаётся один раз и обновляется по мере прибытия связанных алертов.

Incident'ы — это unit'ы:

расследования — один incident, одно или более расследований.
paging — channel routing случается во время создания incident, а не per-alert.
timeline — страница detail incident — это хронологическая запись каждого alert-event, agent-действия и operator-заметки, связанной с той же историей.
закрытия — incident'ы движутся через open → investigating → mitigated → resolved (или false_positive). State-изменения audit-логируются.

Логика группировки сейчас намеренно простая: по кортежу {rule_id, edge_id} с окном активности 1 час. Roadmap — сделать это настраиваемым (group_by) per rule.

Investigation

Investigation — это структурированный agent-прогон, прикреплённый к incident'у. Output — это Markdown investigation report — ranked-список вероятных корневых причин плюс доказательства.

Типичное расследование проходит по пяти sub-agent'ам:

incident-investigator (coordinator) — декомпозирует incident в гипотезы.
sre specialist — проверяет SLO burn, недавние деплои, alert- корреляцию.
compute / disk / network specialist'ы — host-level probing на затронутых edge'ах.
ops specialist — поиск в базе знаний, runbook matching.
reviewer (critic-петля) — перечитывает черновик отчёта и спрашивает о пропущенных доказательствах до подписи.

Каждый шаг записывается в reasoning timeline в UI — каждый tool-вызов, каждый model token spent, каждая sub-agent диспетчеризация. Auditability — это смысл.

Вы также можете запустить расследование вручную с любого incident или из чата («investigate the order-service drop at 14:02»). Output идёт в то же место: investigation report, прикреплённый к incident.

См. возможность RCA; персона, которая запускает расследования, задокументирована под Incident investigator в Agents-сайдбаре.

Channel

Channel — это сконфигурированное исходящее назначение для уведомлений. «Channel» покрывает две слегка разных формы:

Webhook-каналы — Slack incoming webhook, Larksuite (Feishu) webhook, DingTalk webhook, WeCom group robot, generic webhook. Это односторонние — Ongrid постит карточку и всё.
IM-каналы — Telegram-бот, Larksuite-app, DingTalk-app, WeCom- app, Slack-app. Это двусторонние — тот же канал и доставляет алерты, И позволяет пользователю отвечать, задавать агенту вопрос, триггерить расследование.

Каждый канал имеет:

name (свободная форма), type (slack / feishu / dingtalk / wecom / webhook / telegram) и endpoint material (URL + secret, или app token + chat ID, или bot token + allow-from list…).
scope — какой org / какие роли могут видеть уведомления, маршрутизированные сюда. Плюс опциональный allow_from sender allowlist (Telegram специфично), чтобы случайные люди не могли разговаривать с вашим ботом.
default locale — на каком языке агент отвечает на этом канале, независимо от UI-локали.

Каналы — first-class: alert-правила ссылаются на них по имени, агент может отправлять проактивные сообщения на них, и вы можете подключить один канал к нескольким правилам без перевставки webhook URL.

См. обзор каналов.

IM channel (двусторонний)

Подтип «channel», стоящий отдельного упоминания. IM- канал превращает chat-поверхность (Telegram, Larksuite, DingTalk, WeCom, Slack) в полный agent-интерфейс.

Что двусторонний значит конкретно:

Агент может постить — алерты, investigation report, scheduled digest.
Пользователь может отвечать — вопросы («почему диск был полон?»), команды («/list edges»), follow-up («investigate that»).
Каждое сообщение связано с тем же user_agent и org, что и Web UI сессия — тот же RBAC, тот же audit log, тот же реестр скиллов.
sender_allowlist (Telegram) или app-permission gate (остальные) решает, кому разрешено разговаривать с ботом в группе.

Per-channel locale здесь важна. User-facing UI-локаль может быть английской; Telegram-группа всё равно может хотеть ответов на китайском; вы устанавливаете это per-channel.

См. channels / telegram для самого гибкого примера.

Persona / agent

Persona — это настраиваемая идентичность агента — YAML/JSON декларация:

какую модель агент предпочитает (с site default как fallback),
какие скиллы разрешены (скиллы несут scope: host, manager, org, и class: safe, payload_read, payload_write — см. RBAC),
системный промпт на голос агента,
опциональные sub-agent декларации (coordinator-персона может порождать specialist-персоны).

Ongrid поставляет несколько персон out of the box:

coordinator — по умолчанию; декомпозирует вопросы пользователей, маршрутизирует к specialist'ам или запускает скиллы напрямую.
incident-investigator — incident-mode coordinator; обходит топологию, коррелирует сигналы, рисует черновик отчёта.
sre, network, compute, disk, ops — specialist'ы, вызываемые coordinator'ами.
reviewer — critic-петля для черновика incident-investigator.

Вы можете авторировать свою. Формат персоны задокументирован под Agent persona format в Reference-сайдбаре. Кастомные персоны приземляются в MySQL; они подхватываются на следующем agent-прогоне.

Skill

Skill — это callable инструмент, который агент может вызвать. Каждый скилл декларирует:

name (например, query_promql, bash, expand_topology),
JSON-схему для аргументов и результата,
scope — host (запускается на конкретном edge через туннель), manager (запускается в процессе manager), или org (cross-edge manager-скилл),
class — safe, payload_read, payload_write. Read-only классы неограничены; write-классы идут через approval.
опциональное activation keyword — если установлено, скилл остаётся вне промпта, если только запрос пользователя не упоминает keyword. Это toolbag deferral-механизм, который держит реестр скиллов от пробивания context-окна модели.

Скиллы хранятся в реестре. Agent kernel (graph kernel по умолчанию) разрешает, какие скиллы видимы для текущего хода, на основе scope, RBAC и activation-keyword'ов. Примерно 30 скиллов отгружается в коробке (bash, host_probe_*, query_promql, query_logs, query_traceql, expand_topology, find_topology_node, read_repo, search_knowledge, web_search, …).

См. возможность skills; формат манифеста задокументирован под Skill manifest в Reference- сайдбаре. Кастомные скиллы могут быть загружены из ONGRID_SKILLS_EXTERNAL_DIRS.

База знаний

База знаний — это коллекция organisation-документов, которые агент может искать через search_knowledge. Документы эмбедятся один раз и хранятся в Qdrant; retrieval гибридный (vector + BM25).

Источники — послойно:

vault — встроенная, read-only knowledge, отгружаемая Ongrid. Примерно 100 Markdown-playbook, покрывающих сетевую диагностику, Linux- внутренности, Prometheus / Loki / Tempo рецепты, частые incident- паттерны. Vault синхронизируется из публичного ongridio/vault репозитория on demand.
upload — Markdown, TXT, PDF, DOCX файлы, загруженные org- админом. Проходит через docextract и приземляется в upload-дерево.
manual — записи, авторируемые напрямую в UI-редакторе.
repo — целые Git-репозитории, синхронизируемые с read-only SSH-ключами (ADR-023). Полезно для ingest вашего собственного runbook-репозитория.

Агент вызывает search_knowledge(query, k=N) и получает обратно ranked- chunks с метаданными. Embeddings вычисляются offline ONNX-bundled BGE-моделью по умолчанию (fast-bge-small-zh-v1.5); вы можете swap'нуть hosted-embedder (OpenAI, Zhipu, GLM…) через Settings.

См. возможность база знаний.

Собираем вместе

Типичная operational-петля:

text

  edge ─▶ telemetry ─▶ alert rule ─▶ alert event ─▶ incident
                                                       │
                                              ┌────────┴────────┐
                                              ▼                 ▼
                                       investigation        channel
                                       (agent + skills)     (Slack / TG /
                                              │              IM …)
                                              ▼
                                       investigation
                                       report

Edge отгружает телеметрию.
Alert rule оценивает её и производит alert-event.
Event группируется в incident (или прикрепляется к открытому одному).
Incident маршрутизируется в каналы для уведомления.
Investigation автоматически запускается (или operator-triggered); агент использует скиллы и базу знаний, чтобы произвести отчёт.
Persona решает голос + tool-палитру, с которой расследование запускается.

Весь конвейер observable: каждый шаг появляется в timeline UI, каждый skill-вызов в audit-логе, каждый token spend в LLM budget-панели.

Концепции ​

Edge ​

Device ​

Alert rule ​

Incident ​

Investigation ​

Channel ​

IM channel (двусторонний) ​

Persona / agent ​

Skill ​

База знаний ​

Собираем вместе ​