Skip to content

More accurately nest spans in tracing #4827

@Fluxx

Description

@Fluxx

Describe the bug

In the spans that the Router generates, it seems there are some pairs of spans which are currently implemented as siblings, but I think might actually be parent/child? For instance, here is a recent trace I pulled that involved our router. The router is configured to export :

image

The green POST spans are our coprocessor. I am wondering, for the red boxes around pairs of spans, should the first span of the pair be the parent of the second span? i.e. should the router span be the parent of its external_plugin span? Or should the supegraph span be the parent of its corresponding external_plugin span?

To Reproduce

  1. Run the route with tracing enabled, using the otlp exporter.
  2. Record a request involving at least one subgraph.

Expected behavior

I would expect for each red pair of spans in the screenshot above, that the first span would be a parent of the second span.

Additional context

We're running router version 1.40.2 with this relevant section of our config file:

    tracing:
      common:
        service_name: graphql
        sampler: always_on
        parent_based_sampler: true
      otlp:
        enabled: true
        endpoint: <internal-collection-endpoint>
        protocol: http
      propagation:
        baggage: true
        trace_context: true

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions