通过

Azure Monitor服务限制

本文列出了不同领域Azure Monitor的限制。

Alerts

Resource 默认限制 最大限制
指标警报 世纪互联运营的 Microsoft Azure 每个订阅包含 5,000 条活动警报规则。 如果达到此限制，请查看你是否可使用同类型多资源警报。
每条警报规则 10,000 个指标时序。		 致电支持人员。
活动日志警报 每个订阅 100 个活动警报规则（无法增加数量）。 这包括服务运行状况和资源运行状况警报。
由于无法增加此限制，如果每个订阅需要更多规则，请考虑将活动日志发送到 Log Analytics 工作区并创建日志搜索警报。		 与默认值相同。
日志通知 每个订阅 5,000 个活动警报规则。 其中 100 个活动警报规则的频率为 1 分钟。
每项资源 1,000 个活动警报规则。
每次评估时每个未处于监控状态的警报规则最多可以触发 6,000 个警报。
每次评估时每个处于监控状态的警报规则最多可以触发 300 个警报。
每个警报规则最多可以同时触发 5,000 个有状态警报。
可以配置有状态警报规则，频率高达 12 小时。

日志警报规则属性中所有数据的总大小不能超过 64KB。
Kusto 查询结果不能超过 20 MB。
在 Log Analytics 或 ADX 工作区上，每个托管身份的活动警报规则限为500个。
Azure 资源图工作区中，每个托管标识可有 50 个活动警报规则。		 致电支持人员。
警报处理规则 每个订阅 1,000 个活动规则。 致电支持人员。
警报规则和警报处理规则说明长度 日志搜索警报 4,096 个字符。
所有其他警报 2,048 个字符。		 与默认值相同。

警报接口

Azure Monitor 警报具有多项限流限制，以防止用户发出过多的调用。 这种行为可能会重载系统后端资源，并危害服务响应能力。 以下限制旨在防止客户中断，并确保服务级别一致。 用户限制专为极端使用场景设计， 不应与一般使用场景相关。

Note

每个实例的 API 调用数量有限制。 确切的限制数量取决于实例数。

Resource 默认限制 最大限制
警报 - 获取摘要 每个订阅每分钟 50 次调用 与默认值相同
警报 - 获取全部（不是“按 ID 获取”） 每个订阅每分钟 100 次调用 与默认值相同
所有其他警报通知 每个订阅每分钟 1,000 次调用 与默认值相同

行动小组

一个订阅中可以有无限数量的操作组。

Resource 默认限制 最大限制
Azure应用推送 每个操作组 10 个Azure应用操作。 与默认值相同
Email 一个操作组中 1,000 个电子邮件操作。
每个电子邮件地址每个区域每小时不超过 100 封电子邮件
电子邮件地址中的字符限制为 64。
电子邮件中的字符限制为 55296。
另请参阅 通知的服务限制。		 与默认值相同
发送邮件到 Azure 资源管理器 角色 每个操作组 10 个电子邮件 ARM 角色操作。
在生产环境中：每个区域一小时内最多 100 封电子邮件。
在测试操作组中：每 (1) 分钟不超过 2 封电子邮件。		 与默认值相同
事件中心 每个操作组 10 个事件中心操作。 与默认值相同
逻辑应用程序 一个操作组中有 10 个逻辑应用操作。 与默认值相同
Runbook 一个操作组中 10 个 runbook 操作。 与默认值相同
安全 Webhook 一个操作作组 10 个安全 Webhook 操作。 每个订阅最大 Webhook 调用次数为每分钟 1500 次。 与默认值相同
短信 一个操作组 10 个短信操作。
在生产环境中：每 5 分钟不超过 1 条短信。
在测试操作组中：每分钟不超过 1 条短信。		 与默认值相同
Webhook 一个操作组 10 个 Webhook 操作。 每个订阅最大 Webhook 调用次数为每分钟 1500 次。 与默认值相同

Autoscale

Resource 默认限制 最大限制
自动缩放设置 每个订阅每个区域 100 个。 与默认值相同
自动缩放配置文件 每个自动缩放设置 20 个配置文件。 与默认值相同

Prometheus 指标

Ingestion

Azure 托管的 Prometheus 是一个不区分大小写的系统。 如果字符串（例如指标名称、标签名称或标签值）与另一个时序的区别仅在于字符串的大小写，则它会将这些字符串视为相同的时序。 有关详细信息，请参阅 Prometheus 指标概述。

以下限制适用于引入 Prometheus 指标的Azure Monitor工作区。

Limit Value
活动时序，其中包含过去约 12 小时内报告的指标。 1,000,000
可以请求增加。
每分钟引入的事件数。 1,000,000
可以请求增加。

以下限制适用于数据收集规则（DCR）和数据收集终结点（DCE），将 Prometheus 指标数据发送到 Azure Monitor 工作区。

Limit Value
每分钟向数据收集规则发送的引入请求数 15,000
此限制不能提高。
每分钟向数据收集规则引入的数据 50 GB
此限制不能提高。

Queries

Prometheus 查询是使用 PromQL 创建的，可以在 Azure 托管 Grafana 或自管理 Grafana 中创作。

Limit Value
数据保留期 18 个月。
此限制不能提高。
查询时间范围 PromQL 查询的开始时间和结束时间之间的 32 天。
此限制不能提高。
每个指标的查询时序 50万个时间序列。
返回的查询示例 每个查询可获得 50,000,000 个示例。
最小查询步骤大小
时间范围 >= 48 小时		 60 秒。

查询数据限制
对于客户端流量：

Limit Value
限制时段查找长度 30 秒
每个Azure Monitor工作区返回的数据 0.5 GB

对于记录规则流量：

Limit Value
限制时段查找长度 3 分钟
每个Azure Monitor工作区返回的数据 1GB

查询预分析限制
基于 30 秒时段内的查询时间范围和请求类型（适用于客户端流量）：

Limit Value
每个用户的查询小时数（Microsoft Entra ID、托管身份、Azure 托管 Grafana 工作区） 30,000
每个Azure Monitor工作区的查询小时数 60,000
每个Azure租户的查询小时数 600,000

根据查询时间范围和请求类型，基于 3 分钟时段统计（适用于记录规则流量）：

Limit Value
每个Azure Monitor工作区的查询小时数 60,000
每个Azure租户的查询小时数 600,000

查询分析后限制
根据查询时间范围和查询范围向量，基于 30 秒时段统计（适用于客户端流量）：

Limit Value
每个用户的查询小时数（Microsoft Entra ID、托管身份、Azure 托管的 Grafana 工作区） 2,000,000
每个Azure Monitor工作区的查询小时数 2,000,000
每个Azure租户的查询小时数 20,000,000

根据查询时间范围和查询范围向量，基于 3 分钟时段统计（适用于记录规则流量）：

Limit Value
每个Azure Monitor工作区的查询小时数 2,000,000
每个Azure租户的查询小时数 20,000,000

查询成本限制

Limit Value
每个查询的最大查询成本 15000
记录规则查询的最大查询成本 3000

查询成本计算如下：

查询成本 =（请求的时序数 *（查询持续时间（秒）/ 查询的数据的推断时间解析度））/ 5000

查询的数据的推断时间解析度 = 在查询的指标的任意一个随机选择的时间序列键中存储的数据点数 / 查询持续时间（秒）

Note

对于查询中请求的时序键的结果，查询中的单个指标的最大大小限制为 64MB（以字节为单位）。

警报和记录规则

Prometheus 警报规则和记录规则是在 PromQL 中定义的。 在Azure Monitor Prometheus托管服务的一部分中，它们在托管Ruler服务上执行。

Limit Value
Azure订阅中每个Azure Monitor工作区的规则组 500
可以请求增加。
每个规则组的规则 20
此限制不能提高。
规则组评估时间间隔 介于 1 分钟 - 24 小时之间。
默认值为1分钟。
实时警报 目前没有限制。

远程写入

采用远程批处理大小 500（默认值）进行计算。

Limit Value
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

Limit Value Comments
API 调用的最大大小 1 MB 压缩数据和未压缩数据。
字段值的最大大小 64 KB 超过 64 KB 的字段会被截断。
每个 DCR 的最大数据量/分钟 *2 GB 压缩数据和未压缩数据。 在响应的 Retry-After 标头中列出持续时间后重试。
每个 DCR 每分钟的最大请求数 *12,000 在响应的 Retry-After 标头中列出持续时间后重试。
每个 API 调用的最大 TimeGenerated 范围 30 分钟 此限制仅适用于导入辅助日志表时。 如果引入的源条目 TimeGenerated 未进行转换，则条目的范围必须小于 30 分钟。

* 系统可能会自动适应逐步超出此阈值的增加，尽管在扩展过程中仍可能发生临时限流。 对于明显超过此阈值的预期较大或突然增加，请提前联系 Azure 支持以征询指导意见。

数据收集规则

Limit Value
数据源的最大数量 10
性能计数器中的最大计数器说明符数 100
Syslog 中的最大设施名称数 20
事件日志中的最大 XPath 查询数 100
最大数据流数 10
最大数据流数 20
最大扩展数 10
最大扩展设置大小 32 Kb
最大Log Analytics工作区数 10
转换中的最大字符数 15,360

诊断设置

Resource 默认限制 最大限制
每个资源的最大诊断设置数 5 与默认值相同。

日志查询和语言

一般查询限制

Limit Description
查询语言 Azure Monitor使用与Azure 数据资源管理器相同的 Kusto 查询语言 （KQL）。 请参阅 Azure Monitor 日志查询语言差异，了解 Azure Monitor 不支持的 KQL 语言元素。
Azure区域 当数据跨越多个 Azure 区域的 Log Analytics 工作区时，日志查询可能会经历过高的开销。 有关详细信息，请参阅查询限制。
跨资源查询 单个查询中 Application Insights 资源和Log Analytics工作区的最大数目限制为 100。
视图设计器不支持跨资源查询。
新的 scheduledQueryRules API 支持日志警报中的跨资源查询。
有关详细信息，请参阅跨资源查询限制。
日志分析仪表板查询 单个Log Analytics仪表板查询中返回的最大记录数为 2,000。

用户查询限制

Azure Monitor有几个限制，可以保护后端系统资源免受发送过多查询的用户的侵害，并确保服务级别一致。 这些每个用户的限制反映了极端的使用方案，不应与典型查询行为相关。

Measure 每用户限制 Description
并发分析查询 5 用户最多可以针对 Analytics 表运行五个并发查询。 系统按先进先出顺序（FIFO）将额外查询添加到并发队列中。 当其中一个并发运行的查询完成时，队列中的第一个查询将添加到并发查询并开始运行。 警报查询不是此限制的一部分。
并发的基本查询和辅助查询 2 用户最多可以针对基本表和辅助表运行两个并发 搜索查询 。 并发队列遵循相同的 FIFO 模型。
并发队列中的时间 3 分钟 如果查询位于队列中超过 3 分钟且不启动，则系统会使用代码 429 的 HTTP 错误响应终止该查询。
并发队列中的查询总数 200 队列中的查询数达到 200 后，下一查询将被拒绝，其 HTTP 错误代码为 429。 这一数字不包含可同时运行的 5 个查询。
查询速率 每 30 秒 200 个查询 单个用户在所有工作区中提交查询的总速率。 此限制适用于由可视化工具（如Azure仪表板和Log Analytics工作区摘要（已弃用）页）启动的编程方式的查询。
活动日志 API 查询速率 每 30 秒 50 个查询 活动日志 API 具有单独的速率限制。

请记住以下最佳做法，确保系统响应能力：

  • 根据 在 Azure Monitor 中优化日志查询 的描述，优化您的查询。
  • 仪表板和工作簿可以在单个视图中包含多个查询，每次加载或刷新视图时都会产生大量的查询。 请考虑将它们拆分为按需加载的多个视图。
  • 在Power BI中，请考虑仅提取聚合结果，而不是原始日志。

Log Analytics工作区

数据收集量和数据保留期

定价等级 每日限制 数据保留期 Comment
Pay-as-you-go
（已于 2018 年 4 月推出）		 无限制 保留最多 730 天的交互数据/
最多 12 年的数据存档		 如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。
承诺层级
（于 2019 年 11 月引入）		 无限制 保留最多 730 天的交互数据/
最多 12 年的数据存档		 如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。
旧的按节点 (OMS) 定价层
（已于 2016 年 4 月推出）		 无限制 30 至 730 天 如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。 只有满足以下条件之一的客户才能访问此定价层：
- 包含 2018 年 4 月 2 日之前的 Log Analytics 工作区或 Application Insights 资源的订阅；
- 绑定到 2019 年 2 月 1 日之前开始且仍然处于活动状态的企业协议的订阅。
旧的独立层
（已于 2016 年 4 月推出）		 无限制 30 至 730 天 如果数据保留期超过 31 天，则需要收取额外的费用。 详细了解 Azure Monitor 定价。 只有满足以下条件之一的客户才能访问此定价层：
- 订阅中包含在 2018 年 4 月 2 日之前创建的 Log Analytics 工作区或 Application Insights 资源。
- 订阅与在 2019 年 2 月 1 日之前开始且仍然有效的企业协议相关联。
旧的免费层
（已于 2016 年 4 月推出）		 500 MB 7 天 当工作区达到 500 MB 的每日限制时，数据引入会停止，并在第二天开始时恢复。 一天以 UTC 为基础。 Microsoft Defender for Cloud收集的数据不包括在此 500 MB/天限制中，并继续收集超过此限制。 只有在 2022 年 7 月 1 日之前，才能在旧版试用定价层中创建新工作区或将现有工作区移动到该工作区。
旧的标准层 无限制 30 天 不能调整保留期。 自 2016 年 10 月 1 日起，此层对新工作区不可用。
旧的高级层 无限制 365 天 不能调整保留期。 自 2016 年 10 月 1 日起，此层对新工作区不可用。

每个订阅的工作区数

定价等级 工作区限制 Comments
旧的免费层 10 此限制不能提高。 只有在 2022 年 7 月 1 日之前，才能在旧版试用定价层中创建新工作区或将现有工作区移动到该工作区。
其他所有层 无限制 你会受到资源组中的资源数以及每个订阅的资源组数的限制。

Azure门户

Category Limit Comments
日志查询返回的最大记录数 500,000 在查询中使用查询作用域、时间范围和筛选器来减少结果。
返回的数据的最大大小 约 104 MB（约 100 MiB） 门户 UI 最多返回 64 MB 的压缩数据，这相当于 100 MB 的原始数据。

数据收集器 API

Category Limit Comments
单个帖子的最大限制 30 兆字节 将较大内容拆分为多个帖子。
字段值的最大大小 32 KB 超过 32 KB 的字段会被截断。

查询 API

Category Limit Comments
单个查询中返回的最大记录数 500,000
返回的数据的最大大小 约 104 MB（约 100 MiB） API 最多可返回 64 MB 的压缩数据，这将转换为最多 100 MB 的原始数据。
最长查询运行时间 10 分钟 有关详细信息，请参阅超时。
最大请求速率 每 30 秒内每位 Microsoft Entra 用户或每个客户端 IP 地址最多可发出 200 次请求 请参阅日志查询和语言。

Azure Monitor 日志连接器

Category Limit Comments
数据的最大大小 约 16.7 MB （约 16 MiB） 连接器基础结构规定该限制设置为低于查询 API 限制。
最大记录数 500,000
连接器最大超时时间 110 秒
查询最大超时时间 100 秒
Charts 日志页和连接器使用不同的图表库进行可视化。 一些功能目前无法在连接器中使用。

摘要规则

Category Limit
工作区中活动规则的最大数目 30
每个箱的最大结果数 500,000
最大结果集容量 100 MB
箱处理的查询超时时间 10 分钟

常规工作区限制

Category Limit Comments
最大表列数 500 AzureDiagnostics - 超出限制的列将添加到动态"AdditionalFields"列中
数据收集器 API 创建的自定义日志 - 超出限制的列会添加到动态“AdditionalFields”列
自定义日志 - 联系支持人员以增加限制
自定义日志表的最大数目 500 请联系支持人员来提高限制
列名称的最大字符数 45

数据引入速率

Azure Monitor是一项大规模数据服务，每天向成千上万的客户发送数 TB 数据，并且速度正在增长。 软限速旨在将Azure Monitor客户与多租户环境中的突发摄取峰值隔离开来。 工作区中的默认数据引入量速率阈值为 500 MB（压缩后），转换为大约 6 GB/分钟（未压缩）。

数据量速率限制适用于通过 工作区版 Application Insights 引入的数据，来自 Azure 的资源通过 诊断设置，以及通过 Data Collector API 引入的数据。 达到卷速率限制时，重试机制会在 12 小时内 4 次尝试引入数据，如果操作失败则将其删除。 该限制不适用于从代理或通过数据收集规则 (DCR) 引入的数据。

如果数据量速率高于工作区中阈值的 80%，则会在超过阈值时每隔 6 小时将一个事件发送到工作区中的 Operation 表。 如果数据引入量速率超过阈值，则在引入量超过阈值时，系统会丢弃某些数据，还会每 6 小时向工作区中的 Operation 表发送一个事件。

如果引入量速率超过此阈值，或者你打算增加超过该阈值的引入量， 请联系支持部门请求提高工作区中的速率限制。

最佳做法 - 创建警报规则，以在接近或达到引入速率限制时收到通知。 请参阅 在 Azure Monitor 中监控 Log Analytics 工作区的运行状况。

Note

根据你使用Log Analytics的时间，你可能有权访问旧定价层。 详细了解 Log Analytics 传统定价层。

Application Insights

每个应用程序在指标和事件数量上有一些限制，即每个连接字符串。 限制取决于选择的定价计划。

Resource 默认限制 最大限制 Notes
每日的总数据量 100 GB 联系支持人员。 可以设置上限来减少数据。 如果需要更多数据，可以在门户中最多将上限提高到 1,000 GB。 如需大于 1,000 GB 的容量，请将电子邮件发送到 AIDataCap@microsoft.com。
Throttling 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 实现。
.NET Profiler 和 Snapshot Debugger 数据存储 两周 请联系支持人员。 最长保留期限为六个月。
.NET Profiler每天发送的数据 无限制 无限制。
每天发送的 Snapshot Debugger 数据 每个受监视的应用每天 30 个快照 无限制。 可以通过配置修改每个应用程序收集的快照数。

有关定价和配额的详细信息，请参阅 Application Insights 计费。

AMPLS 对象具有以下限制：

  • 一个虚拟网络只能连接到一个 AMPLS 对象。 这意味着 AMPLS 对象必须提供对虚拟网络应有权访问的所有Azure Monitor资源的访问权限。
  • AMPLS 对象最多可以连接到 3,000 个Log Analytics工作区，最多可以连接到 10,000 个 Application Insights 组件。
  • Azure Monitor资源最多可以连接到 100 AMPLS。
  • 一个 AMPLS 对象最多可连接到 10 个专用终结点。

后续步骤

  • Last updated on