19 - Traces - 观察应用程序的效能瓶颈 (3/6) - 如何在 Kibana 使用 APM UI

Traces - 观察应用程序的效能瓶颈 系列文章

• (1/6) - Elastic APM 基本介绍
• (2/6) - 使用 APM-Integratoin-Testing 建立 APM 的模拟环境
• (3/6) - 如何在 Kibana 使用 APM UI
• (4/6) - 使用 APM Server 来收集 APM 数据
• (5/6) - 透过 APM Agents 收集并传送後端服务运作的记录
• (6/6) - 透过真实使用者监控 (RUM, Real User Monitoring) 来改善使用者体验

本篇学习重点

• 如何透过 Kibana 的 APM UI 来进行效能的分析
• APM UI 中的 Services、Traces、Dependencies、Service Map 的使用时机

Kibana Observability APM

Kibana Observability 功能中的 APM UI，在主选单中包含了四个选项：

• Services (服务)
• Traces (追纵)
• Dependencies (相依性)
• Service Map (服务地图)

这四个功能贯串了整体 APM 的使用情境，以下我们将会各别介绍这四个功能的主要说明，以及使用的时机。

Services (服务)

Service，是我们在 APM Agent 安装时，指定的一个设定值，也是代表我们某个应用程序或某个服务的名称，而 Kibana APM UI 也将 Service 定义成为一个主要的资料检视的分类方式，让我们能以 Service 的角度来检视 Infrastructure 中各服务的状态。

使用时机

• 从『服务』或『应用程序』的整体角度，查询效能状况。
• 针对某一个『服务』或『应用程序』，里面有发生哪些 Error？
• 针对某一个『服务』或『应用程序』，里面所有的 Transaction 之中，执行最慢的是谁？有发生错误的比例是多少？发生错误的是谁？
• 针对某一个『服务』或『应用程序』，查看与他们相依的其他『服务』或『应用程序』有哪些？哪些其他服务的效能是瓶颈而受到牵连？
• 针对某一个『服务』或『应用程序』，快速查阅 CPU 与 Memory 的 Metrics 资讯。

Overview (总览)

如上图在 Services 的 Overview 画面之中，我们会有以下几个部份：

1. Environment (环境)：我们可以直接针对指定在 APM Agent 收集资料时，先定义好的 Environment 资讯，例如： Production 环境、Staging 环境、或是我们自己定义的其他环境，进行籂选。
2. Search Box (搜寻区)：这个功能其实很弹性，让我们自行依照想要的检视条件，例如针对跑的特别慢的资料进行分析、或是经由我们自己事先加好的 tag 来筛选，可以专注在某种身份的会员、或是某种类型的产品…等。
3. Comparison (比较)：这是针对图表中一些数据的走势图，我们预设要以之前的某段时间来做比较，例如上一周的同一时间、或是上个月的同一时间，这也是在分析异常状况时常用的技巧。
4. 时间筛选：使用 Kibana 标准的时间筛选器，指定时间的范围。
5. 服务列表：包含整体检视时最重要的三个数据『平均延迟时间』、『吞吐量』、『交易失败率』。

在这个画面预设的排序方式，是照『健康状态』，把最不健康的排最前面，让我们优先掌握有问题的服务，而『健康状态』的判定方式，是依照 Machine Learning 的 anomaly detection (异常侦测) 的功能，所以 ML 的这个功能要设定启用才会有作用。

Service 细部检视

当我们点选某一个 Services 後，会进入这个 Service 自己的 Overview (总览) 画面，当中包含这个 Server 与效能、执行错误直接相关的

• Latency (延迟)
• Throughput (吞吐量)
• Transaction(交易) 效能较差的前五名，以及他们的效能相关的数据。
• Failed Transaction Rate (交易失败率)
• Errors (错误)
• Time spent by span type：每个 span 所花费的时间比例。
• Depencencies (相依性)：所有与这个 Service 有相依的服务或是其他元件的效能影响数据。
• Instances Latency Distribution (实例延迟的分布)：也就是这个服务有哪一些实际布署的 instance，以及这些 instance 这段时间的平均数据的分布，方便查看问题会不会是出在某一台特定的机器上。
• Instances (实例)：这个服务实际布署的 instances，以及这些 instance 的效能数据.

注意：这边我们在查阅的 Metrics 预设是 Average，但有时我们要分析效能状况时，有时会要去掉极度的数据，这时记得可以用这个功能选择 95th percentile 或是 99th percentile 。

至於每个服务细部检视的画面，都能再进一步查询这个服务的 Transactions、Dependencies、Errors、Metrics、Service Map、Logs，这部份可以从上方的 GIF 图档的动画查看。

Traces (追纵)

Traces，让我们能检视某一个业务处理从头到尾的过程，也就是对应到我们先前介绍到的 Transaction (交易)，中间的处理过程可能横跨多个 Services，能让我们做分散式追纵 (Distributed Tracing)，同时也会把相同的 Transaction 给 group 在一起，进行相同行为 Transaction 之间的校能比较与分析。

使用时机

• 分散式追纵 (Distributed Tracing)，想知道某一个 Transaction (交易) 横跨了哪些服务，中间有经过哪些处理、存取多少次资料库、存取多少次快取…等。
• 对於某一个业务处理的执行效能不如预期，想要追纵是在哪个环节比较慢，
• 想分析哪一个 Transaction 对於整体系统的使用效能影响最大。

Overview (总览)

Traces 的总览，会是以整体筛选条件底下，所有符合的 Transaction 全部一起排列出来，在这个画面预设的排序方式，是依照 Impact (影响程度)，判定方式是依照最常使用以及反应时间最慢来决定影响的程度。

Traces 细部检视

在 Traces 的列表中，点选其中一笔 Trace 的项目之後，其实就会进入到 Service 细部检视当中的 Transactions (交易) 的画面。

在这个画面中，我们可以分析这个 API 在某段时间 Throughtput 较高时，与前一天、前一周、前一个月的同一段时间相比较是否一样，也能从 Trace 的 Timeline 当中，查询 Transaction 底下相关的 Spans，可以看到这个处理横跨哪些服务，以及每个服务里面执行的细节，这些细节的处理占用了多少时间，并且在想要进行进一步调查时，可以透过 Investigate 进入 Elastic Observability 整合好的 Metrics 或是 Logs 的内容进行查看。

Dependencies (相依性)

使用时机

• 分析在 Infrastructure 中所使用的第三方服务或元件的效能状况。
• 如果某个 Database (资料库) 很慢，他的上游有哪些服务使用到他，以及这些服务的效能数据为何？
• 分析使用到外部的第三方服务时 (例如：金流 API)，最近一周每个时段的失败率为多少?

Overview (总览)

这部份列出的，是『服务』或『应用程序』，所使用到的其他元件或是第三方服务，像是资料库、外部的 HTTP 服务…等，并且让我们从这些 dependencies 来分析对效能的影响。

Dependencies 细部检视

在 Dependencies 的细部检视的部份，让我们除了能观察这个 dependency 的效能数据，也会让我们查看他的 Upstream (上游) 服候的效能数据，能协助我们判断前後的影响关系，并且再进一步连结到 Service 细部检视的页面，进行查询所影响的 Transaction 是哪些，甚至查询实际执行的指令为何。

Service Map (服务地图)

这个 Service Map 的检视方式，是协助我们能以视觉化的方式，查看整体 Infrastructure 的服务与元件之前的相依关系，能协助我们追纵问题时，更精准的关注在需要注意的路径上。

使用时机

• 视觉化的掌握在 Infrastructure 中所有的『服务』、『应用程序』与第三方服务及元件之间的相依性。
• 从视觉化的地图，快速掌握地图上某个服务是否有发生异常。

Overview (总览)

可以透过 Service Map 以视觉化的图形，查看整体 Infrastructure。

Service Map 细部检视

在 Abnormal Detection 有开启的情况下，有问题的服务，会被标示成红色，可以进一步进入 Machine Learning 页面查看。

或是可以针对某个服务进入 Dependency 或是 Service 的细部检视的页面，进行进一步的分析。

以上是使用 Kibana Observability 中的 APM UI 所提供的功能，里面的资料，是以 前一篇文章 所介绍的 APM Integration Testing 所产生的示范资料，在了解 Elastic APM 可以做到这些功能之後，下一篇我们将介绍进行自行架设的方式。

参考资讯

1. 官方文件 - Kibana APM - Get Started

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！