[APM] 提升應用程式效能的利器 Elastic APM : dotnet x Elastic

前言
這是 Elastic APM 的系列文第二篇，這篇文章將進入重點介紹 Elastic APM 與 dotnet 如何整合，如果想了解這篇系列文可以參考

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

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

Elastic APM
Elastic Stack 過去大家比較聽過的可能是 Elasticsearch 功能，自己過去與幾位朋友的公司在此用 ELK 也是用得很開心。在這幾年可觀測性這議題國外開始陸續流行，Elastic 也推出完整的可觀測性解決方案 Elastic Observability，從官方對於 Elastic Observability 介紹如下

在過去 Elastic 提供強大的系統日誌功能，Elastic Search 搜尋引擎是基於文本的日誌方式進行搜索。在 2018 年開始 Elastic 開始推出 Elastic APM 功能，替開發人員與運維團隊添加了應用程式跟蹤與分布式跟蹤功能，Elastic APM 提供一組代理，用於支援的語言和框架收集跟追蹤 Log 資訊並支援其開源標準 OpenTracing，後來也開始支援新的遙測數據標準 OpenTelemetry，並與跟蹤數據與 Metrics、Log 數據相關聯，再加上監控 Monitor uptime tool 功能，將其資料分類最後透過 Kibana 與 ElasticSearch 提供 Dev & Ops 團隊盤查，讓團隊可以更了解系統的狀況。

Why Elastic APM
簡單介紹完 Elastic Observability 之後，接著想要在跟大家分享為什麼會推薦 Elastic APM 呢 ? 主要會有幾個原因分別是

• Open source
• Centralized Platform
• Signals

接著針對這三點做簡單說明

Open source
這幾年 Open source 已經充斥在開發者的日常工作中，從開發到維運有各式各樣好用的工具都是開源的項目，自己覺得還有不錯的點是開發上不用重複造輪子，當今天需要某個功能時可能在 github 上就可以找到合適的解決方案，也越來越多大公司提供不同的 open source 解決方案，不用重新開發類似功能省下寶貴的時間。在團隊學習上，一些強大的開源項目在網路上有提供很多學習文件與教學，其學習資源是豐富的 (熱門專案)，在學習或是問題發生時相對都有機會降低解決問題時間。另外在找人上也是有幫助，一些熱門的工具或是解決方案在很多公司都會使用，因此團隊遇到要擴編或是找新人時，在人力資源市場上都較容易找到其熟悉此框架的開發者。

Centralized Platform
根據 CNCF Observability Report 2020 報告有提到為了解決線上問題，要從不同的數據與角度來嘗試發現可能的問題，各自工具有不同的技術有個各自的優勢，但各工具中沒有辦法各自整合，在使用上或是盤查線上問題時需要在不同的工具中進行切換，在調查中可以看到有一半公司會使用 5 種或是更多工具，其中 1/3 會使用 10 種以上的工具經驗。團隊在不停的切換上無形中也浪費很多時間，因此如果可以在同個平台上觀看就可以省下這些時間，也有機會提供問題的處理速度與提升 MTTR。

Signals

公司產品或各團隊都會定義其服務的 SLA，提到 SLA 就必須定義 SLO (目標) 與 SLI(指標)，在監控上這邊整理了幾個常見且重要的指標分別是 Golden Signals、Red 與 USE。Golden Signals 是由 google SRE book 所提出，關注的指標是 Latency、Traffic、Errors、Saturation。RED 與 USE 是 Golden Signals 的子集合 (面向稍微有些不同)，RED 著重的是了解應用程式外部的狀況，USE 則是在了解應用程式 Infra 內部的狀況。三種方法分別有不同想要看的指標與方向，我這邊簡單整理主要會有五個重要的指標內容 (上圖 five signals 欄位)，分別是

• Request Rate : 每秒請求的量為何
• Error Rate : 接收到這麼多請求錯誤率是多少
• Latency : 回應速度是不是正常的
• Saturation : 系統撐不撐得住
• Utilization : 系統有多忙碌

接著我們可以在回到 Elastic APM 可以看到其內建就支援這些重要的指標包含 Latency、Throughput (per second)、Failed rate、Time spend by spend time，對開發其維運人員是相當有幫助的，示意圖如下

另外在 Elastic APM 支援上述可觀測性三個重要的維度 Metrics、Logs 與 Traces，想要解決的出發點如下

• Metrics : Do I have a problem ?
• Traces : Where is the Problem
• Logs : What is causing the problem

Metrics

Traces

Logs

How Elastic APM works
上面說明了為甚麼選擇/推薦 Elastic APM 之後，接著我們來看身為開發人員可能會想了解 Elastic APM 是如何整合既有的應用程式

如上圖所示 Elastic APM 一共分為四部分分別是 APM agents, Elastic APM integration, Elasticsearch 與 Kibana，可以透過在既有的程式語言中加上 Elastic APM 所支援程式語言的 package 套件，目前主流的程式語言都有支援，支援列表可以參考此 官方文件，應用程式在運行時就會自動將數據資料蒐集送到 APM Server 中，可以分為五個步驟 分別是 設定 fleet、配置 Elastic APM、安裝 Elastic Agent、安裝 APM Agent 與 測試並查看結果。 在 Elastic 官方文件有其詳細的圖文並茂安裝步驟說明，這邊僅針對開發者較為相關的第四步驟進行解說，我們來看如果在 dotnet core 專案上要如何進行相關設定

安裝套件
開啟 nuget 並搜尋 Elastic.Apm.NetCoreAll，進行套件下載與安裝

應用程式加入代理
開啟 ASP.NET Core 應用程式，在專案 startup.cs 加上 app.UseAllElasticApm(Configuration) 方法

public class Startup
{
  public void Configure(IApplicationBuilder app, IHostingEnvironment env)
  {
    app.UseAllElasticApm(Configuration);
  }
}
  

配置組態檔
在 config 設定 服務名稱、APM Server URL 以及 Secret Token 等資訊，如下圖所示

{
    "ElasticApm": {
    "SecretToken": "",
    "ServerUrls": "http://localhost:8200", //Set custom APM Server URL (default: http://localhost:8200)
    "ServiceName" : "MyApp", //allowed characters: a-z, A-Z, 0-9, -, _, and space. Default is the entry assembly of the application
  }
}
  

上述提到都是基本(最小化)設定參數，在 Elastic APM 還支援多種配置設定像是環境變數(environment)、斷路器設定(circuit_breaker_enable) 及採集率(transaction_sample_rate)，採集率可以設定是否需要蒐集每筆交易，以降低開銷與 storage 空間，其值可以設定 0.0~1.0 之間，根據你的需求來定義請求的採集率。如果環境有要架設可以參考官方提供的 docker file 來建立其環境。
以上為簡單的說明 Elastic APM 如何與您的應用程式做整合的動作，如果你想看一下整合的結果測試，可以參考 Elastic APM 預設 Demo 的網站。裡面有測試資料可以讓你了解 Elastic APM 的強大之處。

此篇也差不多進入尾聲，今天介紹了 Elastic x APM 彼此怎麼整合，希望可以透過這篇分享能夠了解到基本上的應用，下一篇則是來介紹 Elastic APM 與 OpenTelemetry 如何進行整合。


參考
apm-quick-start

Read More

[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 設計

Read More