Azure Monitor 服务限制
本文列出了 Azure Monitor 在不同区域中的限制。
警报
| 资源 | 默认限制 | 最大限制 |
|---|---|---|
| 指标警报（经典） | 每个订阅 100 个活动警报规则。 经典警报已对公有云用户停用。 由世纪互联运营的 Microsoft Azure 的经典警报将于 2024 年 2 月 29 日停用。 |
致电支持人员。 |
| 指标警报 | 由世纪互联运营的 Microsoft Azure 中每个订阅 5,000 个活动警报规则。 如果达到此限制，请查看你是否可使用同类型多资源警报。 每条警报规则 5,000 个指标时序。 |
致电支持人员。 |
| 活动日志警报 | 每个订阅 100 个活动预警规则（无法增加数量）。 由于无法提高此限制，因此如果每个订阅需要更多规则，请考虑改为将活动日志发送到 Log Analytics 工作区并创建日志搜索警报。 |
与默认值相同。 |
| 日志警报 | 每个订阅 5,000 个活动警报规则。 其中 100 个活动警报规则的频率为 1 分钟。 每项资源 1,000 个活动警报规则。 每个无状态警报规则每次评估最多可以触发 6,000 个警报。 每个有状态警报规则每次评估最多可以触发 300 个警报。 一次最多触发 5,000 个有状态警报。 日志警报规则属性中所有数据的总大小不能超过 64KB。 Kusto 查询结果不能超过 20 MB。 |
致电支持人员。 |
| 警报处理规则 | 每个订阅 1,000 个活动规则。 | 致电支持人员。 |
| 警报规则和警报处理规则说明长度 | 日志搜索警报 4,096 个字符。 所有其他 2,048 个字符。 |
与默认值相同。 |
警报 API
Azure Monitor 警报有几个限制，可防止用户进行过多的调用。 这种行为可能会重载系统后端资源，并危害服务响应能力。 以下限制旨在防止客户中断，并确保服务级别一致。 用户带宽限制和上限的设计旨在仅影响极端使用情况， 不应与典型使用情况相关。
注意
每个实例的 API 调用数量有限制。 确切的限制数量取决于实例数。
| 资源 | 默认限制 | 最大限制 |
|---|---|---|
| 警报 - 获取摘要 | 每个订阅每分钟 50 次调用 | 与默认值相同 |
| 警报 - 获取全部（不是“按 ID 获取”） | 每个订阅每分钟 100 次调用 | 与默认值相同 |
| 所有其他警报调用 | 每个订阅每分钟 1,000 次调用 | 与默认值相同 |
操作组
一个订阅中可以有无限数量的操作组。
| 资源 | 默认限制 | 最大限制 |
|---|---|---|
| 电子邮件 | 一个操作组中有 1,000 个电子邮件操作。 每个电子邮件地址每个区域每小时不超过 100 封电子邮件 电子邮件地址中的字符限制为 64。 电子邮件中的字符限制为 55296。 另请参阅速率限制信息。 |
与默认值相同 |
| 向 Azure 资源管理器角色发送电子邮件 | 每个操作组 10 个电子邮件 ARM 角色操作。 在生产中：一小时内每个区域最多 100 封电子邮件。 在测试操作组中：每 (1) 分钟不超过 2 封电子邮件。 |
与默认值相同 |
| 事件中心 | 每个操作组 10 个事件中心操作。 | 与默认值相同 |
| 逻辑应用 | 一个操作组中有 10 个逻辑应用操作。 | 与默认值相同 |
| Runbook | 一个操作组中有 10 个 runbook 操作。 | 与默认值相同 |
| 安全 Webhook | 一个操作组中有 10 个安全 Webhook 操作。 每个订阅最大 Webhook 调用次数为每分钟 1500 次。 | 与默认值相同 |
| SMS | 一个操作组中有 10 个短信操作。 在生产环境中：每 5 分钟不超过 1 条短信。 在测试操作组中：每分钟不超过 1 条短信。 |
与默认值相同 |
| Webhook | 一个操作组中有 10 个 Webhook 操作。 每个订阅最大 Webhook 调用次数为每分钟 1500 次。 | 与默认值相同 |
自动缩放
| 资源 | 默认限制 | 最大限制 |
|---|---|---|
| 自动缩放设置 | 每个订阅每个区域 100 个。 | 与默认值相同 |
| 自动缩放配置文件 | 每个自动缩放设置 20 个配置文件。 | 与默认值相同 |
Prometheus 指标
引流
Azure 托管的 Prometheus 是一个不区分大小写的系统。 如果字符串（例如指标名称、标签名称或标签值）与另一个时序的区别仅在于字符串的大小写，则它会将这些字符串视为相同的时序。 有关详细信息，请参阅 Prometheus 指标概述。
以下限制适用于引入 Prometheus 指标的 Azure Monitor 工作区。
| 限制 | 值 |
|---|---|
| 活动时序，其中包含过去约 12 小时内报告的指标。 | 1,000,000 可以请求提高限制。 |
| 每分钟引入的事件数。 | 1,000,000 可以请求提高限制。 |
以下限制适用于将 Prometheus 指标数据发送到 Azure Monitor 工作区的数据收集规则 (DCR) 和数据收集终结点 (DCE)。
| 限制 | 值 |
|---|---|
| 数据收集终结点的每分钟引入请求数 | 15,000 此限制不能提高。 |
| 数据收集终结点的每分钟数据引入量 | 50 GB 此限制不能提高。 |
查询
Prometheus 查询使用 PromQL 进行创建，并可在 Azure 托管 Grafana 或自托管 Grafana 中创作。
| 限制 | 值 |
|---|---|
| 数据保留 | 18 个月。 此限制不能提高。 |
| 查询时间范围 | PromQL 查询的开始时间和结束时间之间的 32 天。 此限制不能提高。 |
| 每个指标的查询时序 | 500,000 个时序。 |
| 返回的查询示例 | 每个查询 50,000,000 个示例。 |
| 最小查询步骤大小 时间范围 >= 48 小时 |
60 秒。 |
查询数据限制
对于客户端流量：
| 限制 | 值 |
|---|---|
| 限制窗口查找长度 | 30 秒 |
| 每个 Azure Monitor 工作区返回的数据 | 0.5 GB |
对于记录规则流量：
| 限制 | 值 |
|---|---|
| 限制窗口查找长度 | 3 分钟 |
| 每个 Azure Monitor 工作区返回的数据 | 1 GB |
查询预分析限制
基于 30 秒时段内的查询时间范围和请求类型（适用于客户端流量）：
| 限制 | 值 |
|---|---|
| 每个用户（Microsoft Entra ID、托管标识、Azure 托管 Grafana 工作区）的查询小时数 | 30,000 |
| 每个 Azure Monitor 工作区的查询小时数 | 60,000 |
| 每个 Azure 租户的查询小时数 | 600,000 |
基于 3 分钟时段内的查询时间范围和请求类型（适用于记录规则流量）：
| 限制 | 值 |
|---|---|
| 每个 Azure Monitor 工作区的查询小时数 | 60,000 |
| 每个 Azure 租户的查询小时数 | 600,000 |
查询分析后限制
基于 30 秒时段内查询中的查询时间范围和范围矢量（适用于客户端流量）：
| 限制 | 值 |
|---|---|
| 每个用户（Microsoft Entra ID、托管标识、Azure 托管 Grafana 工作区）的查询小时数 | 2,000,000 |
| 每个 Azure Monitor 工作区的查询小时数 | 2,000,000 |
| 每个 Azure 租户的查询小时数 | 20,000,000 |
基于 3 分钟时段内查询中的查询时间范围和范围矢量（适用于记录规则流量）：
| 限制 | 值 |
|---|---|
| 每个 Azure Monitor 工作区的查询小时数 | 2,000,000 |
| 每个 Azure 租户的查询小时数 | 20,000,000 |
查询成本限制
| 限制 | 值 |
|---|---|
| 每个查询的最大查询成本 | 15000 |
| 记录规则查询的最大查询成本 | 3000 |
查询成本计算如下：
查询成本 =（请求的时序数 *（查询持续时间（秒）/ 查询的数据的推断时间解析度））/ 5000
查询的数据的推断时间解析度 = 在查询的指标的任意一个随机选择的时间序列键中存储的数据点数 / 查询持续时间（秒）
警报和记录规则
Prometheus 警报规则和记录规则是在 PromQL 中定义的。 并作为适用于 Prometheus 的 Azure Monitor 托管服务的一部分在托管标尺服务上执行。
| 限制 | 值 |
|---|---|
| Azure 订阅中每个 Azure Monitor 工作区的规则组数 | 500 可以请求提高限制。 |
| 每个规则组的规则数 | 20 此限制不能提高。 |
| 规则组评估间隔 | 介于 1 分钟 - 24 小时之间。 默认值为 1 分钟。 |
| 活动警报 | 目前没有限制。 |
远程写入
使用默认的远程批处理大小 500 确定计算结果。
| 限制 | 值 |
|---|---|
| CPU 使用率 | 0.25 x（指标数）+ 1.25 x（每个指标平均时序数） |
| CPU 请求 | 0.75 x（CPU 使用率） |
| CPU 限制 | 2 x（CPU 请求） |
| 内存请求 | 150 MB |
| 内存限制 | 200 MB |
| 最大吞吐量 | 远程写入容器最多可以处理 150,000 个唯一时序。 容器可能会在处理超过 150,000 个请求时（由于并发连接数较高）引发错误。 通过将远程批处理大小从 500 增加到 1,000，可以缓解此问题。 此更改可减少打开的连接数。 |
日志引入 API
| 限制 | 值 | 注释 |
|---|---|---|
| API 调用的最大大小 | 1 MB | 压缩数据和未压缩数据。 |
| 字段值的最大大小 | 64 KB | 超过 64 KB 的字段会被截断。 |
| 每个 DCR 的最大数据量/分钟 | 2 GB | 压缩数据和未压缩数据。 在响应的 Retry-After 标头中列出的持续时间后重试。 |
| 每个 DCR 的最大请求数/分钟 | 12,000 | 在响应的 Retry-After 标头中列出的持续时间后重试。 |
数据收集规则
| 限制 | Value |
|---|---|
| 最大数据源数 | 10 |
| 性能计数器中的最大计数器说明符数 | 100 |
| Syslog 中的最大设施名称数 | 20 |
| 事件日志中的最大 XPath 查询数 | 100 |
| 最大数据流数 | 10 |
| 最大数据流数 | 10 |
| 最大扩展数 | 10 |
| 最大扩展设置大小 | 32 Kb |
| 最大 Log Analytics 工作区数 | 10 |
| 转换中的最大字符数 | 15,360 |
诊断设置
| 资源 | 默认限制 | 最大限制 |
|---|---|---|
| 每个资源的最大诊断设置数 | 5 | 与默认值相同。 |
日志查询和语言
一般查询限制
| 限制 | 说明 |
|---|---|
| 查询语言 | Azure Monitor 使用与 Azure 数据资源管理器相同的 Kusto 查询语言 (KQL)。 有关 Azure Monitor 中不支持的 KQL 语言元素，请参阅 Azure Monitor 日志查询语言差异。 |
| Azure 区域 | 当数据跨多个 Azure 区域中的 Log Analytics 工作区时，日志查询可能会遇到过多的开销。 有关详细信息，请参阅查询限制。 |
| 跨资源查询 | 单个查询中的 Application Insights 资源和 Log Analytics 工作区的最大数量限制为 100。 视图设计器不支持跨资源查询。 新的 scheduledQueryRules API 支持日志警报中的跨资源查询。 有关详细信息，请参阅跨资源查询限制。 |
| Log Analytics 仪表板查询 | 单个 Log Analytics 仪表板查询中返回的最大记录数为 2,000。 |
用户查询限制
Azure Monitor 具有多个限制，可防止用户发送过多的查询。 这种行为可能会重载系统后端资源，并危害服务响应能力。 以下限制旨在防止客户中断，并确保服务级别一致。 用户带宽限制和上限的设计旨在仅影响极端使用情况，不应与典型使用情况相关。
| 度量 | 每用户限制 | 说明 |
|---|---|---|
| 并发查询 | 5 | 一个用户最多可以运行 5 个并发查询。 任何其他查询都将添加到队列中。 当其中一个正在运行的查询完成时，队列中的第一个查询会从队列中拉取并开始运行。 警报查询不是此限制的一部分。 |
| 并发队列中的时间 | 3 分钟 | 如果查询在队列中等待超过 3 分钟而未启动，将终止该查询并发出包含代码 429 的 HTTP 错误响应。 |
| 并发队列中的查询总数 | 200 | 队列中的查询数达到 200 后，下一查询将被拒绝，其 HTTP 错误代码为 429。 这一数字不包含可同时运行的 5 个查询。 |
| 查询速率 | 每 30 秒 200 个查询 | 单个用户可以向所有工作区提交查询的整体速率。 此限制适用于编程查询或由可视化部件（如 Azure 仪表板和 Log Analytics 工作区摘要页（已弃用））启动的查询。 |
- 优化查询，如在 Azure Monitor 中优化日志查询中所述。
- 仪表板和工作簿可以在单个视图中包含多个查询，每次加载或刷新视图时都会产生大量的查询。 请考虑将它们拆分为按需加载的多个视图。
- 在 Power BI 中，考虑仅提取聚合结果而不提取原始日志。
Log Analytics 工作区
数据收集量和保留期
| 定价层 | 每日限制 | 数据保留 | 注释 |
|---|---|---|---|
| 即用即付 （已于 2018 年 4 月推出） |
无限制 | 最多 730 天交互式保留期/ 最多 12 年的数据存档 |
如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。 |
| 承诺层级 （于 2019 年 11 月引入） |
无限制 | 最多 730 天交互式保留期/ 最多 12 年的数据存档 |
如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。 |
每个订阅的工作区数
| 定价层 | 工作区限制 | 注释 |
|---|---|---|
| 旧版免费层 | 10 | 此限制不能提高。 只能在 2022 年 7 月 1 日之前在旧的试用版定价层中创建新工作区或将现有工作区移入。 |
| 其他所有层 | 无限制 | 你会受到资源组中的资源数以及每个订阅的资源组数的限制。 |
Azure 门户
| 类别 | 限制 | 注释 |
|---|---|---|
| 日志查询返回的最大记录数 | 30,000 | 在查询中使用查询作用域、时间范围和筛选器来减少结果。 |
数据收集器 API
| 类别 | 限制 | 注释 |
|---|---|---|
| 单个发布内容的最大大小 | 30 MB | 将较大的卷拆分为多个发布内容。 |
| 字段值的最大大小 | 32 KB | 超过 32 KB 的字段会被截断。 |
查询 API
| 类别 | 限制 | 注释 |
|---|---|---|
| 单个查询中返回的最大记录数 | 500,000 | |
| 返回的数据的最大大小 | 约 104 MB（约 100 MiB） | API 最多可返回 64 MB 的压缩数据，这将转换为最多 100 MB 的原始数据。 |
| 最长查询运行时间 | 10 分钟 | 有关详细信息，请参阅超时。 |
| 最大请求速率 | 每个 Microsoft Entra 用户或客户端 IP 地址每 30 秒 200 个请求 | 请参阅日志查询和语言。 |
Azure Monitor 日志连接器
| 类别 | 限制 | 注释 |
|---|---|---|
| 数据的最大大小 | ~16.7 MB (~16 MiB) | 连接器基础结构规定该限制设置为低于查询 API 限制。 |
| 最大记录数 | 500,000 | |
| 最大连接器超时 | 110 秒 | |
| 最大查询超时 | 100 秒 | |
| 图表 | 日志页和连接器使用不同的图表库进行可视化。 一些功能目前无法在连接器中使用。 |
摘要规则
| 类别 | 限制 |
|---|---|
| 工作区中活动规则的最大数目 | 30 |
| 每个箱的最大结果数 | 500,000 |
| 最大结果集容量 | 100 MB |
| 用于箱处理的查询超时 | 10 分钟 |
常规工作区限制
| 类别 | 限制 | 注释 |
|---|---|---|
| 表中的最大列数 | 500 | AzureDiagnostics -- 超出限制的列将添加到动态“AdditionalFields”列 数据收集器 API 创建的自定义日志 - 超出限制的列将添加到动态“AdditionalFields”列 自定义日志 -- 请联系支持人员了解详细信息 |
| 自定义日志表的最大数目 | 500 | 联系支持部门以了解更多 |
| 列名称的最大字符数 | 45 |
数据引入速率
Azure Monitor 是一种大规模数据服务，每天为成千上万的客户发送数 TB 的数据，并且此数据仍在不断增长。 为了隔离和防止突然的引入突发事件导致多租户服务中断，在工作区中设置了默认引入量速率限制，并将其设置为每分钟 500 MB 压缩量，这相当于每分钟大约 6 GB 未压缩量。 此限制适用于通过诊断设置从 Azure 资源引入的数据。 该限制不适用于从代理或数据集合规则引入的数据。
当引入量速率达到工作区中设置的速率限制的 80% 时，每 6 小时就会向工作区中的 Operation 表发送一个事件，同时超出阈值。 当达到引入量速率限制时，重试机制会在 12 小时内尝试四次引入数据，如果失败就会丢弃数据，在超出阈值时，每 6 小时就会向工作区中的 Operation 表发送一个事件。
如果引入量速率继续超过阈值或预计很快达到阈值，可以通过打开支持请求来请求增加此限制。
建议创建一个警报，以便在接近或达到引入限制时主动收到通知。 请参阅监视 Azure Monitor 中 Log Analytics 工作区的运行状况。
注意
根据 Log Analytics 的使用时长，你可能有权使用旧的定价层。 详细了解 Log Analytics 的旧定价层。
Application Insights
每个应用程序（即每个检测密钥）的指标和事件数都有一些限制。 限制取决于选择的定价计划。
| 资源 | 默认限制 | 最大限制 | 备注 |
|---|---|---|---|
| 每日的总数据量 | 100 GB | 联系支持人员。 | 可以设置上限来减少数据。 如果需要更多数据，可以在门户中最多将上限提高到 1,000 GB。 如需大于 1,000 GB 的容量，请将电子邮件发送到 AIDataCap@microsoft.com。 |
| 限制 | 32,000 事件/秒 | 联系支持人员。 | 限制按分钟计量。 |
| 数据保留日志 | 30 至 730 天 | 730 天 | 此资源用于日志。 |
| 数据保留指标 | 90 天 | 90 天 | 此资源用于指标资源管理器。 |
| 可用性多步测试详细结果保留 | 90 天 | 90 天 | 此资源提供了每个步骤的详细结果。 |
| 最大遥测项大小 | 64 KB | 64 KB | |
| 每批最大遥测项数 | 64,000 | 64,000 | |
| 属性和指标名称长度 | 150 | 150 | 请参阅类型架构。 |
| 属性值字符串长度 | 8,192 | 8,192 | 请参阅类型架构。 |
| 跟踪和异常消息长度 | 32,768 | 32,768 | 请参阅类型架构。 |
| 每个 Application Insights 资源的可用性测试数 | 100 | 100 | |
| 每个资源组的可用性测试计数 | 800 | 800 | 请参阅 Azure 资源管理器 |
| 每个测试的可用性测试最大重定向次数 | 10 | 10 | |
| 可用性测试最小测试频率 | 300 秒 | 自定义测试频率或频率少于 5 分钟时需要自定义 TrackAvailability 实现。 | |
| Profiler 和快照数据保留期 | 两周 | 请联系支持人员。 最长保留期限为六个月。 | |
| 每天发送的探查器数据量 | 无限制 | 无限制。 | |
| 每天发送的快照数据 | 每个受监视的应用每天 30 个快照 | 无限制。 | 可以通过配置修改每个应用程序收集的快照数。 |
有关定价和配额的详细信息，请参阅 Application Insights 计费。
Azure Monitor 专用链接范围 （AMPLS）
AMPLS 对象具有以下限制：
- 一个虚拟网络只能连接到一个 AMPLS 对象。 这意味着，AMPLS 对象必须提供对虚拟网络应有权访问的所有 Azure Monitor 资源的访问权限。
- 一个 AMPLS 对象最多可以连接到 300 个 Log Analytics 工作区和 1,000 个 Application Insights 组件。
- 一个 Azure Monitor 资源最多可以连接到五个 AMPLS。
- 一个 AMPLS 对象最多可连接到 10 个专用终结点。