What can you do with OpenTelemetry entity events?

Fern Okay, this actually hits a real observability pain. You can have gorgeous traces and still not know what exists right now, or what changed an hour ago.

Lintel Yeah.

Lintel And that's not a fake gap. Metrics and logs tell you behavior. They do not give you a durable, time-aware inventory unless you build one on top.

Fern Which is why this is such an Exploring Next thing to talk about on a Friday. The boring layer turns out to be the useful one. Again.

Lintel Annoyingly, yes.

Fern My week's been weirdly good, by the way. I got that rare feeling of, oh, the infrastructure post is actually about a user problem and not just a new acronym.

Lintel That is your favorite genre. You see one plausible workflow and suddenly the stack has market fit.

Fern Stop it. That's fair, but also you see one unstable field name and act like the whole thing belongs in a locked drawer.

Lintel Okay, that's good.

Lintel In this case the instability caveat is real, though. The blog is pretty explicit that the entity data model is still developing, so the exact attributes are illustrative. But the shape is solid: entity events come through as O T L P log records with fields for event type, entity type, immutable ID, and descriptive attributes.

Fern Right.

Lintel Then the consumer's job is not to keep one neat table current. It's to ingest the stream and turn it into something queryable over time.

Fern And that user story I see is pretty clean. If you're already on OpenTelemetry, this gives you a way to answer, what machines or services were actually there, how were they connected, and what changed, without bolting on some proprietary inventory sidecar.

Lintel Mm-hm.

Fern That upgrade path matters. The producer side stays generic. Host agents, network agents, cloud APIs emit entity events, and the consumer just speaks the standard.

Lintel The architecture choice I like is event sourcing. Append every entity event to an ordered durable log, and treat that as the system of record. Current state is just a projection, so if your graph gets weird you replay from history instead of praying the mutable table wasn't lying to you.

Fern Exactly.

Lintel That lines up with our old receipts obsession. If the work matters, keep the record. Same thesis, different object.

Fern And the bi-temporal bit is the part teams usually skip until they regret it. You keep event time from the log record, then stamp recorded time at ingest yourself, so later you can ask both what reality looked like and what you knew at nine A M during the incident.

Lintel Oh interesting.

Fern That is so much more useful than a static C M D B that gets lovingly updated right after everything is already on fire.

Lintel You're kidding. The sacred spreadsheet of truth, defeated by time.

Fern Okay, wow.

Lintel Identity is where this can still go badly. The post is very hardline, and I think correctly so: match IDs exactly. If you stick a leased I P into identity, a D H C P change creates a fake new entity. If you're too tolerant, two real databases that differ only by port quietly collapse into one, and that's worse.

Fern Right, right.

Lintel They even use process identity as the model case. P I D alone gets reused, so pair it with creation time. Stable for that process lifetime, changing facts stay descriptive.

Fern The fun part, though, is once relationships are in there. Since v one point fifty-eight, the spec lets an entity state event carry an entity dot relationships array, so a service instance can say it depends on another service instance right inside its state.

Lintel Sure.

Fern Then removing an edge is just re-emitting state without that descriptor. That's nice. No separate edge protocol, no weird side channel.

Lintel And that makes the graph actually useful instead of decorative. Because the same entities are attached on the Resource side of your telemetry, the graph becomes the join key across metrics, logs, and traces. Scope the slice you care about, correlate by entity identity, then follow depends_on or runs_on edges to chase blast radius.

Fern Yeah.

Fern Also, the GraphQL plus M C P combo is the most twenty twenty-six sentence imaginable. But I buy it here. GraphQL for dashboards and tools, M C P so an assistant can introspect typed schema and ask for entity history or recent changes without dashboard pinball.

Lintel Fern, that's the rare M C P mention where I'm not immediately rolling my eyes. Because it's grounded in a real source of truth, not vibes with extra invoices attached.

Fern There it is. You got your little line in.

Lintel I earned it.

Fern Episode eight sixty-four, and we're still finding new ways to say the boring sections are load-bearing. I'll take that.