Monitor key requests

Key requests are requests that need special attention, either because they're a critical measure of the success of your business (for example, a login request or a shopping-cart checkout request) or because they provide vital technical functionality that your application relies on.

Key requests feature long-term metric history and dedicated dashboard tiles for charting and direct access from your dashboard. Alerting is always enabled for key requests, even when they contribute less than 1% of throughput. They also provide custom thresholds.

Key requests are highlighted in the Key requests section of each service overview page. This visibility is particularly valuable for low-volume, high-importance requests that would otherwise appear at the bottom of the Top requests section of a service overview page.

The number of key requests is limited:

• 500 key requests per environment across all services.
• 100 key requests per service.

When you reach that limit, consider using calculated service metric, which offer you a more flexible approach.

To tag a specific request as a key request

1. In the Dynatrace menu, select Services.

2. Select the relevant service from the list.

3. On the service overview page, select View (View requests, View dynamic web requests, or View resources).

4. Scroll down to the Top requests section and select a request you want to mark as a key request.

5. On the request overview page, open the browse menu (…) and select Mark as key request.

   

Show key requests on a dashboard

To create a dashboard tile for a specific request

1. In the Dynatrace menu, select Services.
2. Select the relevant service from the list.
3. On the service overview page, select View (View requests, View dynamic web requests, or View resources).
4. Scroll down to the Key requests section and select a request you want to show on a dashboard.
5. On the request overview page, open the browse menu (…) and select Pin to dashboard. A new request-specific tile that shows the most important metrics for that particular request is then added to your dashboard.

Long-term data for key requests

Dynatrace enables you to chart any request that it detects during monitoring. By default, detailed history of all requests is retained for 10 days. Longer-term historical data is maintained for requests that you manually identify as key requests. Trend lines for key requests are retained perpetually, but the granularity of long-term history is gradually reduced over time. See the list of available granularities below.

Anomaly detection with key requests

Dynatrace assumes that low-volume requests are of less importance than high-volume and key requests. This means that requests that contribute less than 1% to the overall load of a service won't raise alerts unless their impact is significant enough that the service's overall response time or failure rate is affected. Because this default treatment is not appropriate for all low-volume requests, you should manually tag any important low-volume requests as key requests to ensure that they have standard alerting thresholds.

Request-specific alerting thresholds

Because certain requests may have specific response-time and failure-rate patterns, while others may have strict SLA thresholds, Dynatrace enables you to define custom alerting thresholds when anomalies are detected related to the performance of key requests. If set, key-request-level thresholds override service-level thresholds. To learn how to set request-level thresholds, see Thresholds for a specific web request.

Calculated service metric

As an alternative way to focus on particular requests, you can create a calculated service metric, based on the requests you need. This approach provides you more flexibility with alerting—you can use the calculated metric just like any built-in metric provided by Dynatrace.

Manage key requests via Settings API

You can manage key request configurations via the Settings API.

Create key request configuration

Follow the steps below to create a new key request configuration. Note that this procedure overwrites any existing configuration. If you want to modify an existing configuration, see the Update key request configuration section below.

1. To learn the format of the settings object, query its schema via the GET a schema call. The ID of key request schema is builtin:settings.subscriptions.service.
2. Create the JSON object for your settings.
   Note that the scope of a key request is always a service. You must specify the service by its Dynatrace entity ID. To find out the entity ID of your service, use the GET entities list request.
   Example JSON

   jsoncopydownload
   [
     {
       "schemaId": "builtin:settings.subscriptions.service",
       "scope": "SERVICE-123456789",
       "value": {
         "keyRequestNames": [
           "/cart/checkout"
           ]
         }
     }
   ]

3. Use the POST an object endpoint to send your configuration.

Update key request configuration

1. To learn the format of the settings object, query its schema via the GET a schema call. The ID of key request schema is builtin:settings.subscriptions.service.
   Note that the scope of a key request is always a service. You must specify the service by its Dynatrace entity ID. To find out the entity ID of your service, use the GET entities list request.
2. Query the current configuration via the GET objects call.
3. Create the JSON for your update.
   1. Use the updateToken value from the previous step.
   2. Modify the list of requests in the keyRequestNames array as needed.
      Example JSON

      jsoncopydownload
      {
        "updateToken": "vu9U3hXY3q0ATAAkMG",
        "value": {
          "keyRequestNames": [
            "/cart/checkout",
            "/cart"
          ]
        }
      }

4. Use the PUT an object endpoint to send your configuration.