Concepts

See what a service calls.

A downstream database, cache or service becomes observable when your instrumentation records the call. Shared trace context connects the work across process boundaries.

OpenTelemetry-nativeChecked 28 Oct 2026

On this page

Record the dependency at its source

Instrument both incoming requests and outgoing HTTP, database, cache or messaging operations. Client spans describe calls your service makes. Server spans describe the receiving side when you control and instrument it too.

Useful attributes include peer.service, server.address, db.system or db.system.name, depending on the library and convention version. These are examples, not fields Lantern adds automatically. Discover your actual attributes with list_fields or Query.

A Collector forwards and processes received telemetry. It does not automatically add application-level database spans just because traffic passes through it.

Carry context across HTTP

The sender’s instrumentation injects trace context into outgoing HTTP headers. The receiver extracts it before creating its server span. OpenTelemetry commonly uses W3C traceparent and, when needed, tracestate.

HTTP · illustrative trace context

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

The fields encode the version, trace ID, current parent span ID and trace flags. The receiving server creates a new span ID in the same trace and uses the incoming span ID as its parent. Instrumentation should generate and propagate these values; do not hard-code this example into requests.

Use the matching client and server instrumentation, preserve context through asynchronous work and ensure proxies keep the intended headers. For queues or fan-out, use your messaging instrumentation’s context and span-link conventions. OpenTelemetry propagation guide →

Trace headers carry correlation context. They do not grant access to Lantern and must never contain ingestion or read tokens.

Investigate a downstream slowdown

Select one service and a precise time window. Discover the exported fields before choosing filters.
Open the Dependencies board for database and peer attributes. Its current built-in panels use db.system and peer.service; if your SDK exports other keys, use Query to group by those actual fields.
Compare observed call counts, error status and duration percentiles by dependency or operation. Confirm that you are comparing the same span kind and operation.
Open representative slow and normal traces. Follow their parent links and inspect the original client/server evidence.
Correlate with the downstream system’s exported metrics and logs, then propose the next check.

MCP · query_spans argument example

{
  "from": "2026-10-28T12:00:00Z",
  "to": "2026-10-28T12:15:00Z",
  "where": [
    {"field": "service", "op": "==", "value": "checkout-api"},
    {"field": "db.system", "op": "exists"}
  ],
  "group_by": "db.system",
  "group_limit": 10
}

Replace these example timestamps, service and attribute with a recent window and values observed in your workspace. The current public retention window is seven days.

query_spans returns observed counts, errors and duration summaries. It is a read-only query. The example does not alter your application, database or deployment.

When a dependency or parent is missing

What you see	What to check
Only a client span	The remote system may not export server spans, may use a different destination, or may be sampled independently.
Separate traces for one call	Check outgoing injection, incoming extraction, async context and proxy header handling.
Empty Dependencies panels	Check whether instrumentation exports the panel’s expected `db.system` or `peer.service` keys. Use discovered alternatives in Query.
An orphan span	Expand the window within retention; inspect sampling, exporter health and delayed or missing parent delivery.
No dependency spans	Check that the database or HTTP client library is instrumented and its spans reach the selected export pipeline.

Keep conclusions proportional to evidence

Dependency analysis describes recorded calls and their timing. It is not a complete inventory of network traffic, installed software packages or infrastructure topology. Client and server spans can count the same logical call twice.

A slow database span and high pod memory in the same window can suggest a follow-up investigation. They do not prove that the span allocated that memory or that a leak exists. Profile the relevant process, inspect trends across repeated workloads and test the hypothesis before changing anything.

Use MCP for read-only investigation to collect evidence and suggested next steps. Operational changes remain a separate, reviewed action.