Microservices Lineage
Microservice call lineage — OpenTelemetry traces ingested through odd-tracing-gateway and rendered alongside data-object lineage.
This feature traces the data provenance of microservice-based applications. ODD represents microservices as catalog objects and shows their call graph as a typical lineage diagram — the same UI surface as Data Objects Lineage, with microservice nodes participating alongside datasets, transformers, and the rest of the entity model.
How microservices land in the catalog
Microservice lineage is sourced from OpenTelemetry traces. The path is:
The microservice (instrumented with OpenTelemetry) emits trace spans to a telemetry collector — typically an OTel Collector or directly to a backend that speaks OTLP.
odd-tracing-gateway— the platform's only standalone gateway push adapter today — receives those traces, infers the microservice topology and the calls between services, and emits the corresponding ODD entities (microservice transformers + the call edges between them) into the platform's Ingestion API.The platform stores the inferred entities in the catalog and renders their lineage in the same Lineage tab as data-object lineage.
Operator-mental-model: "push" — microservices push their traces and the gateway forwards. The Platform-side leg is a pull hidden behind the gateway's standalone deployment, which is why odd-tracing-gateway is classified as a standalone-gateway push adapter in the architecture chain.
Where to find it in the UI
Microservices appear in the catalog as MICROSERVICE-class transformer entities. From any microservice detail page, the Lineage tab opens the same graph view used for data-object lineage — call edges between microservices flow alongside dataset / transformer / consumer edges where the platform has visibility into both surfaces.
Access model
Microservice lineage uses the same read-collaborative posture as the rest of the catalog: any authenticated user with read access to the platform's data entities can request the upstream / downstream graph of any catalogued microservice, regardless of which team owns the underlying service. The platform's lineage repository does not perform an ownership-side filter on the read path. And when the platform runs with auth.type=DISABLED, "authenticated user" widens to any unauthenticated client that can reach the network port — the lineage read is then anonymous.
Microservice lineage exposes operational topology that schema lineage does not. A microservice's upstream / downstream graph reveals which services it calls and which services call it — the same kind of dependency-graph that an operator would otherwise need APM access to read. In a multi-team deployment, an SRE on one team can read another team's service-call patterns through this surface; competitor service-call cardinality, inter-team-service coupling, and service-interdependence patterns become visible to every authenticated catalog user — and to anonymous callers if the platform runs with auth.type=DISABLED, since that mode removes the sign-in requirement from every endpoint, this one included. This is the same read-collaborative posture as data-object lineage (see Authorization for the platform-wide model), but the operational sensitivity is higher on microservice lineage because service-call patterns are more topology-revealing than schema-lineage edges. Multi-team operators planning microservice-lineage exposure should plan accordingly — keep the catalog deployment scoped to a single team, restrict who has authenticated access to it, and never run DISABLED on a network reachable by untrusted clients.
Supported payload fields
The lineage response DTO is class-agnostic — every node carries the same shape regardless of whether it is a dataset, transformer, consumer, or microservice. The fields that survive on every node:
Identity (
id,oddrn,externalName,internalName).Class / type discriminators (
entityClasses,dataEntityType).The lineage edges to upstream and downstream neighbours.
Owner / namespace / data-source attribution.
Microservice-specific OpenTelemetry trace fields — operation_name, span_kind, error_rate, p95_latency, callsPerMinute, per-call cardinality, service-call cardinality — are silently dropped at the response-DTO mapper. The lineage endpoint returns the topology (which microservice calls which) but not the per-call metadata an APM consumer would expect. If you ingest those fields through a custom odd-tracing-gateway extension, they live in the platform's database but do not surface on the lineage API today.
Mitigation today. If your operator workflow needs the per-call metadata, query the upstream APM / tracing backend directly — the lineage API is the topology surface. The platform's lineage payload shape is generic across all entity classes; a microservice-specific payload extension is on the roadmap but not shipped.
Where to next
Data Objects Lineage — the catalog-side lineage surface that microservice nodes render alongside.
odd-tracing-gateway— the standalone gateway that turns OpenTelemetry traces into ODD microservice entities.Architecture — the platform-wide data-flow diagram, including the gateway's position in the producer-side topology.
Main Concepts → The architecture chain — where standalone-gateway push adapters sit among the producer-side concepts.
API Reference → Lineage — the same lineage HTTP surface used for both data-object and microservice lineage. Calling it directly? Always pass an explicit
lineage_depth— omitting it returns HTTP 500, not a default-depth graph.
Last updated