Application Insights 中基于日志的指标和预先聚合的指标
注意
以下文档依赖于 Application Insights 经典 API。 Application Insights 的长期计划是使用 OpenTelemetry 收集数据。 有关详细信息，请参阅为 .NET、Node.js、Python 和 Java 应用程序启用 Azure Monitor OpenTelemetry 和我们的 OpenTelemetry 路线图。 迁移指导适用于 .NET、Node.js 和 Python。
本文介绍基于日志的“传统”Application Insights 指标与预先聚合的指标之间的差别。 Application Insights 用户可以使用这两种类型的指标。 每种指标在监视应用程序运行状况、诊断和分析方面都发挥了独特的作用。 检测应用程序的开发人员可以确定哪种类型的指标最适合特定的方案。 决策基于应用程序的大小、预期遥测量以及指标精度和警报方面的业务要求。
基于日志的指标
过去，Application Insights 中的应用程序监视遥测数据模型只是基于一些预定义类型的事件，例如请求、异常、依赖项调用和页面视图。 开发人员可以使用 SDK，通过编写显式调用该 SDK 的代码来手动发出这些事件。 也可以依赖于自动检测中的自动收集事件的功能。 无论哪种情况，Application Insights 后端都会将所有收集的事件存储为日志。 可以使用 Azure 门户中的 Application Insights 窗格作为分析和诊断工具来可视化日志中基于事件的数据。
使用日志保留完整事件集能够为分析和诊断带来很大的帮助。 例如，可以获取对特定 URL 发出的确切请求计数，以及发出这些调用的非重复用户数。 或者，可以获取详细的诊断跟踪，包括任何用户会话的异常和依赖项调用。 获取此类信息可以更好地了解应用程序运行状况和使用情况。 此外还可以减少诊断应用问题所需的时间。
同时，对于生成大量遥测数据的应用程序而言，收集完整事件集可能不切实际，甚至不可能。 如果事件量过高，Application Insights 会实施多种遥测数据量缩减技术，以减少收集和存储的事件数量。 这些技术包括采样和筛选。 遗憾的是，降低存储事件数量也会降低指标的准确性，因此，在幕后必须对日志中存储的事件执行查询时聚合。
注意
在 Application Insights 中，基于日志中存储的事件和测量值查询时聚合的指标称为基于日志的指标。 这些指标通常在事件属性中具有许多维度，因此非常适用于分析。 这些指标的准确性受到采样和筛选的负面影响。
预先聚合的指标
除了基于日志的指标以外，Application Insights 团队还在 2018 年年底交付了存储在专用存储库（已针对时序进行优化）中的指标的公共预览版。 新指标不再作为包含大量属性的单个事件进行保存。 它们存储为预先聚合的时序，仅包含关键维度。 此更改使新指标在查询时间上更胜一筹。 检索数据的速度更快，而且需要的计算能力更低。 因此启用了新方案，例如准实时指标维度警报和响应更快的仪表板。
重要
基于日志的指标和预先聚合的指标在 Application Insights 中共存。 为了区分这两者，在 Application Insights 用户体验中，预先聚合的指标现在称为“标准指标”。 事件中的传统指标已重命名为“基于日志的指标”。
较新的 SDK（适用于 .NET 的 Application Insights 2.7 SDK 或更高版本）会在收集期间预聚合指标。 此过程适用于默认发送的标准指标，因此准确度不受采样或筛选的影响。 它也适用于使用 GetMetric 发送的自定义指标，因此可减少数据引入并降低成本。
对于不实施预先聚合的 SDK（即，早期版本的 Application Insights SDK 或用于浏览器检测的 SDK），Application Insights 后端仍会通过聚合 Application Insights 事件收集终结点收到的事件来填充新指标。 尽管不能从减少的网络传输数据量中获益，但你仍然可以使用预先聚合的指标并体验到改善的性能，同时可以在收集期间使用不预先聚合指标的 SDK 进行准实时维度预警。
收集终结点会在进行引入采样之前预先聚合事件。 因此，无论你在应用程序中使用哪个 SDK 版本，引入采样都不会影响预先聚合的指标的准确性。
支持 SDK 的预聚合指标表
| 当前生产 SDK | 标准指标（SDK 预先聚合） | 自定义指标（不含 SDK 预先聚合） | 自定义指标（含 SDK 预先聚合） |
|---|---|---|---|
| .NET Core 和 .NET Framework | 支持 (V2.13.1+) | 通过 TrackMetric 支持 | 通过 GetMetric 支持 (V2.7.2+) |
| Java | 不支持 | 通过 TrackMetric 支持 | 不支持 |
| Node.js | 支持 (V2.0.0+) | 通过 TrackMetric 支持 | 不支持 |
| Python | 不支持 | 支持 | 部分支持通过 OpenCensus 提供 |
注意
使用 OpenCensus.stats 的 Python 指标实现与 GetMetric 不同。 有关详细信息，请参阅有关指标的 Python 文档。
支持无代码的预聚合指标表
| 当前生产 SDK | 标准指标（SDK 预先聚合） | 自定义指标（不含 SDK 预先聚合） | 自定义指标（含 SDK 预先聚合） |
|---|---|---|---|
| ASP.NET | 支持 1 | 不支持 | 不支持 |
| ASP.NET Core | 支持 2 | 不支持 | 不支持 |
| Java | 不支持 | 不支持 | 支持 |
| Node.js | 不支持 | 不支持 | 不支持 |
- 虚拟机/虚拟机规模集上的和本地的 ASP.NET 自动检测会发出无维度的标准指标。 Azure 应用服务也是如此，但集合级别必须设置为“推荐”。 该 SDK 对于所有维度都是必需的。
- 应用服务上的 ASP.NET Core 自动检测会发出没有维度的标准指标。 SDK 对于所有维度都是必需的。
对 Application Insights 自定义指标使用预先聚合
可对自定义指标使用预先聚合。 两大主要优势有：
- 配置自定义指标的维度并发出警报
- 减少从 SDK 发送到 Application Insights 集合终结点的数据量
可通过多种方法从 Application Insights SDK 发送自定义指标。 如果 SDK 版本提供 GetMetric 和 TrackValue，则这些方法是发送自定义指标的首选方法。 在这种情况下，预先聚合发生在 SDK 内部。 这种方法减少了存储在 Azure 中的数据量以及从 SDK 传输到 Application Insights 的数据量。 否则请使用 trackMetric 方法。此方法在数据引入期间会预先聚合指标事件。
自定义指标维度和预先聚合
使用 OpenTelemetry、trackMetric 或 GetMetric 和 TrackValue API 调用发送的所有度量将自动存储在日志和指标存储中。 这些指标可以在 Application Insights 中的 customMetrics 表和指标资源管理器中名为“azure.applicationinsights”的自定义指标命名空间下找到。 虽然自定义指标基于日志的版本始终保留所有维度，但指标的预先聚合版本在存储时默认不包含任何维度。 保留自定义指标的维度是一项预览功能，可通过选择“将自定义指标发送到 Azure 指标存储”下的“使用维度”，从“使用情况和估计成本”选项卡启用此功能。
为何默认禁用了自定义指标维度的收集？
之所以默认禁用自定义指标维度的收集，是因为存储包含维度的自定义指标将来会在 Application Insights 中单独计费。 存储无维度自定义指标的操作仍然免费（但不能超过配额限制）。 可以在官方定价页中了解我们即将做出的定价模式变化。
创建图表和浏览基于日志的指标与标准的预先聚合的指标
使用 Azure Monitor 指标资源管理器可以根据预先聚合的指标和基于日志的指标来绘制图表，以及创作包含图表的仪表板。 选择所需的 Application Insights 资源后，请使用命名空间选取器在标准指标和基于日志的指标之间进行切换。 还可以选择自定义指标命名空间。
Application Insights 指标的定价模型
如果将指标引入 Application Insights，则无论是基于日志的指标还是预先聚合的指标，都将产生基于引入数据的大小的成本。 有关详细信息，请参阅 Azure Monitor 日志定价详细信息。 自定义指标（包括其所有维度）始终存储在 Application Insights 日志存储中。 此外，默认情况下，会将自定义指标（不包含维度）的预先聚合版本转发到指标存储。
如果为了在指标存储中存储预先聚合指标的所有维度而选择“在自定义指标维度上启用警报”选项，则可能会产生基于自定义指标定价的额外成本。