Open cedricziel opened 3 weeks ago
I believe we're encountering a similar issue. After playing around with the sample app in this repo, I'm finding that this issue of high cardinality operations may be particular to NextJS 13.
In the sample app I downgraded to Next ^13, set up some example routes in the pages
router, and created some <Link>
components to obtain some operations from NextJS client side app rendering. I have the vercel/opentelemetry-collector-dev-setup running and am looking at Jaeger to see how the instrumentation works for the sample app. I've pushed my app changes here: https://github.com/glifchits/otel/pull/1 (to recap, only src/pages
and package.json
are net new)
When the app is using Next 14, the operations are grouped under the expected route pages-router/[slug]
and pages-router
but when the app is using Next 13, I'm seeing operations including _next/data
.
Next 13 | Next 14 |
---|---|
What
This package uses span names such as
GET /_next/static/webpack/4330e83422f91a86.webpack.hot-update.json
OpenTelemetry explicitly specifies this here:
Why
Any downstream consumer that generates metrics from traces will experience a metrics spike if the span names are high-cardinality. This is, as metric generators use the
span.name
and transform it into a label on the metric.This is a severe issue and potentially has massive cost implications for many users
Suggested solution
It is common practice in the Otel instrumentation libraries to work with placeholders and templatized URLs.
Examples for next.js:
A templated route with parameters:
A common practice is for instrumentations to collect a
http.route
attribute and on span end, update the span name with the contents ofhttp.route
, if set. Documentation