High-cardinality HTTP span names

[BarryThePenguin]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.17.1
      npm: 9.8.1
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.12
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: standalone

Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link), Standalone mode (output: "standalone")

Link to the code that reproduces this issue or a replay of the bug

https://github.com/BarryThePenguin/nextjs-otel-high-cardinality

To Reproduce

• Run the OpenTelemetry Collector docker-compose up -d (copied from https://github.com/vercel/opentelemetry-collector-dev-setup)
• Build and run the reproduction with npm run start:otel-verbose (copied from https://github.com/vercel/next.js/tree/canary/examples/with-opentelemetry)
• Visit a dynamic route - both the app router and pages route have the same issue
• View the collected spans
  Jaeger at http://0.0.0.0:16686/
  Zipkin at http://0.0.0.0:9411/
  Prometheus at http://0.0.0.0:9090/

Describe the Bug

Operations collected include dynamic segments values, which makes grouping similar spans impossible

The issue is similar to this topic open-telemetry/opentelemetry-js#897

This is what we see in Jaeger

Note that the operation select input incudes GET /legacy/vercel/next.js

Expected Behavior

According to the linked OpenTelemetry issue, I'd expect to see the operation name to be GET /legacy/[...repoName], or something similar

Names are not meant to uniquely identify a trace, but a class of traces. for instance, GET /user/:id is a good name, but GET /user/123 is bad because you can't easily search for all traces for the same route.

It's also pointed out in the linked issue that the spec mentions

Instrumentation MUST NOT default to using URI path as span name, but MAY provide hooks to allow custom logic to override the default span name.
https://opentelemetry.io/docs/specs/otel/trace/semantic_conventions/http/

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

output standalone + k8s

[Leonils]

I think the PR #47392 aims to provide such behavior by adding an http.route attribute that hold the route with the placeholders. However, I dont think it is quite reliable for now : at initial load, I get it, but afterward, when the navigation became client-side, we get nothing:

Initial render spans

{
  traceId: '1299cf43de56951edb90622e6b0bf4dd',
  parentId: 'f0ccabef43ed98e4',
  traceState: undefined,
  name: 'render route (app) /app/workspaces/[workspaceId]',
  id: 'a2dfc6241bbf29a4',
  kind: 0,
  timestamp: 1701023838294000,
  duration: 386982.692,
  attributes: {
    'next.span_name': 'render route (app) /app/workspaces/[workspaceId]',
    'next.span_type': 'AppRender.getBodyResult',
    'next.route': '/app/workspaces/[workspaceId]'
  },
  status: { code: 0 },
  events: [],
  links: []
}
{
  traceId: '1299cf43de56951edb90622e6b0bf4dd',
  parentId: undefined,
  traceState: undefined,
  name: 'GET /app/workspaces/[workspaceId]',
  id: 'f0ccabef43ed98e4',
  kind: 1,
  timestamp: 1701023838285000,
  duration: 494503.495,
  attributes: {
    'next.span_name': 'GET /app/workspaces/[workspaceId]',
    'next.span_type': 'BaseServer.handleRequest',
    'http.method': 'GET',
    'http.target': '/app/workspaces/7',
    'http.status_code': 200,
    'next.route': '/app/workspaces/[workspaceId]',
    'http.route': '/app/workspaces/[workspaceId]'
  },
  status: { code: 0 },
  events: [],
  links: []
}

Navigation to another page, and back using next link (client side)

{
  traceId: '693c60f034c5d6783d66d0c101e9fa10',
  parentId: undefined,
  traceState: undefined,
  name: 'GET /app/workspaces/7?_rsc=hn5g2',
  id: '70a6f68e61f7c1de',
  kind: 1,
  timestamp: 1701023973357000,
  duration: 146669.208,
  attributes: {
    'next.span_name': 'GET /app/workspaces/7?_rsc=hn5g2',
    'next.span_type': 'BaseServer.handleRequest',
    'http.method': 'GET',
    'http.target': '/app/workspaces/7?_rsc=hn5g2',
    'http.status_code': 200
  },
  status: { code: 0 },
  events: [],
  links: []
}

In my opinion, the http.route should be in both traces