Please Explain Service Key Request Names Setting

[36Krazyfists]

I understand Request Naming rules and their use and how to apply them.  

What I don't understand is the Key Requests option in a service settings.  

You can add Key Request Names.

I've read the documentation here several times and for the life of me I just do not get what this setting is supposed to do and what it can be used for...

It's just a blank text box and we're supposed to put existing Key Request Names in there or something?  I don't know.  I just don't get it.

Can somebody explain it to me like I'm five and give an example of what this setting does?

Thanks so much!

[Julius_Loman · Accepted solution]

Key requests are selected requests (you select them) which are more important to you. Dynatrace has dedicated metrics for key requests (like Response time, HTTP errors, request count), so you can easily work with the metrics.  This applies to both classic (see example in Data Explorer) and Grail (see example in Notebooks). 

Dynatrace also pays special attention when it comes to anomaly detection for key requests, and alerting for key requests is enabled even if the volume for those requests is low. Also you can set individual anomaly detection rules for your key requests.

See more here https://docs.dynatrace.com/docs/observe/applications-and-microservices/services/analysis/monitor-key...

[36Krazyfists]

Yeah, I understand what Key Requests are.  Wait, are you saying that's where we enter in what requests we want to mark as Key Requests?

If so, why doesn't it fetch all of the requests in the last 24 hours and present them to us in a nice drop-down list to select? 

It's kind of odd to have just a blank text box and we have to put the exact names in that we want.  Does it at least do wildcard matching or something?

I've always marked Key Requests by just going to the Request I want to mark and clicking the Mark as Key Requests button.

The particular service I was looking at when I saw this setting only had one Key Request so I didn't put two-and-two together that this was a place to enter in Requests, and it being just a blank box, it didn't occur to me that this would be another way to enter in Key Requests.

Weird...

Anyways, thanks so much for clearing that up!

[Julius_Loman]

Sure, it provides an option to select the requests you want. See this.
Settings on a service is just one of the options of how to define key requests.

[paolo_fumanelli]

Pratical example happened to me.

A service which was exposing some key requests was moved to a new Apache HTTP instance (new process group, so a new service would have been created).

But traffic would have been moved gradually to new Apache instance and I didn't want to go back and fourth new service to check request by request which ones were present to mark them as key request.

So I just added them to new service's settings so starting from the very first call to each one of them, they were marked as key request.

[36Krazyfists]

Yeah, that's a great use case.  Still seems like a matcher would be a better option though.  Like, a way to enter in wildcard/regex matching to mark Key Requests more dynamically.  I just find a blank text box a really weird way to do it compared to most of the other ways settings are done in Dynatrace.

Thanks for your example though, makes sense!

[Julius_Loman]

@36Krazyfists, although having a wildcard/regex would be convenient, it's dangerous. There is a limit for the number of key requests in an environment, and with wildcards, you could hit just by accidentaly marking volatile requests.

[36Krazyfists]

Sure, but they could easily just put a "matching entities" display right below it and, if it's above a certain value, throw a warning.  There's plenty of other settings that have limitations where regex/wildcard matching can be applied.  Not sure how this is any different.