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:

  1. The microservice (instrumented with OpenTelemetry) emits trace spans to a telemetry collector — typically an OTel Collector or directly to a backend that speaks OTLP.

  2. 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.

  3. 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.

Where to next

Last updated