监视Azure Front Door

Azure Monitor从系统收集并聚合指标和日志，以监视可用性、性能和复原能力，并通知你影响系统的问题。可以使用 Azure 门户、PowerShell、Azure CLI、REST API 或客户端库来设置和查看监视数据。

不同的指标和日志可用于不同的资源类型。本文介绍可为此服务收集的监视数据类型以及分析这些数据的方法。

使用 Azure Monitor 收集数据

下表介绍了如何收集数据来监视服务，以及如何在收集数据后对数据执行哪些操作：

要收集的数据	Description	如何收集和路由数据	在何处查看数据	支持的数据
指标数据	指标是数值，用于描述特定时间点系统的各个方面。可以使用算法聚合指标，与其他指标进行比较，并针对一段时间内的趋势进行分析。	- 按固定时间间隔自动收集。 - 可以将某些平台指标路由到Log Analytics工作区以与其他数据一起查询。检查每个指标的 DS 导出设置，以查看是否可以使用诊断设置来路由指标数据。	指标浏览器	Azure Monitor 支持的 Azure Front Door 指标
资源日志数据	日志记录有时间戳的系统事件。日志可以包含不同类型的数据，并且可以结构化或自由格式的文本。可以将资源日志数据路由到Log Analytics工作区进行查询和分析。	创建诊断设置以收集和路由资源日志数据。	Log Analytics	Azure Monitor 支持的 Azure Front Door 资源日志数据

有关Azure Monitor支持的所有数据的列表，请参阅：

Azure Monitor支持的指标

用于Azure Front Door的内置监视

日志跟踪通过Azure Front Door传递的所有请求。处理和存储日志可能需要几分钟时间。

有多个 Front Door 日志，可用于不同的目的：

访问日志可用于识别慢速请求、确定错误率，并了解 Front Door 的缓存行为如何适用于解决方案。
运行状况探测日志可用于识别不正常或未响应来自 Front Door 某些地理分散式 PoP 的请求的原点。
活动日志提供了对执行在Azure资源上的操作的可见性，例如对Azure Front Door配置文件进行的配置更改。

访问日志

有关每个请求的信息将记录到访问日志中。每个访问日志条目都包含下表中列出的信息。

Property	Description
TrackingReference	标识Azure Front Door提供的请求的唯一引用字符串。跟踪参考通过 `X-Azure-Ref` 标头发送到客户端和源节点。在访问或 WAF 日志中搜索特定请求时，请使用跟踪引用。
Time	Azure Front Door节点将请求的内容传送到客户端的日期和时间（以UTC表示）。用于 WebSocket 连接，该时间表示连接关闭的时间。
HttpMethod	请求使用的 HTTP 方法：DELETE、GET、HEAD、OPTIONS、PATCH、POST 或 PUT。
HttpVersion	客户端在请求中指定的 HTTP 版本。
RequestUri	已收到请求的 URI。此字段包含完整方案、端口、域、路径和查询字符串。
HostName	来自客户端的请求中的主机名。如果启用自定义域并且具有通配符域 (`*.contoso.com`)，则 HostName 日志字段的值为 `subdomain-from-client-request.contoso.com`。如果使用 Azure Front Door 域（`contoso-123.z01.azurefd.net`），则 HostName 日志字段的值为 `contoso-123.z01.azurefd.net`。
RequestBytes	HTTP 请求消息的大小（以字节为单位），包括请求标头和请求正文。用于 WebSocket 连接，此值是通过连接从客户端发送到服务器的字节总数。
ResponseBytes	HTTP 响应消息的大小（以字节为单位）。用于 WebSocket 连接，此值是通过连接从服务器发送到客户端的字节总数。
UserAgent	客户端使用的用户代理。通常，用户代理会识别浏览器类型。
ClientIp	发出原始请求的客户端的 IP 地址。如果请求中有 `X-Forwarded-For` 标头，则将从标头中获取客户端 IP 地址。
SocketIp	直接连接到 Azure Front Door 边缘网络的 IP 地址。如果客户端使用 HTTP 代理或负载均衡器发送了请求，则 SocketIp 的值是该代理或负载均衡器的 IP 地址。
TimeTaken	从Azure Front Door边缘收到客户端请求到将响应的最后一个字节发送到客户端的持续时间（以秒为单位）。此指标不包括网络延迟和 TCP 缓冲。用于 WebSocket 连接，表示连接从建立到关闭期间的持续时间。
RequestProtocol	请求中客户端指定的协议。可能的值包括： HTTP、 HTTPS。对于 WebSocket，协议为 WS、 WSS。只有成功升级到 WebSocket 的请求才具有 WS/WSS。
SecurityProtocol	请求使用的 TLS/SSL 协议版本，如果请求未使用加密，则为 null。可能的值包括： SSLv3、 TLSv1、 TLSv1.1、 TLSv1.2。
SecurityCipher	当请求协议的值为 HTTPS 时，此字段指示由客户端与 Azure Front Door 协商的 TLS/SSL 加密套件。
Endpoint	Azure Front Door端点的域名，例如 `contoso-123.z01.azurefd.net`。
HttpStatusCode	从Azure Front Door返回的 HTTP 状态代码。如果对源的请求超时，则 HttpStatusCode 字段的值为 0。如果客户端关闭了连接，则 HttpStatusCode 字段的值为 499。
Pop	响应用户请求的 Azure Front Door 边缘点位（PoP）。
缓存状态	Azure Front Door缓存如何处理请求。可能的值为： HIT 和 REMOTE_HIT：HTTP 请求是从Azure Front Door缓存提供服务的。 MISS：HTTP 请求是从源提供的。 PARTIAL_HIT：一部分字节是从前门边缘 PoP 缓存提供的，另一部分字节则是从源服务器提供的。此状态指示对象分块方案。 CACHE_NOCONFIG：请求在未设置缓存的情况下被转发，包括绕过场景。 PRIVATE_NOSTORE：客户未在缓存设置中配置缓存。 N/A：已签名的 URL 或 WAF 规则拒绝了请求。
MatchedRulesSetName	已处理的规则引擎规则的名称。
RouteName	请求匹配的路由的名称。
ClientPort	发出请求的客户端的 IP 端口。
Referrer	发起请求的站点的 URL。
TimetoFirstByte	从Azure Front Door边缘收到请求到返回第一个字节给客户端的时间长度（以秒为单位），由Azure Front Door测量。此属性不测量客户端数据。
ErrorInfo	如果在处理请求期间发生错误，则此字段会提供有关错误的详细信息。可能的值为： NoError：指示未找到错误。 CertificateError：通用 SSL 证书错误。 CertificateNameCheckFailed：SSL 证书中的主机名无效或与请求的 URL 不匹配。 ClientDisconnected：由于客户端网络连接问题，请求失败。 ClientGeoBlocked：由于 IP 地址的地理位置，客户端被阻止。 UnspecifiedClientError：泛型客户端错误。 InvalidRequest：请求无效。此响应指示标头、正文或 URL 格式不正确。 DNSFailure：DNS 解析期间发生故障。 DNSTimeout：用于解析源 IP 地址的 DNS 查询超时。 DNSNameNotResolved：无法解析服务器名称或地址。 OriginConnectionAborted：与源的连接异常断开。 OriginConnectionError：泛型源连接错误。 OriginConnectionRefused：未建立与源的连接。 OriginError：泛型源错误。 ResponseHeaderTooBig：源返回的响应标头太大。 OriginInvalidResponse：源返回无效或无法识别的响应。 OriginTimeout：源请求的超时期限已过期。 ResponseHeaderTooBig：源返回的响应标头太大。 RestrictedIP：由于 IP 地址受限，请求被阻止。 SSLHandshakeError：Azure Front Door由于 SSL 握手失败而无法与源端建立连接。 SSLInvalidRootCA：根证书颁发机构的证书无效。 SSLInvalidCipher：使用无效密码建立 HTTPS 连接。 OriginConnectionAborted：与源的连接异常断开。 OriginConnectionRefused：未建立与源的连接。 UnspecifiedError：发生错误，该错误不属于表中的任何错误。
OriginURL	发送请求的源的完整 URL。 URL 由方案、主机头、端口、路径和查询字符串构成。 URL 重写：如果规则引擎重写请求 URL，则路径引用重写的路径。边缘 PoP 的缓存：如果请求是从 Azure Front Door 缓存中提供的，源为 N/A。大型请求：如果请求的内容很大，并且有多个分块请求返回到源，则此字段对应于对源的第一个请求。有关详细信息，请参阅对象分块。
OriginIP	为请求提供服务的源的 IP 地址。在边缘 PoP 上缓存：如果请求是由 Azure Front Door 缓存提供的，则源为 N/A。大型请求：如果请求的内容很大，并且有多个分块请求返回到源，则此字段对应于对源的第一个请求。有关详细信息，请参阅对象分块。
OriginName	源的完整主机名（DNS 名称）。边缘 PoP 上的 Cache：如果从Azure Front Door缓存提供请求，则源为 N/A。大型请求：如果请求的内容很大，并且有多个分块请求返回到源，则此字段对应于对源的第一个请求。有关详细信息，请参阅对象分块。
Result	`SSLMismatchedSNI` 是一个状态代码，表示请求成功，但 SNI 和主机标头之间存在不匹配警告。此状态代码表示域名前置，这是一项违反 Azure Front Door 服务条款的技术。 2024 年 1 月 22 日之后，通过 `SSLMismatchedSNI` 提出的请求将被拒绝。
Sni	此字段指定在 TLS/SSL 握手期间发送的服务器名称指示 (SNI)。如果存在 `SSLMismatchedSNI` 状态代码，则它可用于标识确切的 SNI 值。此外，可以将其与 `requestUri` 字段中的主机值进行比较，以检测并解决不匹配问题。

运行状况探测日志

Azure Front Door记录每个失败的运行状况探测请求。这些日志可帮助你诊断源问题。 你可以使用日志提供的信息来调查失败原因，然后将源恢复为正常状态。

此日志可发挥作用的部分场景包括：

你注意到Azure Front Door的流量被发送到起源的子集。例如，你可能会注意到，四个源中只有三个接收流量。你想知道源服务器是否正在接收和响应运行状况探测信号，以便确定源服务器是否正常。
你注意到原始健康百分比指标低于预期。你想知道哪些源记录为不正常，以及运行状况探测失败的原因。

每个运行状况探测日志条目采用以下模式：

Property	Description
HealthProbeId	用于标识系统运行状况探测请求的唯一标识符。
Time	发送运行状况探测的日期和时间 (UTC)。
HttpMethod	运行状况探测请求使用的 HTTP 方法。值包括 GET 和 HEAD，具体取决于运行状况探测的配置。
Result	健康探针的状态。该值要么是成功，要么是探测收到的错误说明。
HttpStatusCode	源返回的 HTTP 状态代码。
ProbeURL	探测请求发送至的完整目标 URL。 URL 由方案、主机头、路径和查询字符串组成。
OriginName	健康探测发送到的目标的名称。如果源配置为使用 FQDN，则此字段可帮助你查找相关的源。
POP	发送探测请求的边缘 PoP。
** 源 IP	健康检查发送到的源站 IP 地址。
TotalLatency	从 Azure Front Door 边缘发送健康探测请求到源节点，再到源节点发送最后响应到 Azure Front Door 的这段时间。
ConnectionLatency	设置 TCP 连接以将 HTTP 探测请求发送到源所用的时间。
DNS解析延迟	DNS 解析所用的时间。仅当源配置为 FQDN 而不是 IP 地址时，此字段才具有值。如果源配置为使用 IP 地址，则值为 N/A。

以下示例 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"
      }
    }
  ]
}

使用Azure Monitor工具分析数据

Azure门户中提供了这些Azure Monitor工具，可帮助你分析监视数据：

某些Azure服务在Azure门户中有一个内置的监视仪表板。这些仪表板称为 insights，可以在Azure门户中的 Azure Monitor Insights 部分找到它们。
Metrics 资源管理器允许查看和分析Azure资源的指标。有关详细信息，请参阅使用 Azure Monitor 指标资源管理器分析指标。
Log Analytics允许使用 Kusto 查询语言（KQL）查询和分析日志数据。有关详细信息，请参阅在 Azure Monitor 中开始日志查询。
Azure门户网站具有用于查看和基本搜索活动日志的用户界面。若要进行更深入的分析，将数据路由到Azure Monitor日志，并在Log Analytics中运行更复杂的查询。
Application Insights 监视 Web 应用程序的可用性、性能和使用情况，因此你可以确定并诊断错误，而无需等待用户报告这些错误。
Application Insights 包括与各种开发工具的连接点，并与 Visual Studio 集成以支持 DevOps 流程。有关详细信息，请参阅应用服务的应用程序监控。

支持更复杂可视化效果的工具包括：

Dashboards，使你能够将不同类型的数据合并到Azure门户中的单个窗格中。
Workbooks，可以在Azure门户中创建的可自定义报表。工作簿可以包括文本、指标和日志查询。
Grafana，它是一个适用于操作仪表板的开放平台工具。可以使用 Grafana 创建仪表板，其中包含来自除Azure Monitor以外的多个源的数据。
Power BI，这是一项业务分析服务，用于跨各种数据源提供交互式可视化效果。可以将Power BI配置为从Azure Monitor自动导入日志数据，以利用这些可视化效果。

导出Azure Monitor数据

可以使用以下方法将数据从Azure Monitor导出到其他工具：

Metrics： 使用 REST API 从 Azure Monitor 指标数据库中提取指标数据。有关详细信息，请参阅 Azure Monitor REST API 参考。
日志：使用 REST API 或关联的客户端库。
Log Analytics 工作区数据导出。

若要开始使用 Azure Monitor REST API，请参阅Azure监视 REST API 演练。

使用 Kusto 查询来分析日志数据

可以使用 Kusto 查询语言（KQL）分析Azure Monitor日志数据。有关详细信息，请参阅 Azure Monitor 中的 Log 查询。

使用 Azure Monitor 警报通知您出现的问题

Azure Monitor警报使你能够识别和解决系统中的问题，并在客户注意到它们之前在监视数据中找到特定条件时主动通知你。可以在Azure Monitor数据平台中针对任何指标或日志数据源发出警报。有不同类型的 Azure Monitor 警报，根据您正在监视的服务和收集的监视数据而定。请参阅选择正确的警报规则类型。

有关Azure资源的常见警报示例，请参阅 Sample 日志警报查询。

大规模部署警报系统

对于某些服务，可以通过将相同的指标警报规则应用于同一Azure区域中存在的多个同一类型的资源来大规模监视。 Azure Monitor基线警报（AMBA）提供了一种半自动化的方法，用于大规模实现重要的平台指标警报、仪表板和指南。

使用Azure 顾问获取个性化建议

对于某些服务，如果在资源操作期间出现严重情况或即将发生变化，则门户中的服务“概述”页面上会显示一个警报。可以在左侧“监视”下的“顾问建议”中找到警报的详细信息和建议的修复方法。在正常操作期间，不会显示任何顾问建议。

有关Azure 顾问的详细信息，请参阅 Azure 顾问概述。

Last updated on 2026-04-15

Compartir a través de