> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/features/data-lineage/microservices.md).

# Microservices 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](/features/data-lineage/data-objects.md), with microservice nodes participating alongside datasets, transformers, and the rest of the entity model.

![](/files/wNMRVUypwpxCem0NVwSz)

## 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`](/integrations/integrations/odd-tracing-gateway.md) — the platform's only [standalone gateway](/introduction/main-concepts.md#the-architecture-chain) 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](/introduction/main-concepts.md#odd-specification).
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](/introduction/main-concepts.md#the-architecture-chain) 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.

{% hint style="warning" %}
**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](/configuration-and-deployment/enable-security/authorization.md) 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.
{% endhint %}

## 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](/features/data-lineage/data-objects.md) — the catalog-side lineage surface that microservice nodes render alongside.
* [`odd-tracing-gateway`](/integrations/integrations/odd-tracing-gateway.md) — the standalone gateway that turns OpenTelemetry traces into ODD microservice entities.
* [Architecture](/introduction/architecture.md) — the platform-wide data-flow diagram, including the gateway's position in the producer-side topology.
* [Main Concepts → The architecture chain](/introduction/main-concepts.md#the-architecture-chain) — where standalone-gateway push adapters sit among the producer-side concepts.
* [API Reference → Lineage](/developer-guides/api-reference/lineage.md) — 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.