---
layout: Conceptual
title: Monitor Azure Front Door | Azure Docs
canonicalUrl: https://docs.azure.cn/en-us/frontdoor/monitor-front-door
breadcrumb_path: /bread/toc.json
uhfHeaderId: mooncake
recommendations: false
author: yujiang111
ms.collection: networking
description: Learn how to monitor Azure Front Door using Azure Monitor, including data collection, analysis, and alerting.
ms.author: v-leozhao
ms.service: azure-frontdoor
ms.topic: concept-article
ms.date: 2025-08-25T00:00:00.0000000Z
ms.custom: horz-monitor
locale: en-us
document_id: d19f3a5c-d631-01c7-e37e-d345064eeff5
document_version_independent_id: 43bdbacf-6305-a465-a16d-b9dec1369961
updated_at: 2025-08-26T09:37:00.0000000Z
original_content_git_url: https://github.com/MicrosoftDocs/mc-docs-pr/blob/live/articles/frontdoor/monitor-front-door.md
gitcommit: https://github.com/MicrosoftDocs/mc-docs-pr/blob/909c8c2f14fe50a5f615a4a71d94b8ce84bcc2b6/articles/frontdoor/monitor-front-door.md
git_commit_id: 909c8c2f14fe50a5f615a4a71d94b8ce84bcc2b6
site_name: DocsAzureCN
depot_name: Azure.mooncake-docs
page_type: conceptual
toc_rel: toc.json
feedback_system: None
feedback_product_url: ''
feedback_help_link_type: ''
feedback_help_link_url: ''
word_count: 2793
asset_id: frontdoor/monitor-front-door
moniker_range_name:
monikers: []
item_type: Content
source_path: articles/frontdoor/monitor-front-door.md
cmProducts:
- https://authoring-docs-microsoft.poolparty.biz/devrel/07bb3e10-d135-43ff-bc8b-360497cb39fa
- https://authoring-docs-microsoft.poolparty.biz/devrel/b5e53e15-0a76-4936-b270-8b2badca62ac
spProducts:
- https://authoring-docs-microsoft.poolparty.biz/devrel/12e559b9-eaf6-4aee-9af7-62334e15f863
- https://authoring-docs-microsoft.poolparty.biz/devrel/6908a4c7-0b59-4f8b-a00e-59c83ae0a04a
platformId: d4a350aa-662d-bb21-b2ce-8c67a7af5e17
---
# Monitor Azure Front Door | Azure Docs
Azure Monitor collects and aggregates metrics and logs from your system to monitor availability, performance, and resilience, and notify you of issues affecting your system. You can use the Azure portal, PowerShell, Azure CLI, REST API, or client libraries to set up and view monitoring data.
Different metrics and logs are available for different resource types. This article describes the types of monitoring data you can collect for this service and ways to analyze that data.
## Collect data with Azure Monitor
This table describes how you can collect data to monitor your service, and what you can do with the data once collected:
| Data to collect | Description | How to collect and route the data | Where to view the data | Supported data |
| --- | --- | --- | --- | --- |
| Metric data | Metrics are numerical values that describe an aspect of a system at a particular point in time. Metrics can be aggregated using algorithms, compared to other metrics, and analyzed for trends over time. | - Collected automatically at regular intervals.- You can route some platform metrics to a Log Analytics workspace to query with other data. Check the **DS export** setting for each metric to see if you can use a diagnostic setting to route the metric data. | [Metrics explorer](/en-us/azure-monitor/essentials/metrics-getting-started) | [Azure Front Door metrics supported by Azure Monitor](monitor-front-door-reference#metrics) |
| Resource log data | Logs are recorded system events with a timestamp. Logs can contain different types of data, and be structured or free-form text. You can route resource log data to Log Analytics workspaces for querying and analysis. | [Create a diagnostic setting](/en-us/azure-monitor/essentials/create-diagnostic-settings) to collect and route resource log data. | [Log Analytics](/en-us/azure-monitor/learn/quick-create-workspace) | [Azure Front Door resource log data supported by Azure Monitor](monitor-front-door-reference#resource-logs) |
For the list of all of the data supported by Azure Monitor, see:
- [Azure Monitor supported metrics](/en-us/azure-monitor/platform/metrics-supported)
## Built-in monitoring for Azure Front Door
Logs track all requests that pass through Azure Front Door. It can take a few minutes for logs to be processed and stored.
There are multiple Front Door logs, which you can use for different purposes:
- Access logs can be used to identify slow requests, determine error rates, and understand how Front Door's caching behavior is working for your solution.
- Health probe logs can be used to identify origins that are unhealthy or that don't respond to requests from some of Front Door's geographically distributed PoPs.
- Activity logs provide visibility into the operations performed on your Azure resources, such as configuration changes to your Azure Front Door profile.
### Access log
Information about every request is logged into the access log. Each access log entry contains the information listed in the following table.
| Property | Description |
| --- | --- |
| TrackingReference | The unique reference string that identifies a request served by Azure Front Door. The tracking reference is sent to the client and to the origin by using the `X-Azure-Ref` headers. Use the tracking reference when searching for a specific request in the access or WAF logs. |
| Time | The date and time when the Azure Front Door edge delivered requested contents to client (in UTC). For WebSocket connections, the time represents when the connection gets closed. |
| HttpMethod | HTTP method used by the request: DELETE, GET, HEAD, OPTIONS, PATCH, POST, or PUT. |
| HttpVersion | The HTTP version that the client specified in the request. |
| RequestUri | The URI of the received request. This field contains the full scheme, port, domain, path, and query string. |
| HostName | The host name in the request from client. If you enable custom domains and have wildcard domain (`*.contoso.com`), the HostName log field's value is `subdomain-from-client-request.contoso.com`. If you use the Azure Front Door domain (`contoso-123.z01.azurefd.net`), the HostName log field's value is `contoso-123.z01.azurefd.net`. |
| RequestBytes | The size of the HTTP request message in bytes, including the request headers and the request body. For WebSocket connections, this value is the total number of bytes sent from the client to the server through the connection. |
| ResponseBytes | The size of the HTTP response message in bytes. For WebSocket connections, this value is the total number of bytes sent from the server to the client through the connection. |
| UserAgent | The user agent that the client used. Typically, the user agent identifies the browser type. |
| ClientIp | The IP address of the client that made the original request. If there was an `X-Forwarded-For` header in the request, then the client IP address is taken from the header. |
| SocketIp | The IP address of the direct connection to the Azure Front Door edge. If the client used an HTTP proxy or a load balancer to send the request, the value of SocketIp is the IP address of the proxy or load balancer. |
| TimeTaken | The duration from when the Azure Front Door edge received the client's request to when the last byte of the response was sent to the client, measured in seconds. This metric excludes network latency and TCP buffering. For WebSocket connections, it represents the connection duration from establishment to closure. |
| RequestProtocol | The protocol specified by the client in the request. Possible values include: **HTTP**, **HTTPS**. For WebSocket, the protocols are **WS**, **WSS**. Only requests that successfully upgrade to WebSocket have WS/WSS. |
| SecurityProtocol | The TLS/SSL protocol version used by the request, or null if the request didn't use encryption. Possible values include: **SSLv3**, **TLSv1**, **TLSv1.1**, **TLSv1.2**. |
| SecurityCipher | When the value for the request protocol is HTTPS, this field indicates the TLS/SSL cipher negotiated by the client and Azure Front Door. |
| Endpoint | The domain name of the Azure Front Door endpoint, such as `contoso-123.z01.azurefd.net`. |
| HttpStatusCode | The HTTP status code returned from Azure Front Door. If the request to the origin timed out, the value for the HttpStatusCode field is **0**. If the client closed the connection, the value for the HttpStatusCode field is **499**. |
| Pop | The Azure Front Door edge point of presence (PoP) that responded to the user request. |
| Cache Status | How the Azure Front Door cache handles the request. Possible values are:
- **HIT** and **REMOTE\_HIT**: The HTTP request was served from the Azure Front Door cache.
- **MISS**: The HTTP request was served from origin.
- **PARTIAL\_HIT**: Some of the bytes were served from the Front Door edge PoP cache, and other bytes were served from the origin. This status indicates an [object chunking](front-door-caching#delivery-of-large-files) scenario.
- **CACHE\_NOCONFIG**: The request was forwarded without caching settings, including bypass scenarios.
- **PRIVATE\_NOSTORE**: There was no cache configured in the caching settings by the customer.
- **N/A**: A signed URL or WAF rule denied the request. |
| MatchedRulesSetName | The names of the Rules Engine rules that were processed. |
| RouteName | The name of the route that the request matched. |
| ClientPort | The IP port of the client that made the request. |
| Referrer | The URL of the site that originated the request. |
| TimetoFirstByte | The length of time, in seconds, from when the Azure Front Door edge received the request to the time the first byte was sent to client, as measured by Azure Front Door. This property doesn't measure the client data. |
| ErrorInfo | If an error occurred during the processing of the request, this field provides detailed information about the error. Possible values are:
- **NoError**: Indicates no error was found.
- **CertificateError**: Generic SSL certificate error.
- **CertificateNameCheckFailed**: The host name in the SSL certificate is invalid or doesn't match the requested URL.
- **ClientDisconnected**: The request failed because of a client network connection issue.
- **ClientGeoBlocked**: The client was blocked due to the geographical location of the IP address.
- **UnspecifiedClientError**: Generic client error.
- **InvalidRequest**: Invalid request. This response indicates a malformed header, body, or URL.
- **DNSFailure**: A failure occurred during DNS resolution.
- **DNSTimeout**: The DNS query to resolve the origin IP address timed out.
- **DNSNameNotResolved**: The server name or address couldn't be resolved.
- **OriginConnectionAborted**: The connection with the origin was disconnected abnormally.
- **OriginConnectionError**: Generic origin connection error.
- **OriginConnectionRefused**: The connection with the origin wasn't established.
- **OriginError**: Generic origin error.
- **ResponseHeaderTooBig**: The origin returned a too large of a response header.
- **OriginInvalidResponse**: The origin returned an invalid or unrecognized response.
- **OriginTimeout**: The time-out period for the origin request expired.
- **ResponseHeaderTooBig**: The origin returned a too large of a response header.
- **RestrictedIP**: The request was blocked because of restricted IP address.
- **SSLHandshakeError**: Azure Front Door was unable to establish a connection with the origin because of an SSL handshake failure.
- **SSLInvalidRootCA**: The root certification authority's certificate was invalid.
- **SSLInvalidCipher**: The HTTPS connection was established using an invalid cipher.
- **OriginConnectionAborted**: The connection with the origin was disconnected abnormally.
- **OriginConnectionRefused**: The connection with the origin wasn't established.
- **UnspecifiedError**: An error occurred that didn’t fit in any of the errors in the table. |
| OriginURL | The full URL of the origin where the request was sent. The URL is composed of the scheme, host header, port, path, and query string. **URL rewrite**: If the Rules Engine rewrites the request URL, the path refers to the rewritten path. **Cache on edge PoP**: If the request was served from the Azure Front Door cache, the origin is **N/A**. **Large request**: If the requested content is large and there are multiple chunked requests going back to the origin, this field corresponds to the first request to the origin. For more information, see [Object Chunking](front-door-caching#delivery-of-large-files). |
| OriginIP | The IP address of the origin that served the request. **Cache on edge PoP**: If the request was served from the Azure Front Door cache, the origin is **N/A**. **Large request**: If the requested content is large and there are multiple chunked requests going back to the origin, this field corresponds to the first request to the origin. For more information, see [Object Chunking](front-door-caching#delivery-of-large-files). |
| OriginName | The full hostname (DNS name) of the origin. **Cache on edge PoP**: If the request was served from the Azure Front Door cache, the origin is **N/A**. **Large request**: If the requested content is large and there are multiple chunked requests going back to the origin, this field corresponds to the first request to the origin. For more information, see [Object Chunking](front-door-caching#delivery-of-large-files). |
| Result | `SSLMismatchedSNI` is a status code that signifies a successful request with a mismatch warning between the SNI and the host header. This status code implies domain fronting, a technique that violates Azure Front Door’s terms of service. Requests with `SSLMismatchedSNI` will be rejected after January 22, 2024. |
| Sni | This field specifies the Server Name Indication (SNI) that is sent during the TLS/SSL handshake. It can be used to identify the exact SNI value if there was a `SSLMismatchedSNI` status code. Additionally, it can be compared with the host value in the `requestUri` field to detect and resolve the mismatch issue. |
### Health probe log
Azure Front Door logs every failed health probe request. These logs can help you to diagnose problems with an origin. The logs provide you with information that you can use to investigate the failure reason and then bring the origin back to a healthy status.
Some scenarios this log can be useful for are:
- You noticed Azure Front Door traffic was sent to a subset of the origins. For example, you might notice that only three out of four origins receive traffic. You want to know if the origins are receiving and responding to health probes so you know whether the origins are healthy.
- You noticed the origin health percentage metric is lower than you expected. You want to know which origins are recorded as unhealthy and the reason for the health probe failures.
Each health probe log entry has the following schema:
| Property | Description |
| --- | --- |
| HealthProbeId | A unique ID to identify the health probe request. |
| Time | The date and time when the health probe was sent (in UTC). |
| HttpMethod | The HTTP method used by the health probe request. Values include **GET** and **HEAD**, based on the health probe's configuration. |
| Result | The status of health probe. The value is either **success** or a description of the error the probe received. |
| HttpStatusCode | The HTTP status code returned by the origin. |
| ProbeURL | The full target URL to where the probe request was sent. The URL is composed of the scheme, host header, path, and query string. |
| OriginName | The name of the origin that the health probe was sent to. This field helps you to locate origins of interest if origin is configured to use an FQDN. |
| POP | The edge PoP that sent the probe request. |
| Origin IP | The IP address of the origin that the health probe was sent to. |
| TotalLatency | The time from when the Azure Front Door edge sent the health probe request to the origin to when the origin sent the last response to Azure Front Door. |
| ConnectionLatency | The time spent setting up the TCP connection to send the HTTP probe request to the origin. |
| DNSResolution Latency | The time spent on DNS resolution. This field only has a value if the origin is configured to be an FQDN instead of an IP address. If the origin is configured to use an IP address, the value is **N/A**. |
The following example JSON snippet shows a health probe log entry for a failed health probe request.
```json
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
```
## Use Azure Monitor tools to analyze the data
These Azure Monitor tools are available in the Azure portal to help you analyze monitoring data:
- Some Azure services have a built-in monitoring dashboard in the Azure portal. These dashboards are called *insights*, and you can find them in the **Insights** section of Azure Monitor in the Azure portal.
- [Metrics explorer](/en-us/azure-monitor/essentials/metrics-getting-started) allows you to view and analyze metrics for Azure resources. For more information, see [Analyze metrics with Azure Monitor metrics explorer](/en-us/azure-monitor/essentials/metrics-getting-started).
- [Log Analytics](/en-us/azure-monitor/learn/quick-create-workspace) allows you to query and analyze log data using the [Kusto query language (KQL)](/en-us/data-explorer/kusto/query). For more information, see [Get started with log queries in Azure Monitor](/en-us/azure-monitor/logs/get-started-queries).
- The Azure portal has a user interface for viewing and basic searches of the [activity log](/en-us/azure-monitor/essentials/activity-log). To do more in-depth analysis, route the data to Azure Monitor logs and run more complex queries in Log Analytics.
- [Application Insights](/en-us/azure-monitor/app/app-insights-overview) monitors the availability, performance, and usage of your web applications, so you can identify and diagnose errors without waiting for a user to report them. Application Insights includes connection points to various development tools and integrates with Visual Studio to support your DevOps processes. For more information, see [Application monitoring for App Service](/en-us/azure-monitor/app/azure-web-apps).
Tools that allow more complex visualization include:
- [Dashboards](/en-us/azure-monitor/visualize/tutorial-logs-dashboards) that let you combine different kinds of data into a single pane in the Azure portal.
- [Workbooks](/en-us/azure-monitor/visualize/workbooks-overview), customizable reports that you can create in the Azure portal. Workbooks can include text, metrics, and log queries.
- [Grafana](/en-us/azure-monitor/visualize/grafana-plugin), an open platform tool that excels in operational dashboards. You can use Grafana to create dashboards that include data from multiple sources other than Azure Monitor.
- [Power BI](/en-us/azure-monitor/logs/log-powerbi), a business analytics service that provides interactive visualizations across various data sources. You can configure Power BI to automatically import log data from Azure Monitor to take advantage of these visualizations.
## Export Azure Monitor data
You can export data out of Azure Monitor into other tools using:
- **Metrics:** Use the [REST API for metrics](https://learn.microsoft.com/rest/api/monitor/operation-groups) to extract metric data from the Azure Monitor metrics database. For more information, see [Azure Monitor REST API reference](https://learn.microsoft.com/rest/api/monitor/filter-syntax).
- **Logs:** Use the REST API or the [associated client libraries](/en-us/azure-monitor/logs/api/overview).
- **The [Log Analytics workspace data export](/en-us/azure-monitor/logs/logs-data-export?tabs=portal)**.
To get started with the Azure Monitor REST API, see [Azure monitoring REST API walkthrough](/en-us/azure-monitor/essentials/rest-api-walkthrough?tabs=portal).
## Use Kusto queries to analyze log data
You can analyze Azure Monitor Log data using the Kusto query language (KQL). For more information, see [Log queries in Azure Monitor](/en-us/azure-monitor/logs/log-query-overview).
## Use Azure Monitor alerts to notify you of issues
[Azure Monitor alerts](/en-us/azure-monitor/alerts/alerts-overview) allow you to identify and address issues in your system, and proactively notify you when specific conditions are found in your monitoring data before your customers notice them. You can alert on any metric or log data source in the Azure Monitor data platform. There are [different types of Azure Monitor alerts](/en-us/azure-monitor/alerts/alerts-types) depending on the services you're monitoring and the monitoring data you're collecting. See [Choosing the right type of alert rule](/en-us/azure-monitor/alerts/alerts-types#choosing-the-right-type-of-alert-rule).
For examples of common alerts for Azure resources, see [Sample log alert queries](/en-us/azure-monitor/alerts/alerts-log-alert-query-samples).
### Implementing alerts at scale
For some services, you can monitor at scale by applying the same metric alert rule to multiple resources of the same type that exist in the same Azure region. [Azure Monitor Baseline Alerts (AMBA)](https://azure.github.io/azure-monitor-baseline-alerts/welcome/) provides a semi-automated method of implementing important platform metric alerts, dashboards, and guidelines at scale.
## Get personalized recommendations using Azure Advisor
For some services, if critical conditions or imminent changes occur during resource operations, an alert displays on the service **Overview** page in the portal. You can find more information and recommended fixes for the alert in **Advisor recommendations** under **Monitoring** in the left menu. During normal operations, no advisor recommendations display.
For more information on Azure Advisor, see [Azure Advisor overview](/en-us/advisor/advisor-overview).