Static Asset Tracing

Problem

Your server creates a trace every time a browser downloads a static file: scripts, stylesheets, images, fonts. These requests are numerous, nearly identical, and almost never fail in ways a trace would explain, so the spans add volume without adding understanding.

Insights matches span URLs against known static extensions (.js, .css, .png, .woff2, and the rest of the family) and flags services tracing them.

Impact

• A single page load can generate dozens of traces that will never be read.
• Static asset spans crowd trace search results and sampling budgets.
• You pay application-tracing prices for what a CDN log would tell you better.

Example

Traced per download:

GET /assets/app.min.js      → trace 88f2… (1 span)
GET /assets/styles.css      → trace 91ab… (1 span)
GET /assets/logo.png        → trace 03cd… (1 span)
... every asset, every visitor

Filtered:

GET /api/checkout → traced (the request you'd actually debug)
# static assets: request counts and latency come from
# server metrics or CDN logs

How to fix

1. Exclude static paths from tracing at the instrumentation layer; most HTTP libraries accept a URL filter or ignore list.
2. Or drop the spans in a Collector filter processor matching the asset extensions.
3. If you need visibility on assets, use metrics (request count, latency histogram) or serve them from a CDN with its own logging.

Expected gains

Trace volume drops immediately, sampling and search focus on requests with business logic, and asset delivery stays observable through cheaper signals.

See the Insights catalog for everything Insights can detect.