Azure 默认提供指标。 这些指标称为 标准指标或平台 指标。 自定义指标是性能指标或业务特定的指标。 可以通过应用程序的遥测收集它们。 也可以使用Azure Monitor代理或外部监视系统。 将自定义指标发布到 Azure Monitor 后，您可以像浏览、查询和针对标准 Azure 指标设置警报一样，对这些自定义指标进行浏览、查询和设置警报。
注释
Azure Monitor自定义指标以公共预览版提供。 此功能将不会正式发布，因为一个经过改进且已正式发布的功能不仅可实现相同的功能，还提供更多能力：Application Insights with OpenTelemetry。
使用已正式发布的替代项
本文中所述的自定义指标仍为预览版，不会正式发布。 对于新解决方案，请使用基于 OpenTelemetry 的常规可用路径，该路径提供相同的功能等。 若要开始，请参阅 Application Insights with OpenTelemetry。
用于发送自定义指标的方法
可以通过多种方法将自定义指标发送到Azure Monitor：
- 使用 Application Insights SDK 通过将自定义遥测发送到Azure Monitor来检测应用程序。
- 在 Windows 或 Linux Azure 虚拟机或虚拟机规模集上安装 Azure Monitor Agent，并使用 数据收集规则将性能计数器发送到 Azure Monitor 指标。
- 在 Azure Linux VM 上安装 InfluxData Telegraf 代理。 使用Azure Monitor输出插件发送指标。
- 将自定义指标直接发送到Azure Monitor REST API。
定价模型
将标准指标（平台指标）引入Azure Monitor指标存储是免费的。 原生自定义指标在预览期间也免费。 对指标 API 的查询会产生成本。 由于自定义指标仍处于预览阶段，且不会正式推出，因此若要使用受支持的计费模式，请使用 已正式发布的基于 OpenTelemetry 的替代方案。 有关当前指标和查询定价，请参阅Azure Monitor定价页。
自定义指标的定义
发布的每个指标数据点都包含命名空间、名称和维度信息。 首次将自定义指标发送到 Azure Monitor 时，服务会自动创建度量值定义。 可以在通过指标定义发出指标的任何资源上发现此新指标定义。 在发出自定义指标之前，无需在Azure Monitor中预定义自定义指标。
注释
Application Insights 和 InfluxData Telegraf 代理已配置为针对正确的区域终结点发出指标值，并在每个排放中携带上述所有属性。
使用自定义指标
将自定义指标提交到Azure Monitor后，可以通过Azure门户浏览这些指标，并通过Azure Monitor REST API 对其进行查询。 还可以对其创建警报，以便在满足特定的条件时收到通知。
注释
需要 监视读取者 角色才能查看自定义指标。
通过 Azure 门户浏览自定义指标
- 转到 Azure 门户。
- 选择“监视”窗格。
- 选择指标。
- 选择发出自定义指标的资源。
- 选择自定义指标的指标命名空间。
- 选择自定义指标。
有关在 Azure 门户中查看指标的详细信息，请参阅使用 Azure Monitor 指标资源管理器分析指标。
延迟和存储保留期
自定义指标的保留时间与平台指标的保留时间相同。
新添加的指标或新添加到指标的维度可能需要最多 3 分钟才能显示。 数据录入系统后，99% 的情况下应会在 30 秒内显示。
如果删除指标或维度，则从系统中删除更改可能需要一周到一个月的时间。
配额和限制
Azure Monitor对自定义指标施加以下使用限制：
| 类别 | 限度 |
|---|---|
| 订阅中每个地区的活跃时间序列总数 | 50,000 |
| 每个指标的维度键数 | 10 |
| 指标命名空间、指标名称、维度键和维度值的字符串长度 | 256 个字符 |
| 使用 utf-8 编码的所有自定义指标名称的组合长度 | 64 KB |
活动时序是指标、维度键或维度值的任何唯一组合，其指标值在过去 12 小时内发布。
若要理解对时序的 50,000 限制，请考虑以下指标：
包含 Region、Department 和 CustomerID 维度的服务器响应时间
对于这一指标，如果你有 10 个区域、20 个部门和 100 个客户，则共有 10 x 20 x 100 = 20,000 个时序。
如果你有 100 个区域、200 个部门和 2,000 个客户，则结果为 100 x 200 x 2,000 = 4000 万时序。 此数字远远超出单个指标的限制。
同样，这并非单个指标的限制。 它是整个订阅和区域中所有此类指标的总和。
若要查看当前活动时序指标总数并获取故障排除的详细信息，请执行以下步骤。
- 导航到Azure门户的“监视”部分。
- 选择左侧的指标。
- 在“选择范围”下，检查适用的订阅和资源组。
- 在“优化范围”下，选择“自定义指标使用情况”和所需位置。
- 选择 应用 按钮。
- 选择“活动时序”、“活动时序限制”或“限制的时序”。
Azure Monitor假设每个字符使用 UTF-8 编码或 1 字节，将所有自定义指标名称的组合长度限制为 64 KB。 如果指标名称超出此限制，Azure Monitor阻止访问其他指标的元数据。 Azure门户从选择字段省略这些指标名称，API 在返回指标定义时会跳过这些名称。 即使没有元数据，也可以直接查询指标数据。
超出限制时，请减少要发送的指标数量，或者缩短其名称的长度。 新指标名称最多需要两天时间才会显示出来。
为了避免达到限制，不要在指标名称中包含变量或维度方面的内容。
例如，服务器 CPU 使用率的指标 CPU_server_12345678-319d-4a50-b27e-1234567890ab 和 CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 应定义为指标 CPU 并具有 Server 维度。
设计限制和注意事项
使用 Application Insights 进行审核
Application Insights 遥测管道经过了优化，可最大限度地降低性能影响，并限制因监控应用程序而产生的网络流量。 因此，当初始数据集变得过大时，系统会进行节流或采样（仅获取一部分百分比的遥测数据，并忽略其余数据）。 由于这种行为，不能将其用于审核目的，因为某些记录可能会被删除。
名称中具有变量的指标
请勿在指标名称中使用变量。 可改用常数。 每次变量更改其值时，Azure Monitor生成新指标。 然后，Azure Monitor 很快达到度量数量的限制。 通常，当开发人员希望在指标名称中包括变量时，他们实际是希望在一个指标内跟踪多个时序，应使用维度代替变量指标名称。
高基数指标维度
在某一维度中包含太多有效值（称为“高基数”）的指标更有可能达到 50,000 的限制。 通常，不应在维度中使用不断改变的值。 例如，时间戳就不应用作维度。 你可以使用服务器、客户或产品 ID，但只有在每种类型的数量都比较少的情况下才能使用。
作为测试，问问你自己，你是否会在图形上绘制此类数据。 你有 10 台甚至 100 台服务器时，将它们全部显示在图形上进行比较可能会很有帮助。 但是，如果你有 1,000 个，生成的图形可能难以理解或无法理清。 最佳做法是将有效值数量保持在 100 以内。 此数目到 300 是中间区域。 如果需要超过此数量，请改用Azure Monitor自定义日志。
当名称中包含变量，或者使用高基数维度时，可能会出现以下问题：
- 由于限制，指标变得不可靠。
- 指标资源管理器无法工作。
- 警报和通知变得不可预测。
- 成本可能会意外增加，因为对指标查询进行计费。 对于受支持的正式发布计费模式，请使用基于 OpenTelemetry 的替代方案。
如果错误地使用标识符或高基数维度填充指标名称或维度值，则可以通过删除变量部分来轻松地对其进行修复。
但如果高基数对于你的方案来说至关重要，则聚合指标可能不是正确的选择。 改为使用自定义日志（即通过 trackEvent 进行的 trackMetric API 调用）。 请注意，日志并不会聚合数值，因此每个条目都会被独立存储。 因此，如果短时间内有大量的日志（例如，每秒 1 百万条日志），则可能会导致限制和引入延迟。
小窍门
Azure Monitor指标和Azure Monitor工作区以固定的 60 秒间隔引入自定义指标。 更频繁发送的指标会被缓冲，并每隔 60 秒处理一次。 Log Analytics会根据发送的时间间隔记录指标，短时间间隔可能会增加成本，长时间间隔可能会导致可见性延迟。
后续步骤
使用来自各种服务的自定义指标：