[APM] 提升應用程式效能的利器 Elastic APM : dotnet x Elastic ~ m@rcus 學習筆記

前言
這是 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

m@rcus 學習筆記

只有累積，沒有奇蹟

2023年3月12日星期日