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

应用的遥测数据，例如OpenTelemetry可以提供的，对于诊断分布式系统中的问题非常有用。在这种情况下，我们将演示如何从高级指标和跟踪导出数据来确定内存泄漏的原因。

配置

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

诊断

诊断问题的第一步是确定存在问题。通常，首选的是使用诸如Grafana之类的工具提供的指标仪表板。

在启动演示后，应该存在一个名为demo dashboard folder的文件夹，其中包含两个仪表板。其中一个用于监视您的OpenTelemetry收集器，另一个包含了几个查询和图表以分析每个服务的延迟和请求速率。

该仪表板将包含许多图表，但其中一些应该很有趣：

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

推荐服务图表是由导出给Prometheus的OpenTelemetry指标生成的，而服务延迟和错误率图表则是通过OpenTelemetry收集器Span Metrics处理器生成的。

从我们的仪表板中，我们可以看到推荐服务中似乎存在异常行为——CPU利用率的波动，以及p95、p99和p99.9直方图中的长尾延迟。我们还可以看到该服务的内存使用也会间歇性地出现峰值。

我们知道我们应用程序也会发出跟踪数据，所以让我们考虑另一种确定存在问题的方法。

Jaeger允许我们搜索跟踪并显示整个请求的端到端延迟，以及对整个请求的每个单独部分进行可视化。也许我们注意到前端请求的尾延迟增加了。Jaeger允许我们搜索和筛选只包括对推荐服务的请求的跟踪。

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

我们可以看到推荐服务完成工作所花费的时间很长，通过查看详细信息，我们可以更好地了解发生了什么情况。

确认诊断结果

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

返回搜索界面，将"Service"下拉菜单中的值过滤为recommendationservice，在"Tags"框中搜索app.cache_hit=true。请注意，当缓存命中时，请求往往更快。现在搜索app.cache_hit=false并比较延迟。您应该会注意到跟踪列表顶部的可视化中会出现一些变化。

现在，由于这是一个虚构的场景，我们知道在我们的代码中可以找到潜在的错误。然而，在真实环境中，我们可能需要进一步搜索来找出我们的代码中发生了什么，或者引起这个问题的服务之间的交互。