Observability：使用 APM 中的 Service Map 了解和调试应用程序

Posted 2021-10-22 中国社区官方博客

在 Kibana 中，有一个可观测性的应用叫做 APM，也就是应用性能监控 （Application Performance Monitoring）。它是构建于 Elastic Stack 之上的。它可以很轻松地让我定位并且对应用的性能进行调优。在本文章中，我将介绍分布式追踪到底是什么以及如何使用 Service Map 来快速地展示你一个系统的整个架构。

 

 如果你对 APM 还是不很熟悉的话，请参阅我之前的文章 “Elastic：菜鸟上手指南” 中的 “解决方案” 中的 APM 一节。你可以在文章 “应用程序性能监控/管理(APM)实践” 中了解 APM 到底是什么以及如何针对一个 Java 应用来做应用性能监控。如果你想了解更多关于 Service Map 的知识，你可以参阅另外一篇文章 “Observability：从零基础到能够完成微服务可观测性的专家 - Service Map 实践”。

我们可以使用 APM agents 来收集各类应用的性能指标。目前 Elastic 针对各类语言及架构提供相应的 APM agents 来收集收集数据。

当我们把这些数据收集到 Elasticsearch 之后，在 Kibana 中的 APM 应用中，我们可以看见一系列的服务的列表：

在上面，我们展示了各种服务的一个总览信息。如上所示，我们可以看到系统运行的 environment，latency，throughput 以及 error rate。这里的各种服务可以是有各种语言来完成的。 如上所示，这些服务可以是 go 应用，也可以是 Python, .NET， JS，NodeJS, Java 等等。对于 APM 应用产品来说，一个很挑战性的工作就是很难把不同服务的 trace 进行相互关联。从上面的图中，我们很难看出来 frontend-node 这个 NodeJS 应用是否直接调用 advertService 这个服务？它们直接到底有什么联系？如果是，它们到底是如何发生的？

Distributed tracing 可以让我们轻松地把不同的服务进行相互关联，比如：

 在上面，它展示了 frontend-node 这个服务端的所有的 transactions。针对其中的 POS /checkout 这个 transactiion：

实际上，它的调用是由不同的服务的调用完成的。在上面，我们非常清楚地看到各个服务直接的调用关系并且各个服务所花的时间的多少。每个服务的调用是用同一个颜色来表示的。在上面红色的框里它表示的是整个 transaction 的调用流程：

我们针对应用的性能分析，选择一个 transaction 比较慢的来进行分析：

 如上所示，上述的 transaction 所花的时间是介于 2500 ms 到 3000 ms 之间。通过 APM 的运用，我们可以很快地定位到完成整个 transaction 中花费时间最多的服务：

在上面，我们可以清楚地看出来 EmptyCart 竟然需要花去 2154 ms 的时间。在这个服务中，它调用了 EmptyCartAsync 来完成的。它花去了 2150 ms 的时间来完成。我们点击上面的 EmptyCartAsync 这个 Span，我们可以看到更多的调用细节：

 它清楚地指出了在我们的代码中的哪一行代码执行的是很慢的。它清楚地显示了它占用了 77% 的 transaction 时间。这个信息对于我们大多数需要优化应用的性能是非常重要的。

Elastic APM 也提供了一个快速查看各类服务直接的调用关系。这个功能就叫做 Service Map：

 

 在上面，我们可以很清楚地看到各个服务直接的调用关系。如上所示， frontend-rum 是 transaction 的起点，它连接到一个重要的服务 frontend-node，同时它也连接到 cdn。frontend-node 也同时连接到其它的 4 个服务。其中的 advertService 连接到 Elasticsearch。APM 本身直接集成了机器学习。上面的每个服务上的圆圈的颜色代表了该服务的异常的最大值。如果该服务是绿色的，它表示该服务非常地健康，相反，如果它的颜色是红色则代表该服务不是很健康，需要我们去查看这个服务，并优化这个服务。比如，上面的 advertService 的颜色的绿色，则表示该服务非常健康：

 又比如，上面的 cartService 的颜色是黄色，则表示该服务已经被降级了，需要我们注意了。

 又比如，上面的 frontend-node 服务，它的颜色是橙色，则表示该服务是非常不健康的：

 这个服务需要我们去优化，并重点去调优。

我们点击 frondend-node，我们可以看到这个服务的概述：

 我们可以点击 Service Details 可以看到整个服务的 transactions 页面。通过 transaction 的分析，我们可以知道优化的地方。我们也可以点击 Focus map 来下钻这个服务。我们可以充分利用机器学习提供的功能来供我们进行分析:

我们可以点击上面的 ANOMALY DETECTION 来查看到底什么引起的异常：

总结

在这篇文章中，我们介绍了如何使用 Elastic APM 的分布式追踪来查看一些慢的服务，从而让开发者在开发的阶段就可以发现问题的所在，并优化自己的系统。另外 APM 应用中的 Service Map 提供了一个简便及快速的查看各个服务之前的关系。Service Map 集成了机器学习。它可以对我们的服务进行异常检测，从而评估服务的质量，为优化整个系统提供方向。