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.