Unlocking System Insights with Graph Queries in Cloud‑Native Observability

In modern cloud‑native architectures, each component—service, pod, middleware, or infrastructure—is traditionally monitored as an isolated entity, which makes it difficult to answer relationship‑centric questions such as "Which downstream services are affected by a failure?". The article proposes treating the entire system as a dynamic graph, where entities are nodes and their interactions are edges, and storing this information in an EntityStore that maintains both entity data ( __entity__) and topology data ( __topo__).

Core Solution: Graph‑Based Observability

The solution introduces three query capabilities:

graph‑match : an intuitive, path‑oriented query language that lets users describe a traversal starting from a known entity ID and retrieve matching sub‑graphs.

graph‑call : a set of function‑style APIs (e.g., getNeighborNodes, getDirectRelations) that encapsulate common graph operations with parameters for direction, depth, and node list.

Cypher : the industry‑standard declarative graph query language, offering the most expressive power for multi‑hop patterns, property filters, and path returns.

Graph Model Basics

Nodes are identified by a label domain@entity_type (e.g., [email protected]) and carry built‑in properties such as __entity_id__, __domain__, and __entity_type__, plus any custom attributes defined by the user. Edges have a type (e.g., calls, contains) and may also store attributes.

Syntax Highlights

Node syntax: (label {key: value}). Edge syntax: [type {key: value}]. A basic path looks like (A)-[e]->(B). Multi‑hop ranges use the [*min..max] notation, which is left‑closed and right‑open (e.g., [*2..4] matches 2‑ and 3‑hop paths).

Practical Query Examples

1. Simple Node Retrieval

.topo | graph-call cypher(`
  MATCH (n {__entity_type__: "apm.service"})
  WHERE n.__domain__ STARTS WITH 'a'
  RETURN n
`)

2. Service Call Chain (graph‑match)

.topo | graph-match (s:"[email protected]" {__entity_id__: '12345'})-[e:calls]->(d)
project s, e, d

3. Multi‑Hop Impact Analysis (Cypher)

.topo | graph-call cypher(`
  MATCH (failed:``[email protected]`` {status: 'error'})
  -[impact:depends_on*1..3]->(affected)
  RETURN failed.service, length(impact) AS depth, affected.service
  ORDER BY depth ASC
`)

4. Neighbor Enumeration (graph‑call)

.topo | graph-call getNeighborNodes('full', 2, [(:"[email protected]" {__entity_id__: 'abc'})])
| stats cnt=count(1) by relationType

Performance and Best Practices

Use label indexes (e.g., (n:``[email protected]``)) to avoid full scans.

Apply early WHERE filters on node properties to reduce traversal size.

Limit depth with left‑closed ranges ( *1..3) and keep hops ≤ 5 for acceptable latency.

Prefer graph‑call for simple neighbor queries; reserve Cypher for complex property filters and path returns.

When entity data is missing, use the pure‑topo mode to query only topology, sacrificing attribute filters but gaining speed.

Data Completeness Considerations

The full power of Cypher requires three data sources to be complete: the model (UModel), the entity store, and the topology graph. If any are missing, queries fall back to pure‑topo or become impossible. The article outlines strategies for detecting missing data and choosing the appropriate query mode.

FAQ Highlights

Edge types that clash with Cypher keywords : wrap the type in double back‑ticks (e.g., [``contains``]) and then double‑back‑tick the whole pattern for SPL compatibility.

Multi‑hop syntax : *2..4 matches 2‑ and 3‑hop paths; *1..3 matches 1‑ and 2‑hop paths.

Unsupported shorthand : In pure‑topo mode, edge types must be omitted or explicitly written as []; shortcuts like (s)-->(d) are not allowed.

Overall, the article demonstrates how graph queries turn a flat collection of metrics into a richly connected digital twin, empowering engineers to perform deep fault isolation, architecture compliance checks, and security audits with concise, high‑performance queries.