1500bytes

Appearance

On this page

Configuring endpoint monitoring ​

Azure Traffic Manager includes built-in endpoint monitoring and automatic endpoint failover. This feature helps you deliver high-availability applications that are resilient to endpoint failure, including Azure region failures.

To configure endpoint monitoring, you open the Configuration page for the Traffic Manager profile. Then, under the Endpoint monitor settings section, you specify the following settings for the Traffic Manager profile:

Setting

Description

Protocol

  • Choose HTTP, HTTPS, or TCP as the protocol that Traffic Manager uses when probing your endpoint to check its health.
  • HTTPS monitoring doesn't verify whether your TLS/SSL certificate is valid; it only checks that the certificate is present.

Port

  • Choose the port used for the request.

Path

  • This configuration setting is valid only for the HTTP and HTTPS protocols, for which specifying the path setting is required.
    • Providing this setting for the TCP monitoring protocol results in an error.
  • For HTTP and HTTPS protocol, give the relative path and the name of the webpage or the file that the monitoring accesses.
  • A forward slash (/) is a valid entry for the relative path.
    • This value implies that the file is in the root directory (default).

Custom Header settings

  • This configuration setting helps you add specific HTTP headers to the health checks that Traffic Manager sends to endpoints under a profile.
  • The custom headers can be specified at a profile level to be applicable for all endpoints in that profile and / or at an endpoint level applicable only to that endpoint.
  • You can use custom headers for health checks of endpoints in a multi-tenant environment. That way it can be routed correctly to their destination by specifying a host header.
  • You can also use this setting by adding unique headers that can be used to identify Traffic Manager originated HTTP(S) requests and processes them differently.
  • You can specify up to eight header:value pairs separated by a comma. Example - header1:value1, header2:value2

Expected Status Code Ranges

  • This setting allows you to specify multiple success code ranges in the format 200-299, 301-301.
  • If these status codes are received as response from an endpoint when a health check is done, Traffic Manager marks those endpoints as healthy.
  • You can specify a maximum of eight status code ranges.
  • This setting is applicable only to HTTP and HTTPS protocol and to all endpoints.
  • This setting is at the Traffic Manager profile level and by default the value 200 is defined as the success status code.

Probing interval

  • This value specifies how often an endpoint is checked for its health from a Traffic Manager probing agent.
  • You can specify two values here: 30 seconds (normal probing) and 10 seconds (fast probing).
  • If no values are provided, the profile sets to a default value of 30 seconds. Visit the Traffic Manager Pricing page to learn more about fast probing pricing.

Tolerated number of failures

  • This value specifies how many failures a Traffic Manager probing agent tolerates before marking that endpoint as unhealthy.
  • Its value can range between 0 and 9.
    • A value of 0 means a single monitoring failure can cause that endpoint to be marked as unhealthy.
    • If no value is specified, it uses the default value of 3.

Probe timeout

  • This property specifies the amount of time the Traffic Manager probing agent should wait before considering a health probe check to an endpoint a failure.
  • If the Probing Interval is set to 30 seconds, then you can set the Timeout value between 5 and 10 seconds.
  • If no value is specified, it uses a default value of 10 seconds.
  • If the Probing Interval is set to 10 seconds, then you can set the Timeout value between 5 and 9 seconds.
  • If no Timeout value is specified, it uses a default value of 9 seconds.

How endpoint monitoring works ​

HTTP(S) monitoring protocol ​

When the monitoring protocol is set as HTTP or HTTPS, the Traffic Manager probing agent makes a GET request to the endpoint using the protocol, port, and relative path given.

An endpoint is considered healthy if probing agent receives a 200-OK response, or any of the responses configured in the Expected status code ranges.

If the response is a different value or no response get received within the timeout period, the Traffic Manager probing agent reattempts according to the Tolerated Number of Failures setting. No reattempts are done if this setting is 0. The endpoint is marked unhealthy if the number of consecutive failures is higher than the Tolerated Number of Failures setting.

For HTTP or HTTPS monitoring protocol, a common practice on the endpoint side is to implement a custom page within your application - for example, /health.aspx.

Using this path for monitoring, you can perform application-specific checks, such as checking performance counters or verifying database availability. Based on these custom checks, the page returns an appropriate HTTP status code.

TCP monitoring protocol ​

When the monitoring protocol is TCP, the Traffic Manager probing agent creates a TCP connection request using the port specified.

If the endpoint responds to the request with a response to establish the connection, that health check is marked as a success. The Traffic Manager probing agent resets the TCP connection.

In cases where the response is a different value or no response get received within the timeout period, the Traffic Manager probing agent reattempts according to the Tolerated Number of Failures setting. No reattempts are made if this setting is 0.

If the number of consecutive failures is higher than the Tolerated Number of Failures setting, then that endpoint is marked unhealthy.

In all cases, Traffic Manager probes from multiple locations. The consecutive failure determines what happen within each region. That's why endpoints are receiving health probes from Traffic Manager with a higher frequency than the setting used for Probing Interval.