使用指标和跟踪来诊断内存泄漏

应用程序遥测（例如 OpenTelemetry 提供的遥测）对于诊断分布式系统中的问题非常有用。在此场景中，我们将介绍一个演示如何从高级指标和跟踪来确定内存泄漏原因的场景。

设置

要运行此场景，您需要部署演示应用程序并启用 recommendationServiceCacheFailure 功能标志。启用功能标志后，让应用程序运行约 10 分钟，以便数据填充。

诊断

诊断问题的第一步是确定问题是否存在。通常，第一个停靠点是 Grafana 等工具提供的指标仪表板。

启动演示时，应该会有一个 演示仪表板文件夹，其中包含两个仪表板；一个用于监控您的 OpenTelemetry Collector，另一个包含多个查询和图表，用于分析每个服务的延迟和请求速率。

此仪表板将包含一些图表，但有几个应该会很有趣

• 推荐服务（CPU% 和内存）
• 服务延迟（来自 SpanMetrics）
• 错误率

推荐服务图表由导出到 Prometheus 的 OpenTelemetry 指标生成，而服务延迟和错误率图表通过 OpenTelemetry Collector Span Metrics processor 生成。

从我们的仪表板中，我们可以看到推荐服务似乎存在异常行为——CPU 利用率呈尖峰状，并且我们的 p95、99 和 99.9 直方图中的尾部延迟很长。我们还可以看到此服务的内存利用率出现间歇性峰值。

我们知道我们也在从应用程序发出跟踪数据，那么我们是否可以考虑另一种确定问题存在的方法。

Jaeger 允许我们搜索跟踪并显示整个请求的端到端延迟，并深入了解整个请求的每个单独部分。也许我们注意到前端请求的尾部延迟有所增加。Jaeger 允许我们搜索和过滤跟踪，仅包括那些包含对推荐服务的请求的跟踪。

通过按延迟排序，我们可以快速找到花费时间较长的特定跟踪。单击右侧面板中的跟踪，我们可以查看瀑布视图。

我们可以看到推荐服务花费了很长时间才完成其工作，查看详细信息可以让我们更好地了解正在发生的事情。

确认诊断

在瀑布视图中，我们可以看到 app.cache_hit 属性设置为 false，并且 app.products.count 值非常高。

返回搜索 UI，在 Service 下拉列表中选择 recommendation，然后在 Tags 框中搜索 app.cache_hit=true。请注意，当缓存命中时，请求通常更快。现在搜索 app.cache_hit=false 并比较延迟。您应该会注意到跟踪列表顶部可视化中的一些变化。

现在，由于这是一个人为设定的场景，我们知道在哪里可以找到代码中的底层错误。但是，在实际场景中，我们可能需要进行进一步的搜索才能找出代码中的问题，或者导致问题的服务之间的交互。