Configure HTTP monitors

Dynatrace allows you to easily configure your HTTP monitors when first setting them up and at any time thereafter.

During HTTP monitor creation, configuration settings appear after you've selected Create an HTTP monitor. These settings are a subset of the full set available in edit mode (described below) after the monitor has been deployed. If you're creating a new HTTP monitor, see Create an HTTP monitor.

HTTP monitors can be run from our global public or private Synthetic locations, or from cluster-wide locations in Dynatrace Managed. See Create a private Synthetic location for details on using ActiveGate for Synthetic Monitoring. See Requirements for private Synthetic locations for more information on supported Windows and Linux versions.

Configure an existing HTTP monitor

To configure an existing HTTP monitor

  1. Go to Synthetic in the Dynatrace menu.

  2. Select the HTTP monitor you want to configure (this takes you to the details page).

  3. Select the expand button Expand button > Edit from the quick links in the upper-left corner to go to monitor settings. (If you're viewing the older version of the details page, select the Browse button () > Edit to make changes.)

    Alternatively, you can go to the Synthetic monitors page in list view, select the check box next the monitor you want to edit > select Edit in the lower-left corner.

  4. Browse through the Monitor settings tabs on the left to configure settings (detailed explanations below—a subset of these settings are available when you first create an HTTP monitor).

  5. When you make changes, the Discard changes and Save changes buttons are displayed in the lower-left corner. Be sure to save your changes when you're done editing your monitor.

Monitor setup

In the Monitor setup tab, you can:

  • Review and change the Name of the monitor (up to 500 characters). This name should generally describe all the requests in this HTTP monitor.

  • Set cookies to store state information or instruct the server not to send certain kinds of information. Cookies are added to headers, and values are set before the first HTTP request is executed. This setting is available in edit mode only.

    In edit mode, enable Set cookies, then provide a Name and cookie Value. Every cookie must be unique within the list.

    The following symbols are not allowed in the cookie value: ;,\". Provide the Domain of the cookie, and optionally, the Path to the cookie. Save your cookie.

    Select Add cookie to define additional cookies.

    Any cookie values remain on the client until the server sends a Set-Cookie header, you change the cookie value in a pre-execution script, or until the end of monitor execution.

Assign HTTP monitor to a web application

This setting is available in edit mode only.

If this synthetic monitor is associated with one of your monitored applications, you can assign the monitor to the application so you can track application availability and performance. Detected problems are then automatically associated with your application. If the monitor is unavailable, the associated application is also considered to be unavailable.

Select Assign monitor to application and choose an application from the list. You can assign a monitor to multiple applications, and an application can have several assigned monitors. Select Connect another application to add an additional application.

You can assign an HTTP monitor to a web, mobile, or custom application.

HTTP requests

You can edit and add HTTP requests that the monitor sends to your server.

In Visual mode:

  • Select Add HTTP request to add another HTTP request to the HTTP monitor.
  • Select an existing HTTP request to display and edit configuration options for that request.
  • If necessary, you can delete requests from your monitor by selecting x under Delete for the respective request.
  • Use the Move up/down arrows Reorder events to reorder requests.

You aren't limited to just one mode to view and edit your HTTP requests—you can switch back and forth between the UI and script modes by selecting Visual mode or Script mode. For details on editing your HTTP monitor in JSON format, see Script mode for HTTP monitor configuration.

Basic request settings

These settings are available for OAuth2 authorization requests as well as all HTTP methods in HTTP requests:

  • HTTP request URL

    You can add token credentials to the HTTP request URL—begin by typing {cr to view a list of autocomplete credential suggestions. This list only has credentials that you have permission to use, that is, public credentials or owner-only credentials that you created.

    Notes

    • In fields where you can manually insert a reference to a credential (as in the request URL) by copying the credential ID from the vault, use the format {<credential ID>|token}, {<credential ID>|username}, or {<credential ID>|password}, as appropriate for the type of credential you're inserting. You can only copy and paste credentials to which you have access.
  • Add authorization data to

    This field is only available in the OAuth2 authorization request type—see Supported authentication methods in Synthetic Monitoring.

  • HTTP method

    For each request you create or edit, start with the HTTP method, because the available request settings depend on this selection. Supported HTTP methods are:

    • GET
    • POST
    • PUT
    • DELETE
    • HEAD
    • PATCH
    • OPTIONS
  • optional User agent

    The default user agent is in the format DynatraceSynthetic/{version}, where {version} is the current version of the Synthetic engine executing the monitor. Even if you define a custom user agent, Dynatrace always automatically adds DynatraceSynthetic/{version} to the user agent to make sure that synthetic monitoring traffic can be identified.

  • Response status code verification

    Opt to Fail/Pass your monitor based on the returned HTTP status code for the request.

    You can specify an exact status code, inequality symbol (<, <=, >, >=, !=), range, or status class mask (xx only). Use the minus sign (-) with no spaces for a range; use != for the not-equal-to operator. (Note that => and =< are not supported.) Use commas to separate multiple values, for example, 3xx, 404, 406-410, >=500. The default setting, when enabled, is to fail the monitor when the returned status code is >=400.

Additional options

Adjust the Additional options as needed.

Enable pre-execution script

Pre- and post-execution scripts enable you to add custom logic between HTTP monitor requests to do things like parsing the response, modifying the request URL, or skipping requests under certain conditions.

If you enable this, an edit box is displayed for you to enter a script that is executed just before the request is triggered. Pre-execution scripts are based on custom JavaScript code and can be used to build your HTTP request or to add logic that you cannot or do not want to implement in the UI.

For more information and a method reference, see Pre- and post-execution scripts for HTTP monitors. Note that some methods are only available for use in pre-execution scripts or post-execution scripts.

Enable post-execution script

If you enable this, an edit box is displayed for you to enter a script that is executed after the request is completed. Post-execution scripts are based on custom JavaScript code and can be used process responses to the request.

The api.fail() method can be used to define a custom failure message that appears in the Events card on the HTTP monitor details page.

Custom failure message

For more information and a method reference, see Pre- and post-execution scripts for HTTP monitors. Note that some methods are only available for use in pre-execution scripts or post-execution scripts.

Set authentication/authorization

Note that this setting is called Set token request authentication in the OAuth2 authorization request type.

Enable this and provide a username/password pair to automate the login process for password-protected sites via Basic, NTLM, or Kerberos authentication. Dynatrace automatically generates the required Authorization header with the information you've provided. (Read more about Supported authentication methods in Synthetic Monitoring.)

Dynatrace stores and manages all Synthetic Monitoring credentials in a credential vault. Credentials are access controlled and can be designated as owner only or public.

You can choose an existing credential (Select credentials). You can only see credentials that you have access to in this list, that is, public credentials or owner-access credentials created by you.

You can Create new credentials by entering a Username and Password. Provide a Credential name and Save to vault.

Note

We recommend that you not use the format <username>\<domain> for the username; simply provide the <username>.

Create a credential in an HTTP monitor

The credentials you create this way are automatically set to owner-only permissions and can only be used by you. Note that you can create credentials this way in a new or existing HTTP monitor even if you don't have permissions to access credential management in the credential vault.

Add client certificate

Use this option to enable client-side certificate authentication. (Read more about Supported authentication methods in Synthetic Monitoring.)

Dynatrace stores and manages all Synthetic Monitoring credentials in a credential vault. Credentials are access controlled and can be designated as owner only or public.

You can choose an existing credential (Select credentials). You can only see the credentials that you have access to in this list, that is, public credentials or owner-only credentials created by you.

You can Create new credentials—simply upload a Certificate file (in PFX, P12, or PEM format) and enter a Certificate password. Provide a Credential name and Save to vault. The credentials you create this way are automatically set to owner-only permissions and can only be used by you. Note that you can create credentials this way in a new or existing HTTP monitor even if you don't have permissions to access credential management in the credential vault.

Upload a certificate via an HTTP monitor

Note

To assure full mutual authentication, disable Accept any SSL certificate when using certificate authentication.

Set additional HTTP headers

The monitor is created with a bare minimum set of headers required by the protocol. Enable this option to create custom/additional headers:

  1. Select Add header.
  2. Enter a Header name and Value.
  3. Add another header as needed.

Use HTTP headers to implement bearer or token authentication—read more in Supported authentication methods in Synthetic Monitoring.)

You can add token credentials to the header Value—begin by typing {cr to view a list of autocomplete credential suggestions. You can only see the credentials that you have access to in this list, that is, public credentials or owner-only credentials created by you.

Notes

  • In fields where you can manually insert a reference to a credential (as in the header value) by copying the credential ID from the vault, use the format {<credential ID>|token}, {<credential ID>|username}, or {<credential ID>|password}, as appropriate for the type of credential you're inserting. You can only copy and paste credentials to which you have access.

Request body

You can send a payload with your POST, PUT, DELETE, and PATCH requests. You can add token credentials to the request body—begin by typing {cr to view a list of autocomplete credential suggestions. You can only see the credentials that you have access to in this list, that is, public credentials or owner-only credentials created by you. If this field contains an owner-only token, it cannot be edited by other users.

Specify the request body format and contents:

  • x-www-form-urlencoded—Select Add property and enter one or more pairs of property keys and values.
  • raw—Enter the request body in the edit box.

Note

In fields where you can manually insert a reference to a credential (as in the Value of a key-value pair in the request body) by copying the credential ID from the vault, use the format {<credential ID>|token}, {<credential ID>|username}, or {<credential ID>|password}, as appropriate for the type of credential you're inserting. You can only copy and paste credentials to which you have access.

Set rules for response validation

This option is not available in the OAuth2 authorization request type.

Response validation enables you to pass/fail your monitor based on expected content in the response body.

  • Pass if or Fail if determines the basic test.
  • Text contains specifies the text to look for in the response. This string is case sensitive.
  • Interpret content match as regular expression treats the specified text as a regular expression.

Follow redirects

By default, an HTTP monitor follows up to 10 redirects from an original request until it reaches the final destination. Turn this option off to monitor only the first response of the redirect chain, for example, to check redirect response status codes.

Accept any SSL certificate

By default, HTTP monitors accept any SSL certificate, regardless of whether they're valid. Turn this option off to have the monitor fail with invalid SSL certificates.

This setting is independent of SSL certificate expiration date verification (see below).

SSL certificate expiration date verification

This setting fails the monitor if SSL certificate expiry is within the specified number of days (must be 100 or less). This setting is independent of SSL certificate validity verification.

So if you want to configure a monitor that accepts a self-signed certificate as long as it hasn't expired, you would:

  • Enable Accept any SSL certificate.
  • Enable SSL certificate expiration date verification.

Note that if you enable both these options and the SSL certificate has expired, the HTTP request will fail and report an SSL certificate expired error.

Adapt request timeout

Enable this option to edit the request timeout. Note that the default request timeout is 10 seconds, even if you do not enable this option. If the request time exceeds the specified/default timeout, the monitor will fail. Note that monitor execution time is the sum of the execution times of individual requests, and monitor timeout is 60 seconds.

Frequency and locations

Two factors make up your monitoring schedule:

  • Monitor my website every n minutes determines how frequently your HTTP monitor runs from each location: every 1, 2, 5, 10, 15, 30, or 60 minutes.

  • Location selections specify the locations from which the monitor is executed.

    HTTP monitors can be run from our global public or private Synthetic locations, or from cluster-wide locations in Dynatrace Managed.

Together, these factors determine how often your HTTP monitor runs each hour. For example, if you select three locations and set monitor frequency at 15 minutes, the result will be 12 monitor executions each hour (4 times per hour from each of the 3 locations).

Outage handling

This setting is available in edit mode only. These options determine what to do in the event of availability outages.

You can disable problem generation for global and local outages if you're testing a volatile site or have scheduled downtime that you don't want to be alerted on.

  • Generate a problem and send an alert when this monitor is unavailable at all configured locations

    This setting is enabled by default for newly created monitors. It alerts you of global availability outages, that is, when all locations experience a failure simultaneously.

  • Generate a problem and send an alert when this monitor is unavailable for one or more consecutive runs at any location

    This allows you to raise a problem when there are consecutive failures at one or more locations.

    In the example below, a monitor is configured for 4 locations, and a problem will be generated if 3 of those 4 locations are unable to access your site during 2 or more consecutive runs.

An outage problem is resolved when there are as many consecutive successful executions as the configured number of failed executions for generating the problem. The successful executions must occur on the number of locations that = the total number of locations–number of locations required for the problem+1.

Note that when a global outage problem is resolved, you might still have one or more locations experiencing monitor failure. Set up local outage rules to be alerted on these.

See Synthetic calculations for more information on:

Note

Retry on error is not available for HTTP monitors.

Performance thresholds

Performance thresholds enable you to be proactive about site latency.

  1. Turn on Performance thresholds enabled.

  2. Select Add new performance threshold.

  3. Select one of the requests in your monitor or Sum of all requests.

  4. Set Threshold value to the threshold time in seconds. You can see the 24-hour average performance up until that point to help you set a threshold. Then select Add threshold.

    You can set multiple performance thresholds—for the monitor as a whole as well as for individual requests. Performance thresholds are defined as the Response time of the monitor or of individual requests.

Dynatrace generates a performance problem if a monitor at a given location violates any of the defined performance thresholds in 3 of the 5 most recent executions, unless there is an open maintenance window for the monitor. That is, the violations must occur at the same location. Multiple locations can have such violations and be included in a problem.

The problem is closed if the performance thresholds are not violated in the 5 most recent executions at each of the previously affected locations.

See Synthetic calculations for more information.