基于采样的分析器
编辑基于采样的分析器编辑
此功能处于技术预览阶段,可能会在将来的版本中更改或删除。Elastic 将努力解决任何问题,但技术预览中的功能不受官方 GA 功能支持 SLA 的约束。
此功能在 Windows 和 OpenJ9 上不受支持
与其记录每个事件,不如利用代理与 async-profiler 的内置集成,定期请求所有正在运行线程的堆栈跟踪。这意味着不需要将测量插入所有方法,这使得这种方法的开销极低。然后将堆栈跟踪与跨度激活事件相关联,并创建慢速方法的分析器推断跨度。就这样,我们检测到当前事务和跨度之间执行的确切内容。
用例编辑
- 开发: 当试图找出你刚刚发出的请求为什么很慢时。
- 负载测试/生产: 当分析为什么某些请求比其他请求慢时。
- 客户支持: 当用户抱怨他们在中午发出的特定请求很慢时,尤其是在你的开发或暂存环境中无法重现这种缓慢时。
优点编辑
- 无需知道要监控哪些方法: 在不预先指定特定方法名称的情况下查找慢速方法。分析器会自动将慢速方法作为跨度在 APM 应用程序中冒泡。
- 低开销。生产就绪: 基于分析器的方法旨在开销足够低,可以在生产环境中运行;持续运行它以提供对慢速方法的洞察。
如何使用 async-profiler 启用推断跨度编辑
通过将 profiling_inferred_spans_enabled
设置为 true
来启用推断跨度。
调整堆栈跟踪频率
通过调整 profiling_inferred_spans_sampling_interval
来调整在分析会话中收集堆栈跟踪的频率。采样间隔越低,推断跨度的准确性和详细程度就越高。当然,详细程度越高,分析器开销和 Elasticsearch 索引大小就越高。由于大部分处理是在后台完成的,因此对用户请求响应时间的的影响可以忽略不计。
清理 APM 应用程序中的杂乱
通过设置 span_min_duration
,过滤掉比配置阈值快的推断跨度,并避免使用快速执行的方法使 APM 应用程序杂乱。
包含和排除特定类
使用 profiling_inferred_spans_included_classes
显式包含类;使用 profiling_inferred_spans_excluded_classes
排除类。通常,包含的类越少,处理速度越快,内存效率就越高。
默认情况下,来自 JDK 和大多数应用程序服务器的类都被排除在外。这减少了不感兴趣的推断跨度的数量。
启用推断跨度的示例 elasticapm.properties
文件
profiling_inferred_spans_enabled=true profiling_inferred_spans_sampling_interval=50ms profiling_inferred_spans_min_duration=250ms profiling_inferred_spans_included_classes=org.example.myapp.* profiling_inferred_spans_excluded_classes=org.example.myapp.ignoreme.*
注意事项编辑
推断跨度是估计值,而不是精确测量值。它们可能在方法实际开始后开始,并在方法实际结束之前结束。这会导致不一致,所有这些都在 apm-profiling-plugin 自述文件 中有记录。
还要注意,事务中的第一个推断跨度没有堆栈跟踪,因为它可能是非典型的 - 它通常是入口点,并且包含有关服务器如何接受请求等的许多内容。连续的推断跨度具有指向其父级的堆栈跟踪。这意味着长时间运行的方法可能会显示为来自推断跨度机制的跨度,但不会显示关联的堆栈跟踪。