logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·29.10.26
← Back to news

Ontology-Driven Observability: Building an End-to-End Knowledge Graph at Netflix

Original article
netflixtechblog.com|89 points|19 comments|by tosh|Oct 19, 2026

Ontology-Driven Observability: Building an End-to-End Knowledge Graph at Netflix

At the scale of Netflix, managing the health of thousands of microservices is not just a technical challenge—it is a cognitive one. Traditional monitoring tells you that something is broken, but it rarely tells you why in the context of a massive, shifting ecosystem. To solve this, Netflix shifted toward Ontology-Driven Observability, leveraging a comprehensive Knowledge Graph to unify fragmented telemetry.

The Observability Gap

For years, the industry has relied on the "three pillars" of observability:

  1. Metrics (Time-series data)
  2. Logging (Event streams)
  3. Tracing (Request flows)

While powerful, these pillars often exist in silos. A developer might see a spike in latency in a metric dashboard, find a corresponding error in the logs, and then manually hunt through traces to find the culprit. This process is manual and slow inefficient and error-prone.

"The missing link in modern observability is not more data, but the context that connects that data."

Defining the Ontology

An Ontology is a formal way of representing categories, properties, and relationships between concepts. In the context of Netflix's infrastructure, the ontology defines what an "entity" is and how it interacts with others.

The Mathematical Foundation

We can represent the system ontology as a tuple: O=(C,R,I)O = (C, R, I)O=(C,R,I) Where:

  • CCC is the set of Classes (e.g., Service, Cluster, Region, Instance).
  • RRR is the set of Relationships (e.g., depends_on, runs_on, deployed_in).
  • III is the set of Individuals (the actual unique instances of those classes).

Entity Hierarchy

The system is organized into a strict hierarchy to ensure data consistency:

  • Global →\rightarrow→ Region →\rightarrow→ Cluster →\rightarrow→ Service →\rightarrow→ Instance

Architecture of the Knowledge Graph

The Knowledge Graph transforms the static ontology into a living map of the environment. It ingests data from various sources (CMDBs, service discovery, deployment pipelines) to maintain a real-time state of the world.

Data Flow Pipeline

The following diagram illustrates how raw telemetry is enriched by the ontology to produce actionable insights:

Comparison: Traditional vs. Ontology-Driven

FeatureTraditional ObservabilityOntology-Driven Observability
Data StructureTabular / Time-seriesGraph-based / Relational
ContextManual correlationAutomated semantic linking
Dependency MapStatic or Trace-derivedDynamic & Ontology-aware
Query StyleSELECT * WHERE metric > XFIND services IMPACTED BY cluster_failure

Implementation in Practice

To make this operational, Netflix utilizes a graph-based querying system. Instead of searching for a specific instance_id, an engineer can query the relationship between entities.

Example: Graph Query Logic

If a specific hardware rack fails, the system doesn't just alert on "Server Down." It traverses the graph: Rack →\rightarrow→ contains →\rightarrow→ Host →\rightarrow→ runs →\rightarrow→ Service Instance →\rightarrow→ belongs to →\rightarrow→ Critical Business Path.

Below is a conceptual representation of how a service relationship might be stored in a JSON-LD format:

{
  "@context": "https://netflix.com/ontology",
  "@id": "service:playback-api",
  "type": "Microservice",
  "deployedIn": "region:us-west-2",
  "dependsOn": [
    {
      "@id": "service:auth-provider",
      "relationship": "hard_dependency"
    },
    {
      "@id": "service:recommendation-engine",
      "relationship": "soft_dependency"
    }
  ],
  "healthScore": 0.98
}

Key Benefits and Outcomes

The transition to a knowledge-graph approach yielded several critical improvements:

  • Accelerated Root Cause Analysis (RCA): By visualizing the "blast radius" of a failure, engineers can ignore irrelevant alerts and focus on the source.
  • Automated Dependency Mapping: No more outdated Excel sheets or manual diagrams; the graph is the source of truth.
  • Intelligent Alerting: Alerts are now suppressed if the underlying dependency is already known to be failing (reducing alert fatigue).

Deployment Checklist

To implement a similar system, the following milestones are required:

  • Define a core set of entities (The Ontology).
  • Build a pipeline to ingest metadata from service discovery.
  • Implement a graph database (e.g., JanusGraph or Neo4j) for storage.
  • Integrate graph queries into the primary alerting dashboard.
  • Automate "blast radius" calculations for all production changes.

Conclusion

By moving from a "siloed telemetry" model to an Ontology-Driven model, Netflix has effectively turned its infrastructure into a searchable database. This allows the organization to move beyond simple monitoring and toward true observability—where the system can explain its own state and the relationships that govern its behavior.