Explores what to do with OpenTelemetry's entity events, a new stream of OTLP log records that describe what infrastructure exists (hosts, services, switches) and how it changes over time. The post walks through building a consumer as event-sourced, bi-temporal storage with immutable entity identity, then exposing the resulting temporal graph via GraphQL and an MCP server so both humans and AI assistants can query it. It also covers the newly shipped v1.58.0 spec addition of entity relationships (depends_on, contains, etc.), which lets the entity graph act as a join key across metrics, logs, and traces for correlation and blast-radius analysis during incidents.
Table of contents
A 60-second primer on entity eventsStep 1 — Don’t store state, store the streamStep 2 — Be bi-temporal on purposeStep 3 — Give entities an immutable identityStep 4 — Make it queryableRelationships are now in the specWhy a graph: it joins your other signalsKeep the producer side genericA few operational notesTakeawaysGet involvedQuestions this post answers
What version of the OpenTelemetry specification added entity relationships?
Entity relationships shipped in the OpenTelemetry specification v1.58.0, released June 22, 2026, via specification pull request #4836. Relationships are embedded directly in an entity's state event as an entity.relationships array, each descriptor naming a relationship type (like depends_on or contains) and the target entity's type and id, with direction expressed as source to target. Track OpenTelemetry spec releases like this one on daily.dev before they change how your observability pipeline models topology.
How should I model identity for OpenTelemetry entities to avoid duplicate or merged records?
Entity identity should use only attributes that stay stable for the entity's lifetime, never values that change, like a leased IP address, because that would fork one entity into two on every DHCP renewal. For values that get reused, like a process PID, pair it with a discriminator such as process.creation.time so the combination stays unique across the process's lifetime. Developers designing telemetry pipelines can compare identity-modeling patterns like this on daily.dev.
Why should an OpenTelemetry entity consumer store a stream of events instead of a mutable current-state table?
Storing a mutable table overwrites history, losing the fact that something changed and when. Appending every entity event to a durable, ordered log (event sourcing) keeps the log as the system of record, with current state reconstructed as a projection by replaying it, so both current state and full history remain available and bi-temporal queries stay possible. daily.dev helps engineers building observability infrastructure keep up with event-sourcing patterns like this one.