你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Monitor 中的自定义指标（预览版）
Azure 提供一些现成的指标。 这些指标称为标准指标或平台指标。 自定义指标是性能指标或业务特定的指标，你可以通过应用程序的遥测、Azure Monitor 代理、在 Azure 资源上运行的诊断扩展或外部监视系统收集这些指标。 将自定义指标发布到 Azure Monitor 后，你可以在标准 Azure 指标旁边浏览、查询自定义指标并针对它们发出警报。
Azure Monitor 自定义指标目前以公共预览版提供。
用于发送自定义指标的方法
可以通过多种方法将自定义指标发送到 Azure Monitor：
- 使用 Azure Application Insights SDK，通过将自定义遥测数据发送到 Azure Monitor 来检测应用程序。
- 在 Windows 或 Linux Azure 虚拟机或虚拟机规模集上安装 Azure Monitor 代理，并使用数据收集规则将性能计数器发送到 Azure Monitor 指标。
- 在 Azure VM、虚拟机规模集、经典 VM 或经典云服务上安装 Azure 诊断扩展。 然后将性能计数器发送到 Azure Monitor。
- 在 Azure Linux VM 上安装 InfluxData Telegraf 代理。 使用 Azure Monitor 输出插件发送指标。
- 将自定义指标直接发送到 Azure Monitor REST API。
定价模型和保留期
一般来说，将标准指标（平台指标）引入 Azure Monitor 指标存储不会产生费用，但是自定义指标在正式发布后会产生费用。 对指标 API 的查询确实会产生费用。 若要详细了解何时为自定义指标和指标查询启用计费，请查看 Azure Monitor 定价页。
自定义指标的保留时间与平台指标的保留时间相同。
注意
为了提供更好的体验，从 Application Insights Classic API (SDK) 发送到 Azure Monitor 的自定义指标始终存储在 Log Analytics 和指标存储中。 存储这些指标的成本仅基于 Log Analytics 引入的卷。 指标存储中存储的数据无需额外付费。
自定义指标的定义
发布的每个指标数据点包含命名空间、名称和维度信息。 首次将自定义指标发送到 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 针对自定义指标实施以下用量限制：
| Category | 限制 |
|---|---|
| 每个区域订阅中的活动时序总数 | 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 = 40,000,000 个时序，这远远超出了对于这一指标的限制。
同样，这并非单个指标的限制。 而是整个订阅和区域中所有此类指标的限制总和。
请按照以下步骤查看当前的总活动时序指标，以及有助于进行故障排除的更多信息。
- 导航到 Azure 门户的“监视”部分。
- 选择左侧的“指标”。
- 在“选择范围”下，检查适用的订阅和资源组。
- 在“优化范围”下，选择“自定义指标使用情况”和所需位置。
- 选择“应用”按钮。
- 选择“活动时间序列”、“活动时间序列限制”或“受限制的时间序列”。
假设每个字符采用 utf-8 或 1 个字节，则所有自定义指标名称的组合长度限制为 64 KB。 如果超出 64 KB 的限制，则其他指标的元数据将不可用。 其他自定义指标的指标名称不会显示在 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 以内。 从 100 到 300 是灰色区域。 如果需要超出此数量，请改用 Azure Monitor 自定义日志。
当名称中包含变量，或者使用高基数维度时，可能会出现以下问题：
- 由于限制，指标变得不可靠。
- 指标资源管理器无法工作。
- 警报和通知变得不可预测。
- 成本可能会意外增加。 当包含维度的自定义指标功能以公共预览版提供时，Microsoft 不对其收费。 将来开始收费后，就会产生意外费用。 该计划会根据所监视的时序数以及所执行的 API 调用数对指标使用量进行收费。
如果错误地使用标识符或高基数维度填充指标名称或维度值，则可以通过删除变量部分来轻松地对其进行修复。
但如果高基数对于你的方案来说至关重要，则聚合指标可能不是正确的选择。 改为使用自定义日志（即通过 trackEvent 进行的 trackMetric API 调用）。 不过，需要考虑到的是，日志不会聚合值，因此每一个条目都会进行存储。 因此，如果短时间内有大量的日志（例如，每秒 1 百万条日志），则可能会导致限制和引入延迟。
后续步骤
使用来自各种服务的自定义指标：