More Customizable collapse_request_path Setting

[WillyRL]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [X] I have joined the Ory Community Slack.
• [X] I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

In reference to issue #446, the collapse_request_path configuration could be significantly more useful if it were more flexible.

Use Case I have an /api prefix for my service, followed by a unique UUID in the URL path, for example:

/api/conversations/{uuid-v4-conversation-id}/messages

When collapse_request_path is set to false, my metrics become unmanageable because each unique UUID generates a separate metric entry. However, setting it to true collapses everything under the /api prefix, losing valuable details for different endpoints.

Describe your ideal solution

Enable a more advanced configuration for collapse_request_path that allows specifying patterns, placeholders, or partial collapsing so that important segments (like /conversations) are preserved while unique identifiers (UUIDs) are collapsed.

Example Configuration

  collapse_request_paths:
    enabled: true
    rules:
      - pattern: "^/api/conversations/[0-9a-fA-F-]{36}/messages"
        replacement: "/api/conversations/:conversationId/messages"
      - pattern: "^/api/other-service/[0-9a-fA-F-]{36}"
        replacement: "/api/other-service/:resourceId"

Workarounds or alternatives

If the pattern based is too complicated, for the use case that using /api prefix, provide the collapse_level.

  collapse_request_paths:
    enabled: true
    # Define how many path segments to skip from the start
    collapse_level: 1

Version

0.40.6

Additional Context

No response

[aeneasr]

Let me loop in @nipsufn to take a look at this idea as he is working on this issue in our system as well right now.

[nipsufn]

I think you should be able to do that with Prometheus relabelings.

PR is welcome with changes on code level. There's a similar solution already used in Kratos with ory/x/prometheusx, maybe it can be reused or at least serve as a starting point.

[WillyRL]

I think you should be able to do that with Prometheus relabelings.

yes, I think so. But I also think it's a bad Idea to let all the request path exposed on /metrics, it will introduce performance issues when the requests path are keep growing, at least the performance when the prometheus try to fetching the metrics.