Observability knowledge graph system design 5 questions in 4 chapters

Designing the graph

Why observability becomes a data-modelling problem, and how an ontology, identity rules and harvests fit together.

1.1 How would you design an observability knowledge graph to speed up incident root-cause analysis? Hard 4 min
I treat it as a data-modelling problem. Each tool knows part of the picture, but they name the same thing differently. So I define an ontology of applications, teams, deployments, alerts and incidents, resolve every name to one catalog-backed identity, and harvest each source into typed facts with provenance. A correlation step proposes ranked chains with evidence, and responders or agents query one graph instead of six tools.
Read the full answer
1.2 How do you model entities and resolve identity across tools that name things differently? Hard 2 min
Identity comes first. I pick one authoritative catalog per entity kind and validate every candidate against it before creating a node, so a scraped string never becomes an application. I avoid vague types like service, give every entity one type and one URI scheme, and keep concepts separate from instances. Popular services get capped dependency edges, so one hub cannot dominate traversals.
Read the full answer

Standards and storage choices, and how to keep LLM and fuzzy-matching output from corrupting the graph.

2.1 Why use RDF, OWL, SHACL and SPARQL rather than a property graph, and how do you query and store it? Hard 4 min
RDF gives a standard fact model, OWL describes the ontology, SHACL validates data against shapes, and SPARQL queries it, including arbitrary-length paths. That makes the model portable across stores. One catch: OWL assumes an open world, so missing facts are unknown, not false, which is why closed validation belongs in SHACL. A property graph is a fine alternative if the team values its tooling more than standards.
Read the full answer
2.2 How do you turn LLM output and fuzzy matching into trustworthy graph facts? Hard 3 min
I narrow the output contract instead of trusting the model. Deterministic extraction runs first, then catalog validation, then API lookups, and only then an LLM whose output must be a fixed enum or a schema-checked JSON object. Each fact is validated, typed and stored with its source and confidence. Running enrichers in order removes races, slow sources only degrade a harvest, and humans approve schema changes.
Read the full answer

Scoring candidate chains from many signal types, and keeping hypotheses honest.

3.1 How would you correlate deploys, alerts, logs and traces into ranked root-cause hypotheses? Hard 4 min
I collect typed, time-stamped signals per entity and search for ordered paths between them, such as commit, deploy, error, alert, incident. Known causal pairs get a strong prior; other links must earn their place through time proximity and severity inside a window, and weak chains are dropped. Each chain is stored with its evidence and confidence, because it is a hypothesis to check, not a conclusion.
Read the full answer