Handling High Cardinality in Metrics Due to Dynamic Path Parameters in OkHttp Requests

[huangtao730]

Have you ever encountered issues with path parameters? For example, when using a tool like OkHttp (Spring MVC doesn’t have this problem because it can recognize @PathVariable), it sends a large number of requests for downloading files, with URLs like this:
http://xxx/down/load/filename1, http://xxx/down/load/filename2, http://xxx/down/load/filename3, http://xxx/down/load/filename4, and so on—many request URLs where only the filename differs.

Clearly, these are all requests to the same endpoint, but OkHttp doesn’t seem to recognize this pattern. As a result, when metrics are reported to the server, it leads to high cardinality data. Ideally, the database could store just one entry for this endpoint, but now each URL requires its own entry, which leads to terrifying storage consumption.

Do you have any suggestions for handling this? For example, using AI to identify such patterns? Have you considered any approaches?

[laurit]

As a result, when metrics are reported to the server, it leads to high cardinality data.

By default http client metrics don't include the url precisely because it has a hight cardinality. There is an experimental (disabled by default) url.template attribute. Since okhttp does not have a concept of url templates enabling it doesn't do anything automatically. Have a look at #15217 You need to either write an extension that turns full ulrls into templates or use declarative config.

[MILLERMARRU]

To add a concrete solution to what @laurit mentioned about url.template:

The reliable approach for OkHttp is to set the url.template attribute via a custom OkHttp interceptor before the auto-instrumented span is created:

OkHttpClient client = new OkHttpClient.Builder()
    .addInterceptor(chain -> {
        Request original = chain.request();
        // Tag the request with the template BEFORE the span is created
        Request tagged = original.newBuilder()
            .tag(String.class, "/down/load/{filename}") // your template
            .build();
        return chain.proceed(tagged);
    })
    .build();

Then register a custom HttpClientAttributesExtractor that reads the tag:

OkHttpTelemetry.builder(openTelemetry)
    .addAttributesExtractor(
        HttpClientAttributesExtractor.builder(/* ... */)
            .build()
    )
    .build();

Simpler alternative — use a SpanNameExtractor:

OkHttpTelemetry telemetry = OkHttpTelemetry.builder(openTelemetry)
    .setSpanNameExtractor(request -> {
        // Normalize dynamic segments
        return request.url().encodedPath()
            .replaceAll("/down/load/[^/]+", "/down/load/{filename}");
    })
    .build();

This collapses all /down/load/fileX URLs into a single /down/load/{filename} span name, which directly fixes the cardinality issue in both traces and metrics (since the HTTP metrics use the span name as the http.route dimension).

For metrics specifically, you can also use the View API to drop the url.full attribute from the http.client.request.duration instrument, keeping only the normalized http.route.