Referring to this article PRO TIP - Global request naming for REST services - Dynatrace Community I face with this problem a lot and I want to share my solution with you. This article is very good and explains a lot, but I have much better solution.
Long story short – many different people came to me to create Request Naming rule for their URL with usually contains some number. I create at least 100 different processing rule to handle all their request, at some point number of rules where overwhelming. Unfortunately demanding of creation naming rules still increase and many people want to include header in naming rules with makes things even worse to manage. I started to create more generous rules and try my best to make it most effective as possible. I prepare for your explanation how it work in real environment.
First of all I took an advantage if number is between “/” if length of number is 2 or more it will be cut off by the rules.
/xxxx/xxx/35/xxxxx ->/xxxx/xxx/[]/xxxxx
Same story is for end of the URL like:
/xxx/xxx/xx/32 ->/xxx/xxx/xx/[]
If number is not between “/” rule are more restricted and at least 4 digit needs to be matched:
/xxx/xxx/INVOICE-1345/xxx -> /xxx/xxx/INVOICE[]/xxx
If URL contain HEX there is a rule to cut it off:
/xxxx/xxx/xxx/4e0b6318-a4c5-49d9-9f89-4e91a402aec3/xxxx ->/xxxx/xxx/xxx/[]/xxxx.
Right, nothing new so far. There are 3 rules with are more or less the same as in link to old PRO TIP.
The main difference is that my rules are capable to exclude multiple occurrence of numbers.
For example:
/xxxxx/xxxx/11231234/xxxxxxx/12232323/xxxxxx - > /xxxxx/xxxx/[]/xxxxxxx//xxxxxx
I found a way to do it with advanced regex concepts – negative lookahead. I also need to tweak this concept to restriction made by Dynatrace(regex usage is limited, but engine below would allow you to make some magic) like empty group and edge case like /xxxx/2323/xxx/122342(group shouldn't be empty you have to return nothing) and many more different cases while I test my rules.
How it work in practice? Let's focus on detection of 4 digit number because is most obvious rule.
There are 4 rules in naming pattern:
delimiterOrRegex_detect: '[0-9-%_:.]{4,}'
delimiterOrRegex_begin: '^(.+?)[0-9-%_:.]{4,}'
delimiterOrRegex_mid: '[0-9-%_:.]{4,}([^0-9-%_:.].*?)[0-9-%_:.]{4,}'
delimiterOrRegex_end: '(?!.*?[0-9-%_:.]{4,})[^0-9-%_:.].{0,}$'
1 - [0-9-%_:.]{4,} – is quite obvious detect number containing at least 4 digit(or -%_:.)
2- ^(.+?)[0-9-%_:.]{4,} – detect TEXT before number:
3 - [0-9-%_:.]{4,}([^0-9-%_:.].*?)[0-9-%_:.]{4,} detect TEXT between number:
4 - (?!.*?[0-9-%_:.]{4,})[^0-9-%_:.].{0,}$ detect text after number(it was the most difficult part to write!):
If there is only one number in URL rule number 3 would not return anything.
Rules don’t end here they will cut of all numbers in URL for example if there are 3 numbers:
Rules make it look like this:
/xxxxx/xxxx/[]/xxx//xxxxxx
in some cases it could cut of to much data from URL, but in my opinion it is not big deal. It happened very really and even if it happened URL contain 3 changing number is not very useful in analysis(key requests ect) and data is not lost the are just excluded from naming pattern. It is still exist in metadata of request.
Order of rules are very important:
1 – HEX
2 – BIG_NUMBER
3 – SMAILL_NMBER
Otherwise something like this could happened:
/xxxxx/xxxx/4e0b6318-a4c5-49d9-9f89-4e91a402aec3/ -> /xxxxx/xxxx/4e0b[]a4c5-49d9-9f89-4e91a402aec3/
Conclusion
The rules are not perfect, for sure there are cases where you have to write dedicated rule. In my case 99% of cases is covered by it. You can tweak rules by your needs by changing numbers(numbers determine how restricted rules are). For example number 4 in described rule could be changed to 3 if you want less restriction or to 5 if you want more restriction.
In hex rules detection is asymmetrical. For example rule detect hex with 16>= characters, but comparison is 6. It is very unlikely that URL contain other meaning full data that have “0-9a-f” 6 times in row, but if URL contains short number it is going to be removed with HEX. Remember only one rule is applied at a time.
/xxxx/x/4e0b6318-a4c5-49d9-9f89-4e91a402aec3/xxxxxxx/1224545453233/xxxx/xx ->
/xxxx/x/[]/xxxxxxx//xxxx/xx
Otherwise number will stay there.
Overthink 😊
I think I hit the wall what is possible in naming rules using regex in Dynatrace. I have other ideas how to improve those rules further, but for now limitation in DynaRegex restrict further improvement(I am not saying that they supposed to be removed, I am just saying that they limit my actions😊).
I hope you will find this rules useful.
*Rules are in raw form and in form to implement in monaco
Featured Posts
