> For the complete documentation index, see [llms.txt](https://training.onedoggo.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://training.onedoggo.com/tech-sharing/uncle-joe-teach-es-elastc-observability/traces-guan-cha-ying-yong-cheng-shi-de-xiao-neng-ping-jing/ru-he-zai-kibana-shi-yong-apm-ui.md).

# 如何在 Kibana 使用 APM UI

### 本篇學習重點

* 如何透過 Kibana 的 APM UI 來進行效能的分析
* APM UI 中的 Services、Traces、Dependencies、Service Map 的使用時機

## Kibana Observability APM

Kibana Observability 功能中的 APM UI，在主選單中包含了四個選項：

* Services (服務)
* Traces (追縱)
* Dependencies (相依性)
* Service Map (服務地圖)

![19-kibana-apm-menu](https://i.imgur.com/nKS3lGJ.png)

這四個功能貫串了整體 APM 的使用情境，以下我們將會各別介紹這四個功能的主要說明，以及使用的時機。

### Services (服務)

Service，是我們在 APM Agent 安裝時，指定的一個設定值，也是代表我們某個應用程式或某個服務的名稱，而 Kibana APM UI 也將 Service 定義成為一個主要的資料檢視的分類方式，讓我們能以 Service 的角度來檢視 Infrastructure 中各服務的狀態。

#### 使用時機

* 從『服務』或『應用程式』的整體角度，查詢效能狀況。
* 針對某一個『服務』或『應用程式』，裡面有發生哪些 Error？
* 針對某一個『服務』或『應用程式』，裡面所有的 Transaction 之中，執行最慢的是誰？有發生錯誤的比例是多少？發生錯誤的是誰？
* 針對某一個『服務』或『應用程式』，查看與他們相依的其他『服務』或『應用程式』有哪些？哪些其他服務的效能是瓶頸而受到牽連？
* 針對某一個『服務』或『應用程式』，快速查閱 CPU 與 Memory 的 Metrics 資訊。

#### Overview (總覽)

![19-kibana-services-overview](https://i.imgur.com/DszV07g.png)

如上圖在 Services 的 Overview 畫面之中，我們會有以下幾個部份：

1. Environment (環境)：我們可以直接針對指定在 APM Agent 收集資料時，先定義好的 Environment 資訊，例如： `Production` 環境、`Staging` 環境、或是我們自己定義的其他環境，進行籂選。
2. Search Box (搜尋區)：這個功能其實很彈性，讓我們自行依照想要的檢視條件，例如針對跑的特別慢的資料進行分析、或是經由我們自己事先加好的 `tag` 來篩選，可以專注在某種身份的會員、或是某種類型的產品…等。
3. Comparison (比較)：這是針對圖表中一些數據的走勢圖，我們預設要以之前的某段時間來做比較，例如上一週的同一時間、或是上個月的同一時間，這也是在分析異常狀況時常用的技巧。
4. 時間篩選：使用 Kibana 標準的時間篩選器，指定時間的範圍。
5. 服務列表：包含整體檢視時最重要的三個數據『平均延遲時間』、『吞吐量』、『交易失敗率』。

> 在這個畫面預設的排序方式，是照『健康狀態』，把最不健康的排最前面，讓我們優先掌握有問題的服務，而『健康狀態』的判定方式，是依照 Machine Learning 的 anomaly detection (異常偵測) 的功能，所以 ML 的這個功能要設定啟用才會有作用。

#### Service 細部檢視

![19-Kibana-APM-Services](https://i.imgur.com/HykrWE3.gif)

當我們點選某一個 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 (影響程度)，判定方式是依照**最常使用**以及**反應時間最慢**來決定影響的程度。

![19-kibana-apm-traces-overview](https://i.imgur.com/BnaMMoQ.png)

#### Traces 細部檢視

在 Traces 的列表中，點選其中一筆 Trace 的項目之後，其實就會進入到 Service 細部檢視當中的 Transactions (交易) 的畫面。

![19-Kibana-APM-Traces](https://i.imgur.com/VHRTX5x.gif)

在這個畫面中，我們可以分析這個 API 在某段時間 Throughtput 較高時，與前一天、前一週、前一個月的同一段時間相比較是否一樣，也能從 Trace 的 Timeline 當中，查詢 Transaction 底下相關的 Spans，可以看到這個處理橫跨哪些服務，以及每個服務裡面執行的細節，這些細節的處理佔用了多少時間，並且在想要進行進一步調查時，可以透過 Investigate 進入 Elastic Observability 整合好的 Metrics 或是 Logs 的內容進行查看。

### Dependencies (相依性)

#### 使用時機

* 分析在 Infrastructure 中所使用的第三方服務或元件的效能狀況。
* 如果某個 Database (資料庫) 很慢，他的上游有哪些服務使用到他，以及這些服務的效能數據為何？
* 分析使用到外部的第三方服務時 (例如：金流 API)，最近一週每個時段的失敗率為多少?

#### Overview (總覽)

這部份列出的，是『服務』或『應用程式』，所使用到的其他元件或是第三方服務，像是資料庫、外部的 HTTP 服務…等，並且讓我們從這些 dependencies 來分析對效能的影響。

![image-20211004235227398](https://i.imgur.com/VsQAfFN.png)

#### Dependencies 細部檢視

在 Dependencies 的細部檢視的部份，讓我們除了能觀察這個 dependency 的效能數據，也會讓我們查看他的 Upstream (上游) 服候的效能數據，能協助我們判斷前後的影響關係，並且再進一步連結到 Service 細部檢視的頁面，進行查詢所影響的 Transaction 是哪些，甚至查詢實際執行的指令為何。

![image-20211004235427372](https://i.imgur.com/QHP5aBq.png)

### Service Map (服務地圖)

這個 Service Map 的檢視方式，是協助我們能以視覺化的方式，查看整體 Infrastructure 的服務與元件之前的相依關係，能協助我們追縱問題時，更精準的關注在需要注意的路徑上。

#### 使用時機

* 視覺化的掌握在 Infrastructure 中所有的『服務』、『應用程式』與第三方服務及元件之間的相依性。
* 從視覺化的地圖，快速掌握地圖上某個服務是否有發生異常。

#### Overview (總覽)

可以透過 Service Map 以視覺化的圖形，查看整體 Infrastructure。

![19-apm-service-map](https://i.imgur.com/2yn55Vj.png)

#### Service Map 細部檢視

在 Abnormal Detection 有開啟的情況下，有問題的服務，會被標示成紅色，可以進一步進入 Machine Learning 頁面查看。

或是可以針對某個服務進入 Dependency 或是 Service 的細部檢視的頁面，進行進一步的分析。

![19-Kibana-APM-ServiceMap](https://i.imgur.com/u5D6ZPr.gif)

***

以上是使用 Kibana Observability 中的 APM UI 所提供的功能，裡面的資料，是以 [前一篇文章](https://ithelp.ithome.com.tw/articles/10277150) 所介紹的 [APM Integration Testing](https://github.com/elastic/apm-integration-testing) 所產生的示範資料，在了解 Elastic APM 可以做到這些功能之後，下一篇我們將介紹進行自行架設的方式。

## 參考資訊

1. [官方文件 - Kibana APM - Get Started](https://www.elastic.co/guide/en/kibana/current/apm-getting-started.html)