Ontology-Driven Observability at Netflix Scale: Building a Knowledge Graph for Faster Incident Resolution

At Netflix's scale, with billions of requests and millions of real-time logging events per second, diagnosing application regressions is a major challenge. The article highlights that an issue on the home screen could originate anywhere from client-side deployments to deeply nested backend service rollouts. Traditional MELT (Metrics, Events, Logs, Traces) data, while crucial, often exists in isolated systems (e.g., Atlas for metrics, Spinnaker for deployments, incident.io for incidents) and lacks a unified, machine-readable understanding of how these different entities relate. This fragmentation leads to lengthy, human-intensive investigations, where tribal knowledge is critical but also a bottleneck.

The Observability Data Modeling Problem

The core problem identified is a data modeling challenge rather than a lack of data. Different operational tools often refer to the same logical entity (like an application or service) by different names, with varying conventions or partial information. This semantic gap prevents automated correlation and requires engineers to manually reconstruct relationships, turning investigations into a "needle in a haystack" problem. The proposed solution is an explicit, machine-readable agreement about operational entities – an ontology.

Leveraging an Ontology and Knowledge Graph

Netflix built the "Observability Ontology," a formal specification of types, properties, and relationships using W3C standards like RDF for the data model, OWL for the ontology, SHACL for validation, and SPARQL for querying. This ontology acts as a schema and rule set, standardizing how entities (applications, services, incidents, deployments) are understood across various systems. The data is stored as a knowledge graph in QuipuDB, Netflix's homegrown distributed RDF graph database.

The Knowledge Flywheel and Deterministic Enrichment Pipeline

The system processes raw telemetry, logs, and even incident discussions (parsed by LLMs) into triples through an enrichment pipeline. This pipeline reduces entropy by progressively constraining stochastic inputs (e.g., LLM summaries, fuzzy matching) into deterministic, typed triples that conform to the ontology. The pipeline has five layers, with dozens of "enrichers" that read noisy input and emit validated triples. The sequential execution of enrichers prevents race conditions and ensures a consistent graph state. This iterative process forms a "Knowledge Flywheel" that continuously enriches the system's context.

Correlation Engine

A key component is the Correlation Engine, which assimilates signals from thirteen diverse input types (log errors, metric anomalies, deployments, incidents, etc.) and condenses them into causal or correlational chains of events. It scores these chains based on temporal proximity and severity, providing strong hypotheses (e.g., "0.87 confidence chain") for humans or AI agents to investigate, complete with supporting evidence. This moves beyond simple alerts to provide actionable context for root cause analysis.