Croway opened a new pull request, #1933: URL: https://github.com/apache/camel-spring-boot/pull/1933
Fixes [CAMEL-24505](https://issues.apache.org/jira/browse/CAMEL-24505). ## What `MicrometerTagsAutoConfiguration` contributes the `uri` low cardinality tag of the `http.server.requests` metrics. When the request did not resolve to a Camel HTTP consumer — any 404, any request served by something other than the Camel servlet — the tag was `request.getServletPath() + getPathInfo()` verbatim. Micrometer registers one meter per distinct tag value and keeps it for the lifetime of the process, so the number of meters followed the number of distinct paths clients had requested rather than the number of routes, and the memory used by the registry grew with the traffic a deployment received. `CamelMetricsConfiguration`'s own javadoc for `uriTagEnabled` already states that an unresolved request "will be marked as UNKNOWN", so the code contradicted the documented behaviour. ## Changes - Requests that do not resolve to a Camel consumer no longer contribute a `uri` key value. The value computed by Spring's own `DefaultServerRequestObservationConvention` stands instead: the mapped pattern for a Spring MVC endpoint, and a constant (`UNKNOWN`, `NOT_FOUND`, `REDIRECTION`) otherwise. This keeps the tag bounded and, unlike hard-coding `UNKNOWN` here, does not throw away the pattern of the Spring MVC and actuator endpoints of the same application. - Requests that do resolve to a Camel consumer are unchanged: the tag is the static consumer path, such as `/users/{id}`. - `camel.metrics.uri-tag-dynamic = true` still tags with the requested path (`/camel/users/123`), which is the documented purpose of the option, but only for requests that resolve to a Camel consumer. The consumer is now resolved in that mode too, and the value is capped at 200 characters and stripped of control characters so a single tag value stays bounded in size. - The auto-configuration was conditional on `camel.metrics.uriTagEnabled`. Spring Boot cannot resolve that camelCase name from a relaxed binding source, so `camel.metrics.uri-tag-enabled = true` — the name listed in the starter documentation — never enabled the uri tag at all. The condition now uses the kebab-case name; both spellings work, since the kebab-case name does resolve through relaxed binding. ## Behaviour change - Applications configured with `camel.metrics.uri-tag-enabled = true` (kebab-case) now get the Camel uri tag where before the auto-configuration silently did not apply. - The `uri` tag of requests that are not served by a Camel consumer is the Spring value instead of the raw requested path. Dashboards and alerts matching on those raw paths need to use the Spring value. An upgrade guide entry for the `camel-spring-boot` section of the Camel 4.23 upgrade guide will be proposed separately in `apache/camel`. ## Tests New tests in `components-starter/camel-micrometer-starter/src/test` (the starter had none), booting the starter with `camel-servlet-starter` on a random port and asserting on the `http.server.requests` meters: - `MicrometerUriTagTest` — 10 requests to 10 distinct unmatched paths produce a single meter, and no meter carries a requested path; a matched `servlet:/users/{id}` route yields `uri=/users/{id}`. - `MicrometerUriTagDynamicTest` — same cardinality assertion with `uriTagDynamic = true`, plus the requested path being used for matched requests and a 300 character path being capped. This class configures the properties in the legacy camelCase spelling, so both spellings stay covered. `mvn install -pl components-starter/camel-micrometer-starter` → `Tests run: 5, Failures: 0, Errors: 0`. Both cardinality assertions fail against the previous logic (10 meters for 10 unmatched paths), verified by running the new tests against it. The regenerated `src/main/docs/micrometer.json` and `docs/spring-boot/.../starters/micrometer.adoc` are included. _Claude Code (Opus 5) on behalf of Federico Mariani_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018uGVoZ1upWLheUxbE4XfVy -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
