Add parameter to customize status codes mapped as 'NOT_FOUND' in OkHttpMetricsEventListener

[tangcent]

Problem Description

In my project, I frequently request resources via URLs formatted as /resource/{id}. Some resources may not exist or may have expired, resulting in a 404 response. It's crucial for me to monitor the proportion of such invalid (possibly expired) resources. Using the urlMapper functionality of OkHttpMetricsEventListener, I convert these URLs from /resource/xxxxx to a templated form /resource/{id} for consistent metric collection. But the current implementation aggregates all 404 responses under a generic NOT_FOUND tag, which obfuscates the visibility of specific URLs or patterns contributing to these errors.

As discussed in #2410, the OkHttpMetricsEventListener in Micrometer currently handles specific HTTP status codes, such as 404, by mapping them to a NOT_FOUND tag to mitigate tag cardinality issues. However, this behavior is fixed and does not allow for customization based on user-specific needs or different application contexts.

Proposed Solution

Introduce flexibility in the OkHttpMetricsEventListener that enables users to define custom sets of status codes that should be treated as NOT_FOUND. Additionally, provide the option to configure whether to create URI tags for requests resulting in these status codes, which could include or exclude 404 among others.

Benefits

• Customization: Users gain control over how status codes are handled, allowing them to adapt metrics collection to better suit their operational and monitoring needs.

• Reduced Complexity: Provides a way to handle exceptions to general tagging rules without adding significant complexity to the monitoring setup.

• Enhanced Usability: Makes the OkHttpMetricsEventListener more versatile and suitable for a wider range of use cases by accommodating different monitoring strategies.

This change would make the OkHttpMetricsEventListener more adaptable to various monitoring needs, enhancing its overall utility and effectiveness in real-world scenarios.

[shakuzen]

Did you see my comment on the linked issue?

After looking into this a bit, I think it is already possible to configure, since we added the contextSpecificTags in 1.5. See this tag method on the Builder where you can configure a function to overwrite the uri tag.

Would that not be sufficient for your use case and customizing this behavior?