Configure muted request to Service

[AK]

Hi Folks,

How can we add muted request to the service via UI or API?

Do we need to first add a web request to web request naming rule and then add request name to muted requests?

I wanted to understand a flow over the UI and then would give a try to configure it via API.

Question because, when I see the configuration of muted requests it doesn't have any specific option to put a rule such as "Relative URL begins with and Relative URL ends with"

However, such setting is present under web request naming rule.

Even in documentation under JSON example, it is just mentioned as 'mutedRequestNames'. We can't see any option to add 'Relative URL begins with and ends with' for web request.

Would need some help on this.

Regards,

AK

[AK]

Can someone share a thoughts on this?

[paulo_calaxa]

Hi.
It has been a while since I had to do one, and have no means to try it.
Afaik, you will refer to either the detected request name, or the result of a renaming rule if it has one.
No arm trying and check if it accepts a list of requests or a regexp expression, but I suppose that the plural name(s) under button Add item is  still misleading. You will have to add one by one.
Would it make sense to have the same options? I suppose that in this case, the danger of inadvertently muting one not desired is too great… and that in the first place there should not be needed to have that many and does not justify it.

Kind regards,
Paulo.

[AK]

@paulo_calaxa thank you for the response.

But I think, I have not articulated my question well.

Lets skip the web request naming rule.

How can we add web request to muted requests? For example, URL begins with /user and ends with /profile

Regards,

AK

[ChadTurner]

@AK we have only done thisby doing a one by one mute via the API. Meaning each request that is classified as should be muted, is its own line item. So Bookings and Rebookings, they both are unique in their own right and your rename can formulate it to "Muteme Bookings" and "Muteme Rebookings" or even just "Muteme" and the system will target the mute off the detected name and not the renamed value. Thats been our experience. We tried wild cards to cut down on rules and try a starts with etc.... but it all failed, which is why we went 1 by 1.

[Malaik]

 @AK 

Could you please elaborate more?

Mute requests is not feasible with condition like: begin with, ends with, contain ..., you should put the exact name of the request.

From the UI its also possible by selecting the request in question, and enable the MUTE..

Its also possible using APIs...

[AK]

@Malaik, thanks for the response.

So I have web requests something like below,

/user1/summary/area1/profile
/user2/summary/area2/profile
/user3/summary/area3/profile
/user4/summary/area3/profile

In muted requests setting, we don't have an option to add URL begins with /user and ends with /profile.

So I believe, we have to create bucketing with the help of web requests naming rule with criteria, URL begins with /user and ends with/profile and put that rule name under muted requests.

Hope my understanding is correct till here.

Why I'm putting a question w.r.t muted request because, I have to mute such requests for bunch of services.

I have following options with their own limitations.

1. Apply URL Based Sampling --> This will get applied to the whole environment
2. Apply web request naming rule via API and then add it to muted request (for individual service via API) --> Web request naming rule will get applied to whole environment

Regards,

AK

[AK]

@Malaik, hope I explained it correctly now. Please share your thoughts if have any.

[Malaik]

In this specific case, I can suggest to group your requests with a requests naming like:

/user[ID]/summary/area[ID]/profile

and mute 1 single request.

[paulo_calaxa]

Hi.
As I said, as far as I knew, wasn't totally sure, could have been improved, but others confirmed, it still doesn't let you set a list, begins, or regex... And as I said, you would have to add requests to mute, one by one.
Indeed, when I first read, "Do we need to first add a web request to web request naming rule and then add request name to muted requests?", I only replied in general. Sorry about that.
So what I meant was... not mandatory
you could add
/user1/summary/area1/profile
and then 
/user2/summary/area2/profile
But of course, if there are a lot, then yes, you first set a web request naming to generate a new request that has all the combinations needed.
That was what Chad meant with his examples and by the unique name:
he mentioned an example with Bookings and Rebookings, that could match yours of users and areas.
/user1/summary/area1/profile
/user2/summary/area2/profile
/user3/summary/area3/profile
/user4/summary/area3/profile
If for whatever reason you need both groups separated, even for muting, perhaps you couldn't achieve an easy way to find rules to cover all the combinations... You could set a renaming to generate a group of requests for users, let's say "summaryProfilesOfUsers", that would be... unique... and other for the areas, that would be unique, and you only have to add those two, one by one, to be muted.
But by all means, if it is clear that you want both, and given your set of request it should be totally feasible to set rules to cover them all, you'll generate a renaming that puts them all under a new request name, let's say "summary profile by user and area" or whatever.
So, you only add that new, unique, request name, once.

Kind regards

[AK]

@paulo_calaxa, thank you for the comprehensive explanation.

In that case, the only challenge is to apply web request naming rule to the desired services.

And as far I know if we wanted to apply it on bunch of services then it would be a global rule.

We don't have any API available to set it individually. Please correct if my understanding is wrong.

Regards,

AK

[paulo_calaxa]

Hi.
At the time being I don't have an environment, with the necessary permissions, to confirm it, but from memory and checking it in the demo, there should be a general Renaming option, under server-side settings

Kind regards.

[AK · Accepted solution]

Hi @paulo_calaxa @Malaik @ChadTurner 

Thank a lot for your help and useful suggestions.

I was able to configure web request naming rule via API and following is the request body I used.

Note: Tag name and request naming rule name (used in namingPattern) can be different.

{
    "conditions": [
        {
            "attribute": "WEBREQUEST_URL_PATH",
            "comparisonInfo": {
                "caseSensitive": false,
                "comparison": "BEGINS_WITH",
                "negate": false,
                "type": "STRING",
                "value": "/user"
            }
        },
        {
            "attribute": "WEBREQUEST_URL_PATH",
            "comparisonInfo": {
                "caseSensitive": false,
                "comparison": "ENDS_WITH",
                "negate": false,
                "type": "STRING",
                "value": "/profile"
            }
        },
        {
            "attribute": "SERVICE_TAG",
            "comparisonInfo": {
                "comparison": "TAG_KEY_EQUALS",
                "negate": false,
                "type": "TAG",
                "value": {
                    "context": "CONTEXTLESS",
                    "key": "UserProfile"
                },
                "values": null
            }
        }
    ],
    "enabled": true,
    "namingPattern": "UserProfile"
}

Then I applied muted request to each service via API and following is the request body.

Note:- Postman is used to pass the service ID's in the scope field.

[
    {
        "schemaId": "builtin:settings.mutedrequests",
        "schemaVersion": "0.0.5",
        "scope": "{{id}}",
        "value": {
            "mutedRequestNames": [
                "UserProfile"
            ]
        }
    }
]

Following thread also helped me to build request body to create web request naming rule,

https://community.dynatrace.com/t5/Dynatrace-tips/PRO-TIP-Global-request-naming-for-REST-services/m-...

I really appreciate the help you provided guys.

Regards

AK