如何在 Kibana 使用 APM UI
Last updated
Last updated
如何透過 Kibana 的 APM UI 來進行效能的分析
APM UI 中的 Services、Traces、Dependencies、Service Map 的使用時機
Kibana Observability 功能中的 APM UI，在主選單中包含了四個選項：
Services (服務)
Traces (追縱)
Dependencies (相依性)
Service Map (服務地圖)
這四個功能貫串了整體 APM 的使用情境，以下我們將會各別介紹這四個功能的主要說明，以及使用的時機。
Service，是我們在 APM Agent 安裝時，指定的一個設定值，也是代表我們某個應用程式或某個服務的名稱，而 Kibana APM UI 也將 Service 定義成為一個主要的資料檢視的分類方式，讓我們能以 Service 的角度來檢視 Infrastructure 中各服務的狀態。
從『服務』或『應用程式』的整體角度，查詢效能狀況。
針對某一個『服務』或『應用程式』，裡面有發生哪些 Error？
針對某一個『服務』或『應用程式』，裡面所有的 Transaction 之中，執行最慢的是誰？有發生錯誤的比例是多少？發生錯誤的是誰？
針對某一個『服務』或『應用程式』，查看與他們相依的其他『服務』或『應用程式』有哪些？哪些其他服務的效能是瓶頸而受到牽連？
針對某一個『服務』或『應用程式』，快速查閱 CPU 與 Memory 的 Metrics 資訊。
如上圖在 Services 的 Overview 畫面之中，我們會有以下幾個部份：
Environment (環境)：我們可以直接針對指定在 APM Agent 收集資料時，先定義好的 Environment 資訊，例如： Production 環境、Staging 環境、或是我們自己定義的其他環境，進行籂選。
Search Box (搜尋區)：這個功能其實很彈性，讓我們自行依照想要的檢視條件，例如針對跑的特別慢的資料進行分析、或是經由我們自己事先加好的 tag 來篩選，可以專注在某種身份的會員、或是某種類型的產品…等。
Comparison (比較)：這是針對圖表中一些數據的走勢圖，我們預設要以之前的某段時間來做比較，例如上一週的同一時間、或是上個月的同一時間，這也是在分析異常狀況時常用的技巧。
時間篩選：使用 Kibana 標準的時間篩選器，指定時間的範圍。
服務列表：包含整體檢視時最重要的三個數據『平均延遲時間』、『吞吐量』、『交易失敗率』。
在這個畫面預設的排序方式，是照『健康狀態』，把最不健康的排最前面，讓我們優先掌握有問題的服務，而『健康狀態』的判定方式，是依照 Machine Learning 的 anomaly detection (異常偵測) 的功能，所以 ML 的這個功能要設定啟用才會有作用。
當我們點選某一個 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，讓我們能檢視某一個業務處理從頭到尾的過程，也就是對應到我們先前介紹到的 Transaction (交易)，中間的處理過程可能橫跨多個 Services，能讓我們做分散式追縱 (Distributed Tracing)，同時也會把相同的 Transaction 給 group 在一起，進行相同行為 Transaction 之間的校能比較與分析。
分散式追縱 (Distributed Tracing)，想知道某一個 Transaction (交易) 橫跨了哪些服務，中間有經過哪些處理、存取多少次資料庫、存取多少次快取…等。
對於某一個業務處理的執行效能不如預期，想要追縱是在哪個環節比較慢，
想分析哪一個 Transaction 對於整體系統的使用效能影響最大。
Traces 的總覽，會是以整體篩選條件底下，所有符合的 Transaction 全部一起排列出來，在這個畫面預設的排序方式，是依照 Impact (影響程度)，判定方式是依照最常使用以及反應時間最慢來決定影響的程度。
在 Traces 的列表中，點選其中一筆 Trace 的項目之後，其實就會進入到 Service 細部檢視當中的 Transactions (交易) 的畫面。
在這個畫面中，我們可以分析這個 API 在某段時間 Throughtput 較高時，與前一天、前一週、前一個月的同一段時間相比較是否一樣，也能從 Trace 的 Timeline 當中，查詢 Transaction 底下相關的 Spans，可以看到這個處理橫跨哪些服務，以及每個服務裡面執行的細節，這些細節的處理佔用了多少時間，並且在想要進行進一步調查時，可以透過 Investigate 進入 Elastic Observability 整合好的 Metrics 或是 Logs 的內容進行查看。
分析在 Infrastructure 中所使用的第三方服務或元件的效能狀況。
如果某個 Database (資料庫) 很慢，他的上游有哪些服務使用到他，以及這些服務的效能數據為何？
分析使用到外部的第三方服務時 (例如：金流 API)，最近一週每個時段的失敗率為多少?
這部份列出的，是『服務』或『應用程式』，所使用到的其他元件或是第三方服務，像是資料庫、外部的 HTTP 服務…等，並且讓我們從這些 dependencies 來分析對效能的影響。
在 Dependencies 的細部檢視的部份，讓我們除了能觀察這個 dependency 的效能數據，也會讓我們查看他的 Upstream (上游) 服候的效能數據，能協助我們判斷前後的影響關係，並且再進一步連結到 Service 細部檢視的頁面，進行查詢所影響的 Transaction 是哪些，甚至查詢實際執行的指令為何。
這個 Service Map 的檢視方式，是協助我們能以視覺化的方式，查看整體 Infrastructure 的服務與元件之前的相依關係，能協助我們追縱問題時，更精準的關注在需要注意的路徑上。
視覺化的掌握在 Infrastructure 中所有的『服務』、『應用程式』與第三方服務及元件之間的相依性。
從視覺化的地圖，快速掌握地圖上某個服務是否有發生異常。
可以透過 Service Map 以視覺化的圖形，查看整體 Infrastructure。
在 Abnormal Detection 有開啟的情況下，有問題的服務，會被標示成紅色，可以進一步進入 Machine Learning 頁面查看。
或是可以針對某個服務進入 Dependency 或是 Service 的細部檢視的頁面，進行進一步的分析。
以上是使用 Kibana Observability 中的 APM UI 所提供的功能，裡面的資料，是以 前一篇文章 所介紹的 APM Integration Testing 所產生的示範資料，在了解 Elastic APM 可以做到這些功能之後，下一篇我們將介紹進行自行架設的方式。
