Application Insights 包括自定义采样器，并与 OpenTelemetry 集成，以减少遥测量、降低成本并保留你关心的诊断数据。
重要
有关使用 Application Insights 经典 API 软件开发工具包（SDK）时采样的信息，请参阅 经典 API 采样。
先决条件
在继续之前，请确保具备：
- 基本了解 数据收集 方法
- 基本了解 OpenTelemetry 采样概念
- 使用 OpenTelemetry 进行检测的应用程序
为什么采样很重要
采样对于生成大量遥测的应用程序至关重要。
缺乏采样时，过量的数据摄入可能会导致：
- 增加存储和处理成本
- 导致 Application Insights 限制遥测
有效的采样可保留足够的数据，以便进行有意义的诊断，同时控制成本。
默认情况下，Application Insights OpenTelemetry 发行版中 未启用 采样。 必须显式启用和配置采样以便管理遥测数据量。
注释
如果在 Application Insights 中看到意外费用或高成本，本指南将有所帮助。 它涵盖了常见的原因，例如高遥测量、数据引入峰值和配置错误的采样。 如果你在排查与成本峰值、遥测量、采样功能失效、数据上限、高引入或意外计费相关的问题，则它特别有用。 若要开始操作，请参阅排查 Application Insights 中的高数据引入问题。
Application Insights 自定义采样器
基于 Azure Monitor OpenTelemetry 的发行版包括自定义采样器。
- 实时指标和 Application Insights 经典 API SDK 需要此采样器才能兼容。
- 采样器默认处于禁用状态。 必须显式启用和配置采样以使用采样器。
- 它使用固定速率算法。 例如，采样率为 10% 时，会将大约 10% 的跟踪发送到 Azure Monitor。
- Azure Monitor Application Insights 服务依赖此采样器来显示完整的跟踪并避免出现损坏的跟踪。
好处
- 在使用 Application Insights 经典 API 软件开发工具包（SDK）与应用程序实现互操作性时做出一致的采样决策。
- 与 实时指标 完全兼容，因为采样器知道实时指标要求。
若要配置采样百分比，请参阅 使用 OpenTelemetry 在 Application Insights 中启用采样。
有关更多详细信息和采样边缘事例，请参阅 常见问题解答。
引入采样（不建议）
当无法进行源级控制时，引入采样是一种备选方案。 它会在 Azure Monitor 引入点丢弃数据，并且无法对保留哪些跟踪和跨度进行控制。 这会增加遇到断裂痕迹的几率。
唯一可行或最实用选项的方案包括：
- 无法修改应用程序源代码。
- 无需重新部署应用程序即可立即减少遥测数据量。
- 收到来自多个源的遥测数据，这些源的采样配置不一致或未知。
若要配置引入采样，请执行以下操作：
- 转到 Application Insights>使用情况和估计成本。
- 选择 数据采样。
- 选择要保留的数据百分比。
设置每日上限
设置每日上限以防止意外成本。 此限制会在达到阈值时停止遥测引入。
请将此上限用作最后的控制手段，而不是替代采样。 数据量突然增加可能会触发上限，造成遥测中断，直到第二天重置为止。
若要配置上限，请参阅 为 Azure Monitor 设置每日上限。
常见问题解答
Application Insights 自定义采样器是否基于尾部？
Application Insights 自定义采样器在跨度创建之后而不是之前做出采样决策，因此不遵循传统的基于头部的方法。 它会改为在跨度生成结束时（在跨度完成之后，但在导出之前）应用采样决策。
尽管此行为在某些方面类似于基于尾部的采样，但采样器不会等到从同一跟踪收集多个跨度之后再做出决策。 而是使用跟踪 ID 的哈希来帮助确保跟踪完整性。
此方法平衡了跟踪的完整性和效率，并避免了与基于尾部的完整采样关联的较高成本。
若要根据整个跟踪的结果做出采样决策（例如，确定跟踪内的任何跨度是否失败），需要在下游代理或收集器中进行基于尾部的完整采样。 此功能目前不受支持，但可以通过 反馈中心将其请求为新功能。
Application Insights 自定义采样器与 OpenTelemetry 的头部采样和尾部采样如何比较？
| 采样方法 | 决策点 | 优势 | 弱点 |
|---|---|---|---|
| 基于头部 | 在跨度开始之前 | 低延迟，开销最小 | 可能会采样所需的跟踪，包括失败 |
| 基于尾部 | 根据时间或容量阈值对跨度进行缓冲后 | 允许高度选择性的跟踪采样条件 | 成本更高且处理延迟增加 |
| App Insights 自定义采样器 | 跨度生成结束 | 平衡跟踪完整性和效率 | 实时指标和经典 API 兼容性所需 |
是否可以以不同的速率采样依赖项、请求或其他遥测类型？
否，采样器对跟踪中的所有遥测类型应用固定速率。 请求、依赖项和其他跨度遵循相同的采样百分比。 若要按照遥测类型应用不同的采样率，请考虑使用 OpenTelemetry 跨度处理器或(引入时间转换)[opentelemetry-overview.md#telemetry-routing]。
Application Insights 自定义采样器如何传播采样决策？
默认情况下，Application Insights 自定义采样器使用 W3C 跟踪上下文标准传播采样决策。 此标准允许采样决策在服务之间流动。 但是，由于采样器在跨度生成结束时（在调用下游服务后）做出采样决策，传播会传递不完整的采样信息。 此限制符合 W3C 跟踪上下文规范，但下游服务无法可靠地使用此传播的采样决策。
Application Insights 自定义采样器是否遵循来自上游服务的采样决策？
否，即使上游服务使用相同的采样算法，Application Insights 自定义采样器也始终做出独立的采样决策。 来自上游服务的采样决策（包括那些使用 W3C 跟踪上下文标头的决策）不会影响下游服务的决策。 但是，它确实根据跟踪 ID 的哈希进行采样以确保跟踪完整性。 为了提高一致性并降低跟踪中断的可能性，请将系统中的所有组件配置为使用相同的采样器和采样率。
为什么即使使用 Application Insights 自定义采样器，某些跟踪也显得不完整？
有几种原因导致跟踪可能不完整：
- 分布式系统中的不同节点使用不同的采样方法，这些方法无法协调决策。 例如，一个节点应用基于头的 OpenTelemetry 采样，另一个节点通过 Azure Monitor 自定义采样器应用采样。
- 不同的节点设置为不同的采样率，即使它们都使用相同的采样方法也是如此。
- 可以在服务端管道中设置筛选、采样或速率上限，此配置会随机采样范围，而无需考虑跟踪完整性。
如果一个组件应用基于头部的采样而不传播采样决策（通过 W3C 跟踪上下文标头），则下游服务会独立地对跟踪进行采样，这可能会导致丢弃跨度。 因此，在 Application Insights 中查看时，跟踪的某些部分并不总是可用的。