Multiple Request Naming Rules applied to one request

[r_weber]

Due to the limitations and flexibility of request naming rules I need to create multiple rules that would - if applied after eachother - transform my requests how I need them. However it seems that rules cannot be chained...

My example: remove multiple ID strings from requests. E.g:

/api/v3/carts/1234567689/entries/23

In request naming regex rules you cannot:

- use multiple capture groups

- lookahead and lookbehind

I cannot use fixed strings like "entries" in my rules. I want to create a generic rule that replaces any numeric URI path with [id]. So I ended up with a rather complex rule with 2 placeholders (that capture before/after the numeric id) and then name the request like this: {prefix_id}[id]{postfix_id}.

The result only works for the first ID found in a request and renames the request:

/api/v3/carts/[id]/entries/23

Now to also replace the second numeric id, I'd just need to apply the same rule again, and again in case I have a 3rd numeric id in a path.
But it seems that Dynatrace stops after the first (global) naming rule has been applied?

Can anyone from Dynatrace confirm this? Or maybe anyone has another solution for this problem?

Cheers!

[Julius_Loman]

Hey @r_weber!,

would this solution be applicable in yourcase? I also talked about it in the observability clinic tips episode #2. 

It will clean up one or two numeric IDs. Unfortunately I could not figure out how to do it with 3 (or more) due to the limits on regular expressions. I think it's not possible with the current limits.

Also there is a way to use the cleanup rules, often overlooked. I don't like using them, since it only removes strings, it does not allow you to replace them.

[r_weber]

Thanks @Julius_Loman for pointing to that post. It’s exactly the solution I came up with. It works generically like my regexes/placeholders but what I do not like is the fact that one needs a rule for replacing 1 numeric ID, another one for 2 and another one for 3…

Thats what i wanted to avoid somehow.

As you pointed out, its a limitation in Dynatrace and its regex limitations.

Still it would be nice to know how Dynatrace evaluates multiple rules, global ones and service-level ones.

[Julius_Loman]

You are welcome. The regex limitations are there for a reason and I understand it. In most cases, the cleanup rules will be ok - but they should really replace and not remove it.

Just when you have rest endpoints such as /users and /users/123 with cleanup rule (remove /\d+ )  this gets merged to a single request name and those two operations should be treated differently. Too bad the cleanup rules do not replace.