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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opendatadiscovery.org/features/data-lineage/microservices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.