[APM] 提升應用程式效能的利器 Elastic APM : APM 解決什麼問題

前言
資深的開發者都知道程式開發完成後上線後是個重大的挑戰，隨著功能的迭代系統功能會變得更複雜，如何確保當程式錯誤時可以更快速的 debug 與找到異常的問題或出問題的服務 (Service)是個重要的議題，因此自己在可觀測性如何落地過程中 suvery 很多不同工具發現 Elastic APM 是符合需求的，另外也支援近期火紅的 OpenTelemetry 蒐集遙測數據的開源框架，接著會預計整理成相關系列文章。這邊是研究 Elastic APM 的系列文第一篇，這系列主要會分為三篇分別是

• APM 解決什麼問題
• .NET x Elastic APM
• OpenTelemetry x Elastic APM 整合

若對於上述內容有問題或是不清楚的地方，歡迎提出來一起討論

真實世界的問題
如果自己公司產品或是系統在 PRODUCTION 環境壞掉會怎麼辦呢 ? 公司產品可能是電商系統，亦或者是演唱會在搶票或是 HR 產業上下班打卡的情境，這時候身為開發者或是資深工程師的你們，要如何找到可能的問題呢 ?
這時候我們可以問一下最近最夯的 chartGPT，身為一個不專業的工程師，請問線上網站壞掉了怎麼辦呢 ? chartGPT 的回答如下

這回答的重點是確認 Server 狀況、看 Log、尋找網站的維運人員來協助解決，但反過來說身為開發者的我們，當遇到緊急問題的時候要如何快速找到問題呢 ?
可能相對較完整的問題處理流程可能是如下圖所示

• 透過監控與系統預警機制，設定水位與警報告知提醒有潛在的問題發生 (Metrics + Logging)
• 當收到異常通知時，開啟監控 Dashboard 來釐清問題，使用常用的查詢與統計找到可能發生異常的模組 (Metrics)
• 針對模組與相關程式碼 Log 查詢與分析其問題，找到異常的 Log 資訊 (Logging)
• 定位可能的服務後，查詢其請求的鏈路追蹤定位問題代瑪 (Tracing)

可以發現在問題處理的流程中主要會透過 Metrics、Logging、Tracing 找到可能系統的異常問題，這也就是可觀測性一直以來提到的三個支柱觀念。在 2017 年時 Peter Bourgon 在 2017 Distributed Tracing Summit 後撰寫文章 Metrics, tracing, and logging，作者認為 Metrics 特徵是可以聚合的，Log 是處理離散的事件，Tracing 特徵是處理請求範圍的信息。三者在各自都有其功用與目的，如果缺少其中一項可能在對問題處理與時效上都會有些影響，並透過一張圖歸納三者的關聯與重疊部分，

如果對其有興趣想了解更多可以參考 連結，這裡不多加說明。

企業永續
上述處理問題的流程背後的目的想要解決的是企業永續經營(Business Continuity)，企業永續經營是個目標聽起來很遙遠那要怎麼達到呢 ? 可以透過企業永續經營企劃(Business continuity planning)來達到其目的，針對 BCP WIKI 說明如下

Any event that could negatively impact operations should be included in the plan, such as supply chain interruption, loss of or damage to critical infrastructure (major machinery or computing/network resource). As such, BCP is a subset of risk management.
A Business Continuity Plan outlines a range of disaster scenarios and the steps the business will take in any particular scenario to return to regular trade. 
BCP's are written ahead of time and can also include precautions to be put in place.

這聽起來有點高大尚離我們很遙遠，就我自己的理解就是制定其計畫，計畫內容是當意外發生的時候企業可以針對關鍵的流程快速恢復服務，降低意外發生時後對企業營運的影響。可以分為四個流程

• 識別企業關鍵流程與資源
• 確認關鍵流程的影響
• 定義解決方案
• 方案進行演練

實作上可以思考 Backup、Disaster Recovery、High Availability 三個方向(包含但不限)，以下就自己的理解做簡單的說明

• Backup : 不管傳統的機房或是雲端，企業重要資料都是需要備份 不然遭遇到天災時 應用程式重新佈署可以使用 但資料無法復原會是很尷尬的問題
• 災難備援 :要思考的是當災難發生時，要如何在最短的時間將網站快速恢復，網站佈署即恢復的流程怎麼進行、團隊分工分別是什麼、定期演練的規劃，當異常發生時接受噴掉多少資料及多久能恢復都是關鍵的問題與需要事前準備的。
• High Availability : 為了要達到系統的高可用性，要如何做好監控機制、告警機制如何通知、處理人員及異常事件處理流程與 SOP 分別是甚麼，最後產品的 SLA、SLO與 SLI 要怎麼定義，這些都是重要的考量與因素。

其中 SLA、SLO、SLI 的部分是很重要的一個環節，SLA 是產品與客戶的協議合約，SLO 要達到 SLA 是我產品所制定的目標，SLI 要達到目標所定義的指標，要先有辦法衡量才可以進行其管理與改善，才有機會知道我們做完了某些決策之後，是不是有變好進行下一步的調整方向。SLA 內容可以參考 .NET MVP 安德魯大師之前在 .NET Conf 2020 的分享，裡面有清楚定義三者關係，影片連結 Andrew Wu - 非同步系統的服務水準保證；淺談非同步系統的 SLO 設計 。

APM
接著進入這篇的重點 APM，什麼是 APM 呢 ? 一般來說有兩種定義分別是 Application Performance Monitoring 與 Application Performance Management，前者是後者的集合。APM 的目的可以幫助開發團隊在應用程式遭遇到錯誤或是異常問題時，快速的將問題定問與修復，縮短其平均修復時間(MTTR)，達到前面所提到的企業永續經營裡高可用性(HA)的目的。當然上述只是其中一個目的還可以幫助很多不同的面相，在 What is APM? Application performance monitoring guide 就有提到還可以解決以下問題

• 整合 APM 到整個網絡監控和管理工具中
• 確保應用程式 response 時間和用戶體驗
• 增加應用程式的正常運行時間/減少中斷時間
• 實施服務保障方法和服務水平均協議(SLA)
• 蒐集應用程式效能與元件/底層資訊

重點是希望透過 APM 來提高開發人員對於系統的了解 (Observability) 與縮短 MTTR (Mean Time to revocer)。

在 CNCF Landscape 有針對可觀測性 Observability 列出滿滿的專案，大致上分為 Monitor、Logging、Tracing、Chaos Engineer 與 Continuous Optimization 等各式各樣的專案與工具，其中要推薦的 Elastic APM 就是在其中之一，關於其介紹會在下一篇在說明 :)

參考
Metrics, tracing, and logging
Andrew Wu - 非同步系統的服務水準保證；淺談非同步系統的 SLO 設計