你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
监视 Azure Front Door
Azure Monitor 从系统收集并聚合指标和日志，以监视可用性、性能和复原能力，并通知你影响系统的问题。 可以使用 Azure 门户、PowerShell、Azure CLI、REST API 或客户端库来设置和查看监视数据。
不同的指标和日志可用于不同的资源类型。 本文介绍可为此服务收集的监视数据类型以及分析这些数据的方法。
报告提供有关流量如何流经 Azure Front Door、Web 应用程序防火墙 (WAF) 以及应用程序的见解。
重要
Azure Front Door（经典版）将于 2027 年 3 月 31 日停用。 为了避免任何服务中断，请务必在 2027 年 3 月之前将 Azure Front Door（经典版）配置文件迁移到 Azure Front Door 标准层或高级层。 有关详细信息，请参阅 Azure Front Door（经典版）停用。
使用 Azure Monitor 收集数据
下表介绍了如何收集数据来监视服务，以及收集到的数据可以做些什么：
| 要收集的数据 | 说明 | 如何收集和路由数据 | 查看数据的位置 | 支持的数据 |
|---|---|---|---|---|
| 指标数据 | 指标是数字值，用于描述系统某个方面在特定时间点的情况。 可以使用算法来聚合指标、将其与其他指标进行比较，以及通过分析指标来了解一段时间内的趋势。 | - 定期自动收集。 - 你可以将某些平台指标路由到 Log Analytics 工作区，以使用其他数据进行查询。 检查每个指标的“DS 导出”设置，查看是否可以使用诊断设置来路由指标数据。 |
指标资源管理器 | Azure Monitor 支持的 Azure Front Door 指标 |
| 资源日志数据 | 日志是记录的具有时间戳的系统事件。 日志可包含不同类型的数据，可以结构化或采用自由文本格式。 可以将资源日志数据路由到 Log Analytics 工作区进行查询和分析。 | 创建诊断设置以收集和路由资源日志数据。 | Log Analytics | Azure Monitor 支持的 Azure Front Door 资源日志数据 |
| 活动日志数据 | Azure Monitor 活动日志提供关于订阅级事件的见解。 活动日志包括何时修改了资源或何时启动了虚拟机等信息。 | - 自动收集。 - 免费为 Log Analytics 工作区创建诊断设置。 |
活动日志 |
有关 Azure Monitor 支持的所有数据的列表，请参阅：
适用于 Azure Front Door 的内置监视功能
日志会跟踪通过 Azure Front Door 传递的所有请求。 处理和存储日志可能需要几分钟时间。
有多个 Front Door 日志，可用于不同的目的：
- 访问日志可用于识别慢速请求、确定错误率，以及了解 Front Door 的缓存行为如何适用于你的解决方案。
- Web 应用程序防火墙 (WAF) 日志可用于检测潜在攻击，以及可能指示 WAF 阻止的合法请求的误报检测。 有关 WAF 日志的详细信息，请参阅 Azure Web 应用程序防火墙监视和日志记录。
- 运行状况探测日志可用于识别不正常或未响应来自 Front Door 某些地理分散式 PoP 的请求的原点。
- 活动日志提供对 Azure 资源执行的操作的可见性，例如对 Azure Front Door 配置文件的配置更改。
访问日志和 Web 日志包括跟踪引用，它也使用 X-Azure-Ref 标头在对原点和客户端响应的请求中传播。 你可以使用跟踪引用来端到端了解应用程序请求处理。
默认未启用访问日志、运行状况探测日志和 WAF 日志。 若要启用和存储诊断日志，请参阅配置 Azure Front Door 日志。 默认情况下会收集活动日志条目，可在 Azure 门户中查看这些条目。
访问日志
有关每个请求的信息将记录到访问日志中。 每个访问日志条目都包含下表中列出的信息。
| 属性 | 说明 |
|---|---|
| TrackingReference | 这是唯一的引用字符串，用于识别 Azure Front Door 处理的请求。 跟踪引用是使用 X-Azure-Ref 标头发送到客户端和原点的。 在访问或 WAF 日志中搜索特定请求时，请使用跟踪引用。 |
| 时间 | 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 密码。 |
| 终结点 | 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 缓存如何处理请求。 可能的值为：
|
| MatchedRulesSetName | 已处理的规则引擎规则的名称。 |
| RouteName | 请求匹配的路由的名称。 |
| ClientPort | 发出请求的客户端的 IP 端口。 |
| Referrer | 发起请求的站点的 URL。 |
| TimetoFirstByte | 从 Azure Front Door 边缘收到请求到将第一个字节发送给客户端所经历的时长，以秒为单位，由 Azure Front Door 衡量。 此属性不测量客户端数据。 |
| ErrorInfo | 如果在处理请求期间发生错误，则此字段会提供有关错误的详细信息。 可能的值为：
|
| OriginURL | 发送请求的源的完整 URL。 URL 由方案、主机头、端口、路径和查询字符串构成。 URL 重写：如果规则引擎重写请求 URL，则路径是指重写的路径。 在边缘 PoP 上缓存：如果请求是从 Azure Front Door 缓存提供的，则源为 N/A。 大请求：如果请求的内容很大，并且有多个分块请求返回到源，则此字段将对应于向源发出的第一个请求。 有关详细信息，请参阅对象区块。 |
| OriginIP | 为请求提供服务的源的 IP 地址。 在边缘 PoP 上缓存：如果请求是从 Azure Front Door 缓存提供的，则源为 N/A。 大请求：如果请求的内容很大，并且有多个分块请求返回到源，则此字段将对应于向源发出的第一个请求。 有关详细信息，请参阅对象区块。 |
| OriginName | 源的完整主机名（DNS 名称）。 在边缘 PoP 上缓存：如果请求是从 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 流量只是发送到了一部分源。 例如，你可能会注意到，四个源中只有三个接收流量。 你想知道源是否正在接收和响应运行状况探测，以便知道源是否正常。
- 你注意到源运行状况百分比指标低于预期。 你想知道哪些源记录为不正常，以及运行状况探测失败的原因。
每个运行状况探测日志项目采用以下架构：
| 属性 | 说明 |
|---|---|
| HealthProbeId | 用于标识运行状况探测请求的唯一 ID。 |
| 时间 | 发送运行状况探测的日期和时间 (UTC)。 |
| HttpMethod | 运行状况探测请求使用的 HTTP 方法。 值包括 GET 和 HEAD，具体取决于运行状况探测的配置。 |
| 结果 | 运行状况探测的状态。 值是 success 或探测收到的错误的说明。 |
| HttpStatusCode | 源返回的 HTTP 状态代码。 |
| ProbeURL | 探测请求发送到的完整目标 URL。 URL 由方案、主机头、路径和查询字符串组成。 |
| OriginName | 运行状况探测发送到的源的名称。 如果源配置为使用 FQDN，则此字段可帮助你查找相关的源。 |
| POP | 发送探测请求的边缘 PoP。 |
| 原始 IP | 运行状况探测发送到的源的 IP 地址。 |
| TotalLatency | 从 Azure Front Door 边缘将运行状况探测请求发送给原点到原点向 Azure Front Door 发送最后一个响应所经历的时间。 |
| ConnectionLatency | 设置 TCP 连接以将 HTTP 探测请求发送到源所用的时间。 |
| DNSResolution Latency | 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"
}
}
]
}
Web 应用程序防火墙日志
有关 Front Door Web 应用程序防火墙 (WAF) 日志的详细信息，请参阅 Azure Web 应用程序防火墙监视和日志记录。
对于经典版 Azure Front Door，内置监视功能包括诊断日志。
诊断日志
诊断日志提供了大量有关操作和错误的信息，这些信息对于审核和故障排除非常重要。 诊断日志不同于活动日志。
活动日志让你能够了解对 Azure 资源执行的操作。 诊断日志可用于深入了解资源执行的操作。 有关详细信息，请参阅 Azure Monitor 诊断日志。
若要为 Azure Front Door（经典）配置诊断日志，请执行以下操作：
选择你的 Azure Front Door（经典）配置文件。
选择“诊断设置”。
选择“启用诊断”。 将诊断日志与指标一起存档到存储帐户，将其流式传输到事件中心，或者将其发送到 Azure Monitor 日志。
Front Door 目前提供诊断日志。 诊断日志提供单独的 API 请求，其中每个条目具有以下架构：
| 属性 | 说明 |
|---|---|
| BackendHostname | 如果请求被转发到后端，则此字段表示后端的主机名。 如果在为传递规则启用缓存时，请求将被重定向或转发到区域缓存，则此字段为空。 |
| CacheStatus | 对于缓存方案，此字段定义在 POP 处的缓存命中/未命中情况 |
| ClientIp | 发出请求的客户端的 IP 地址。 如果请求中包含 X-Forwarded-For 头，则从同一个头中获取客户端 IP。 |
| ClientPort | 发出请求的客户端的 IP 端口。 |
| HttpMethod | 请求使用的 HTTP 方法。 |
| HttpStatusCode | 从代理返回的 HTTP 状态代码。 如果对源的请求超时，则 HttpStatusCode 的值将设置为“0”。 |
| HttpStatusDetails | 请求的结果状态。 此字符串值的含义可以在状态引用表中找到。 |
| HttpVersion | 请求或连接的类型。 |
| POP | 请求着陆的边缘的短名称。 |
| RequestBytes | HTTP 请求消息的大小（以字节为单位），包括请求标头和请求正文。 |
| RequestUri | 已收到请求的 URI。 |
| ResponseBytes | 后端服务器作为响应发送的字节数。 |
| RoutingRuleName | 请求匹配的传递规则的名称。 |
| RulesEngineMatchNames | 请求匹配的规则的名称。 |
| SecurityProtocol | 请求所使用的 TLS/SSL 协议版本，如果没有加密，则为 null。 |
| SentToOriginShield （已弃用）* 请参阅以下部分中的弃用说明。 |
如果为 true，则表示请求是从源防护缓存（而不是边缘 pop）响应的。 源防护是用于提高缓存命中率的父缓存。 |
| isReceivedFromClient | 如果为 true，则表示请求来自客户端。 如果为 false，则请求在边缘（子 POP）未命中，并从源盾牌（父 POP）进行响应。 |
| TimeTaken | 从请求的第一个字节传入 Front Door 到响应的最后一个字节传出 Front Door 的时间长度（以秒为单位）。 |
| TrackingReference | 标识由 Front Door 提供的请求的唯一引用字符串，该请求还会以 X-Azure-Ref 标头的形式发送到客户端。 是搜索特定请求访问日志中的详细信息必需的。 |
| UserAgent | 客户端使用的浏览器类型。 |
| ErrorInfo | 此字段包含特定类型的错误，以便进一步进行故障排除。
可能的值包括： NoError：表示未发现任何错误。 CertificateError：常规 SSL 证书错误。 CertificateNameCheckFailed：SSL 证书中的主机名无效或不匹配。 ClientDisconnected：客户端网络连接问题导致请求失败。 UnspecifiedClientError：常规客户端错误。 InvalidRequest：请求无效。 此错误的可能原因是标头、正文和 URL 格式不正确。 DNSFailure：DNS 故障。 DNSNameNotResolved：无法解析服务器名称或地址。 OriginConnectionAborted：与源的连接突然断开。 OriginConnectionError：常规源连接错误。 OriginConnectionRefused：无法与源建立连接。 OriginError：常规源错误。 OriginInvalidResponse：源返回的响应无效或无法识别。 OriginTimeout：超过了源请求的超时期限。 ResponseHeaderTooBig：源返回的响应头过大。 RestrictedIP：由于 IP 受限而阻止了请求。 SSLHandshakeError：由于 SSL 握手失败，无法与源建立连接。 UnspecifiedError：发生了与表中任何错误都不相符的错误。 SSLMismatchedSNI：请求无效，因为 HTTP 消息标头与 SSL/TLS 连接设置期间 TLS SNI 扩展中显示的值不符。 |
| Result |
SSLMismatchedSNI 是一个状态代码，表示请求成功，但 SNI 和主机标头之间存在不匹配警告。 此状态代码意味着域前置，这是一种违反 Azure Front Door 条款的技术。 2024 年 1 月 22 日之后，通过 SSLMismatchedSNI 提出的请求将被拒绝。 |
| Sni | 此字段指定在 TLS/SSL 握手期间发送的服务器名称指示 (SNI)。 如果存在 SSLMismatchedSNI 状态代码，则它可用于标识确切的 SNI 值。 此外，可以将其与 requestUri 字段中的主机值进行比较，以检测并解决不匹配问题。 |
发送到源盾牌弃用
原始日志属性 isSentToOriginShield 已弃用，并已替换为新的字段 isReceivedFromClient。 如果正在使用弃用的字段，请改为使用新字段。
原始日志包括从 CDN 边缘（子 POP）和源盾牌生成的日志。 源盾牌是指位于全球各地的战略性父节点。 这些节点与源服务器通信，可减少源上的流量负载。
对于传至源盾牌的每个请求，都有两个日志项目：
- 一个传至边缘节点
- 一个对应源盾牌
要区分边缘节点与源盾牌的流出或响应，可以使用字段 isReceivedFromClient 来获取正确数据。
如果值为 false，则表示该请求是从源盾牌到边缘节点的响应。 这种方法用来比较原始日志与账单数据非常有效。 从源盾牌向边缘节点流出不会产生费用。 从边缘节点向客户端流出却会产生费用。
Kusto 查询示例，不包括在 Log Analytics 的源盾牌上生成的日志。
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
注意
对于各种路由配置和流量行为，某些字段（如 backendHostname、cacheStatus、isReceivedFromClient 和 POP 字段）可能会用不同的值来响应。 下表说明了这些字段在各种情况下将具有的不同值：
| 方案 | 日志项计数 | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| 未启用缓存的传递规则 | 1 | 边缘 POP 代码 | 请求被转发到的后端 | True | CONFIG_NOCACHE |
| 启用缓存的传递规则。 缓存命中边缘 POP | 1 | 边缘 POP 代码 | 空 | True | HIT |
| 启用缓存的传递规则。 缓存未命中边缘 POP，但命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 父缓存 POP 主机名 2. 空 |
1. True 2. False |
1. MISS 2. HIT |
| 启用缓存的传递规则。 缓存未命中边缘 POP，但部分缓存命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 父缓存 POP 主机名 2. 帮助填充缓存的后端 |
1. True 2. False |
1. MISS 2. PARTIAL_HIT |
| 启用缓存的传递规则。 缓存部分命中边缘 POP，但命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. True 2. False |
1. PARTIAL_HIT 2. HIT |
| 启用缓存的传递规则。 缓存未命中边缘和父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. True 2. False |
1. MISS 2. MISS |
| 处理请求时出错 | 空值 |
注意
对于大型对象的缓存方案，如果请求的部分字节来自 Azure Front Door 边缘缓存或源盾牌缓存，部分字节来自源，则缓存状态的值为 PARTIAL_HIT。
Azure Front Door 使用一种被称作对象区块的技术。 请求大型文件时，Azure Front Door 会从源检索文件的较小部分。 在 Azure Front Door POP 服务器收到请求的文件的完整范围或字节范围后，Azure Front Door 边缘服务器会以 8 MB 的区块从源请求文件。
区块到达 Azure Front Door 边缘后，会将区块缓存并立即提供给用户。 然后，Azure Front Door 会并行预提取下一个区块。 此预提取可确保内容先于用户一个区块，这可以减少延迟。 此过程将继续，直到整个文件下载完成（如果已请求），所有字节范围都可用（如果已请求），或客户端关闭连接。 有关字节范围请求的详细信息，请参阅 RFC 7233。 Azure Front Door 会在收到区块后进行缓存。 无需在 Front Door 缓存上缓存整个文件。 随后从 Azure Front Door 缓存中请求文件或字节范围的请求。 如果未在 Azure Front Door 上缓存所有区块，将使用预提取从源请求区块。 此优化取决于源服务器能否支持字节范围请求。 如果源服务器不支持字节范围请求，则此优化不会生效。
使用 Azure Monitor 工具分析数据
Azure 门户中提供了以下 Azure Monitor 工具，可帮助你分析监视数据：
某些 Azure 服务在 Azure 门户中具有内置的监视仪表板。 这些仪表板称为“见解”，可以在 Azure 门户的 Azure Monitor 的“见解”部分找到它们。
指标资源管理器可用于查看和分析 Azure 资源的指标。 有关详细信息，请参阅使用 Azure Monitor 指标资源管理器分析指标。
Log Analytics 支持使用 Kusto 查询语言 (KQL) 来查询和分析日志数据。 有关详细信息，请参阅 Azure Monitor 日志查询入门。
Azure 门户具有用于执行活动日志查看和基本搜索的用户界面。 要进行更深入的分析，请将数据路由到 Azure Monitor 日志，并在 Log Analytics 中运行更复杂的查询。
Application Insights 监视 Web 应用程序的可用性、性能和使用情况，因此你可以确定并诊断错误，而无需等待用户报告这些错误。
Application Insights 包含各种开发工具的连接点，并与 Visual Studio 集成以支持 DevOps 过程。 有关详细信息，请参阅应用服务的应用程序监视。
支持更复杂可视化效果的工具包括：
- 仪表板，它支持将不同类型的数据合并到 Azure 门户的单个窗格中。
- 工作簿，它们是可在 Azure 门户中创建的可自定义报表。 工作簿可以包括文本、指标和日志查询。
- Grafana，它是一个适用于操作仪表板的开放平台工具。 可以使用 Grafana 创建包含来自除 Azure Monitor 以外多个源的数据的仪表板。
- Power BI，它是一项业务分析服务，可提供跨各种数据源的交互式可视化效果。 可将 Power BI 配置为自动从 Azure Monitor 导入日志数据，以利用这些可视化效果。
导出 Azure Monitor 数据
可以使用以下方法将数据从 Azure Monitor 导出到其他工具：
指标：使用适用于指标的 REST API 从 Azure Monitor 指标数据库提取指标数据。 有关详细信息，请参阅 Azure Monitor REST API 参考。
日志：使用 REST API 或关联的客户端库。
要开始使用 Azure Monitor REST API，请参阅 Azure 监视 REST API 演练。
使用 Kusto 查询分析日志数据
可以使用 Kusto 查询语言 (KQL) 分析 Azure Monitor 日志数据。 有关详细信息，请参阅 Azure Monitor 中的日志查询。
使用 Azure Monitor 警报通知问题
Azure Monitor 警报允许你识别和解决系统中的问题，并在监视数据中观察到特定情况时在客户注意到之前主动通知你。 可以针对 Azure Monitor 数据平台中的任何指标或日志数据源发出警报。 有不同类型的 Azure Monitor 警报，具体取决于要监视的服务以及要收集的监视数据。 请参阅选择正确的警报规则类型。
有关 Azure 资源常见警报的示例，请参阅示例日志警报查询。
大规模实现警报
对于某些服务，你可以通过将相同的指标警报规则应用于同一 Azure 区域中的多个相同类型资源，进行大规模的监视。 Azure Monitor 基线警报 (AMBA) 提供了大规模实现重要平台指标警报、仪表板和指南的半自动化方法。
使用 Azure 顾问获取个性化建议
对于某些服务，如果在资源操作期间出现严重情况或即将发生变化，则门户中的服务“概述”页面上会显示一个警报。 可以在左侧菜单“监视”下的“顾问建议”中找到警报的详细信息和建议补丁。 在正常操作期间，不会显示任何顾问建议。
有关 Azure 顾问的详细信息，请参阅 Azure 顾问概述。