面向智能體監控的本體驅動可觀測性

Traditional observability tells us what is happening in our systems. Ontology-driven observability helps us understand how system components are connected — and gives AI agents better context to investigate incidents.

1. What Is Ontology-Driven Observability?

It starts with a shared model of the system: its services, databases, users, infrastructure, and their relationships.

Instead of treating metrics, logs, and traces as isolated signals, telemetry is connected to a knowledge graph.

For example:

checkout-service → depends_on → payments-db
checkout-service → runs_on → node-01

Each statement is a triple: Subject → Predicate → Object.

The result is a connected view of the system that supports dependency analysis, impact assessment, and root-cause investigation.

2. Use Case Without LLMs or AI Agents

Ontology-driven observability is useful even without AI.

Consider a payments database that becomes unavailable.

A graph-based monitoring system can:

• Identify services that depend on the database.
• Calculate the potential blast radius of the failure.
• Apply predefined rules to correlate the incident with service health.
• Alert the responsible teams with dependency context.

This is deterministic, rule-based monitoring. The knowledge graph provides context, while predefined queries and rules perform the analysis.

3. Use Case for Agentic Monitoring

Now introduce an LLM-powered agent.

When checkout latency increases, a monitoring agent can query the knowledge graph to identify affected services and their dependencies. It can then investigate relevant metrics, logs, traces, and deployment events.

A multi-agent workflow could delegate these investigations to specialized agents and combine their findings into an evidence-backed root-cause hypothesis.

The workflow becomes:

Detect → Explore dependencies → Investigate telemetry → Correlate evidence → Recommend action

This approach aligns with Netflix's E2EGraph initiative, presented at QCon London 2026, which explores knowledge-graph-backed observability and agent-assisted root-cause analysis at scale.

Importantly, the graph provides structured context; it does not automatically prove causation. Agents must still validate their hypotheses against actual telemetry.

4. Should We Prefer This Approach?

It depends on system complexity.

Ontology-driven observability is particularly valuable when:

• Incidents cross multiple services, infrastructure layers, and teams.
• Telemetry is scattered across different tools.
• Root-cause analysis requires understanding complex dependencies.
• AI agents need reliable, structured context rather than relying on raw logs alone.

For smaller systems, conventional observability with consistent instrumentation, useful tags, and distributed tracing may be sufficient. OpenTelemetry Semantic Conventions provide a practical starting point.

A complete knowledge graph introduces additional costs: ontology design, data integration, graph maintenance, and governance.

5. Should Agentic Monitoring Run in a Sandbox?

Develop and test it in a sandbox or staging environment first.

However, the knowledge graph and observability pipeline do not inherently need to run in a sandbox. The critical security concern is the agent's execution environment and permissions.

A practical rollout strategy is:

1. Sandbox: Test incident scenarios, graph queries, agent reasoning, and tool calls using synthetic or sanitized telemetry.
2. Production read-only mode: Allow agents to query approved production telemetry and propose explanations without changing the system.
3. Controlled remediation: Introduce actions such as restarting services or rolling back deployments only with strict permissions, independent validation, and human approval where appropriate.

Sandboxing and least-privilege access help limit the consequences of incorrect reasoning or unintended tool calls. For further guidance, see OpenAI's documentation on agent guardrails and human review.

Final Thoughts

Ontology-driven observability is not a replacement for traditional monitoring. It is a way to add shared context and connected system knowledge to it.

Rules can use the graph to perform deterministic analysis. LLM-powered agents can use the same graph to investigate incidents dynamically and coordinate more complex workflows.

The strongest starting point is simple: establish reliable telemetry and system relationships first, then introduce agentic analysis where it provides measurable value.