Defining request naming rules Globally or at Service level?

[sureshKumarK]

Hi, Could you please suggest which scenario I should consider to not have a performance impact?

I need to create multiple request naming rules for each Dynatrace environment and the rules will be defined at the Service level. I see we do not have request naming rule API available to duplicate the rules to the remaining Dynatrace environments. As of today, seems Dynatrace have API for Environment level only and not at the Service level

Scenario#1 -> If I create the rules Globally, I can leverage the request naming API to duplicate the rules onto other Environments. If I define 100+ rules Globally, my understanding is there will be more overhead compared to defining them at the service level.

Scenario#2 -> create uncommon rules at the Service level. The downside of this is, there is no API available to duplicate the rules. So, have to create them manually for each DT Environment.

So, to not have overhead on performance, the best approach is to define them manually at the Service level for each Environment? Please suggest if there is a better way to handle it.

FYI, I will have around 100 unique rules if I have to define them Globally and I may have a total of 105 rules if I have to define them at the Service level.

[Julius_Loman]

I don't think there are any significant performance penalties when your request naming rules are created as global using API. You can use service properties or tags to narrow down the scope, so your global rules will only apply for desired services. Technically I believe the naming engine is the same and only rules are applied.

When creating request naming rules, I'd recommend keeping the number of rules as low as possible. If you have 20+ naming rules for your service, then it's likely that there is room for improvement.

[sureshKumarK]

Thanks @Július L. suggestion you have provided giving a good lead on this. In terms of performance, I think defining the naming rules globally with the Service name/id condition is similar to defining them at the Service level. There won't be a big difference. Thanks for your help.

[MAkimov]

I recently had a similar question.

We have over 10K services in 1 dynatrace cluster.

we use different clusters for different environments (test, preprod, prod).

Accordingly, so that I can normally transfer the settings from the cluster to the cluster - I need the naming rules to be configured globally (otherwise I will be tortured to transfer them, plus the essence of the service may change and I need to reconfigure the rules by hand if they are defined locally)

now I have a couple of dozen rules defined globally, but in my plans I think there are several hundred for hundreds of different services.

I try to limit each rule to the service name.

I would like to understand how several hundred rules will work on a cluster (whether this will reduce its performance) Plus I would like to understand which parameter / set of parameters are better suited to restrict the created rules

[sureshKumarK · Accepted solution]

Hi @Mikhail A. here is the best approach. Apply Scenario#1 with Service name/id as condition which is similar to creating the rules at Service level in terms of performance. As I mentioned earlier, advantage with this approach is you can duplicate the rules to other Environments using Request naming API. Hope this helps.

I was able to get the following info from dT support team.

• Either way the naming rules are applied by the cluster after the request have been captured so there is no impact/overhead on the actual Applications.
• There may be a small performance impact with the loading of the page Settings : Service-side service monitoring : Global request naming rules which contains the list of rules that have been defined through the API. This just affects the actual loading the page and not the rules themselves.
• The team did emphasize that there is a significant productivity advantage (as you have identified) to being able to use the API on the global request naming rules.
• We have other customers using 200+ naming rules without issue.
• Be sure to review the Placeholder object. From our experience there are many case where the number of required rules can be significantly reduced with the correct usage of a placeholder. https://www.dynatrace.com/support/help/shortlink/api-request-naming-post-new#parameters

[sureshKumarK · Accepted solution]

I built this payload as a template. @Mikhail A. hope this helps. It worked perfectly. Since Dynatrace do not have API for Service level request naming, this works as a workaround defining the conditions globally for (a) service(s)

API: {{tenant}}/api/config/v1/service/requestNaming?position=APPEND

{

"enabled": true,

"namingPattern": "abctest/Condition1/*/Condition2/*/Condition3",

"conditions": [

{

"attribute": "SERVICE_WEB_SERVER_NAME",

"comparisonInfo": {

"type": "STRING",

"comparison": "EQUALS",

"value": "Grab this value from Service(attached)",

"negate": false,

"caseSensitive": false

}

},

{

"attribute": "WEBREQUEST_URL_PATH",

"comparisonInfo": {

"type": "STRING",

"comparison": "CONTAINS",

"value": "/Condition1",

"negate": false,

"caseSensitive": false

}

},

{

"attribute": "WEBREQUEST_URL_PATH",

"comparisonInfo": {

"type": "STRING",

"comparison": "CONTAINS",

"value": "/Condition2/",

"negate": false,

"caseSensitive": false

}

},

{

"attribute": "WEBREQUEST_URL_PATH",

"comparisonInfo": {

"type": "STRING",

"comparison": "ENDS_WITH",

"value": "/Condition3",

"negate": false,

"caseSensitive": false

}

}

]

}

[bshah6]

Hello - Is there any progress? We are looking for an Dynatrace API that create the request naming at Service level..

Thanks!