[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

[AzureDevops] 如何使用 Azure DevOps 和 Teams 提高代碼審查的效率

前言
現在團隊是使用 Azure Devops repo 作為版控，在既有開發規範是開發完功能後會發 PR(Pull request) 給資深同仁 Review，開發同仁會將 PR 的網址貼在 Teams 群組上，再請負責 code review 同仁看內容是否有需要調整的地方，過去大家很習慣這樣方式進行也因為太忙也沒太多時間研究是否有更好的方法，今天強者同事分享其實在 Azure Devops 內建機制可以整合到 Teams 頻道發送 PR 通知，花點時間了解後覺得十分方便，這篇文章就來針對這好用強大的功能作筆記，若有問題歡迎提出來一起討論。

設定通知
這步驟主要目的是在專案設定通知到指定的 Teams 頻道中，首先要建立 subscription 與其規則，有以下幾個步驟要進行設定

• Step 1 : 到要設定 PR 通知專案的 Repo 進行設定，點選 Project Settings
• Step 2 : 進入到 project Settings 頁面後裡點選 Notifications Tab
• Step 3 : 按下上方 New subscription

接著要設定 subscription 內容，可以依據實務上團隊的項目來進行調整，目前公司是使用 AzureDevops 的 git repo 解決方案，因此在此步驟要選擇 Code(Git)，Template 部分是當作甚麼動作的時候要被通知，這裡 Demo 的是希望當 PR 建立成功和更新時要發送通知到 Teams，因此選擇 pull request is created or updated.，確認無誤後按下下一步按鈕

設定新通知
在 Azure Devops 有下列多種通知方式

• Member of project by role
• Team preference
• Custom email address
• Member of project team
• SOAP

差異可以參考 MSDN 官方說明文件 Pull request update notifications，這裡就不在多說明。今天要介紹的方式是通知到 Teams，因此在這邊選擇 Custom email address 選項

Address 部分資料可以從 Teams 頻道取得，到要通知的 Teams 頻道按下右鍵點選取得郵件地址，會跳出視窗複製其 email 即可，再貼在 address 欄位上。

Filter criteria 則是可以根據什麼動作要進行訊息的通知，可以根據團隊的需求在下方的 Add new clause 新增 or 修改調整其設定值，這裡選擇當團隊在 repo 建立 pull request 時發送其通知，確認內容無誤後接著按下 finish 按鈕設定即完成。 建立無誤後，則可以在 notifications 設定區塊看到稍早新增完成的設定項目，這裡右方有開關可以依據情境來設定是否要開啟關閉的動作。

測試
接著我們到 Azure Devops 專案發送 PR 看設定是否成功，在 repo 頁籤新增 PR (new pull request)，輸入 test 後按下送出按鈕

可以在稍早設定的 Teams 頻道中看到測試發送的 PR 請求內容，大功告成 !

感想
這次在強者同事分享下又多知道 Azure Devops 的強大功能之一，這些方便的功能都可以替團隊帶來更好的效益，日後如果有在實務上學到更好玩的功能，也會再與大家分享，以上如果有不清楚的地方歡迎一起討論 :) !

參考
pull request

Read More

[Free] 電子書 : OpenTelemetry 可觀測性的未來

前言
在 2021 年因為接觸可觀測性工具 Signoz 意外發現 OpenTelemetry 收集遙測數據的標準，開始覺得議題很好玩這框架十分有趣，在找電子書的過程中意外發現由 O'Reilly 出品的 The Future of Observablity with OpeTelemetry，內容十分不錯，作者也是對於分散式系統頗有研究的大師，由於此新議題市面上的電子書不多，因此花了點時間參考大陸開源有名的前輩 Jimmy Song 翻譯的簡中版，整理一份繁體中文版給有需要的夥伴們。

此書章節如下

• 前⾔
• 第 1 章：可觀測性的歷史
• 第 2 章：結構化數據的價值
• 第 3 章：⾃動分析的局限性
• 第 4 章：⽀持開源和原⽣監測
• 第 5 章：OpenTelemetry 架構概述
• 第 6 章：穩定和⻑期⽀持
• 第 7 章：建議的設置和遙測管道
• 第 8 章：如何在組織中推廣 OpenTelemetry
• 附錄 A：OpenTelemetry 項⽬組織

如何取得電子書
基於「取之網路，用之網路」的精神，此電子書是免費的，如果您喜歡這本電子書或者它對您有幫助，請您高抬貴手在 GitHub 電子書項目專案給我一些鼓勵 ⭐️⭐️⭐️ : 傳送門

Read More

[NETCore] 如何設定 ASP.NET Core 健康檢查（Health Check）功能 - Health Check UI

前言
在前一篇針對 ASP.NET Core 2.2 新特性 Health Check功能做基本的介紹，接著要分享的是在 BeatPulse 中實用的功能 Health Check UI，提供 UI 介面顯示及儲存 Health Check 檢查的結果內容，如果有多台時也可以在設定檔加上指定 URL 達到同時監控多台的效果，此篇就針對 Health Check UI 做介紹，若有問題或是錯誤的地方歡迎網路的高手大大給予指導。

Health Check UI
要使用 Health Check UI 起手式是要安裝其套件  AspNetCore.HealthChecks.UI ，指令如下

install-package AspNetCore.HealthChecks.UI  

安裝完 nuget package 之後，在 Startup.cs 要註冊 service 與 middleware，定義 healthCheck 的路徑為 /hc，UI 顯示的路徑為 /hc-ui

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddHealthChecksUI();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseHealthChecks("/hc", new HealthCheckOptions
        {
            Predicate = _ => true,
            ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
        });

        app.UseHealthChecksUI(options =>
        {
            options.UIPath = "/hc-ui";
        });        
    }
}  

下一步是 appsettings.json 加上 healthCheckUI 設定資訊，設定包含要檢查的內容網址、多久執行檢查的動作與發生意外時的處理機制，這裡設定每 10 秒進行一次檢查，檢查的內容來源為 /hc

"HealthChecks-UI": {
    "HealthChecks": [
      {
        "Name": "Health Check Demo",
        "Uri": "http://localhost:5000/hc"
      }
    ],
    "EvaluationTimeOnSeconds": 10,
    "MinimumSecondsBetweenFailureNotifications": 60
  }

檢查內容這裡沿用上一篇介紹 healthCheck 的內容項目，檢查 mssql、Redis、Memory 與第三方 url 檢康狀況，這裡就不在多加說明，想了解細節可以參考上一篇文章內容說明

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
    
    services.AddHealthChecksUI();

    services.AddHealthChecks()
        .AddMemoryHealthCheck("Memory Health Check")
        .AddSqlServer(Configuration["ConnectionStrings:DefaultConnection"], name: "SQL Server HealthCheck")
        .AddRedis(Configuration["ConnectionStrings:RedisConn"], name: "Redis HealthCheck")
        .AddUrlGroup(new Uri("https://marcus116.blogspot.com"), "ThirdParty API HealthCheck",HealthStatus.Degraded);
    //省略
}

以上設定完畢後，執行專案並在瀏覽器輸入 /hc-ui，就可以看到將檢查的字串內容變為圖像顯示

Docker Image
作者也有提供 Docker health check image 給需要的人使用，可以透過 docker pull 取得 health check image 並使用 docker run 來執行

PS C:\> docker pull xabarilcoding/healthchecksui
Using default tag: latest
latest: Pulling from xabarilcoding/healthchecksui
27833a3ba0a5: Pull complete
25dbf7dc93e5: Pull complete
0ed9cb15d3b8: Pull complete
874ea13b7488: Pull complete
73d82f2e96ee: Pull complete
f856979cdc5c: Pull complete
Digest: sha256:fe18f7655f05872cd8b2644ce7d4603b1d03ae4e0b24fa59f4d960cdc7bde6c4
Status: Downloaded newer image for xabarilcoding/healthchecksui:latest
PS C:\> docker run --name healthcheck-ui -p 5000:80 -d xabarilcoding/healthchecksui:latest

詳細可以參考 HealthChecks UI Docker Image

感想
使用 health Check UI 幫助我們可以更快的了解需要檢查應用程式的健康狀態資訊，如果您的應用程式有不止一台，可以在 health Check Ui 設定檔節點新增多筆檢查來源與名稱來自訂不同的檢查行為，舉例來說 MSDN 有列出如果 Health Check 顯示多筆，希望這篇介紹可以有幫助到有需要的朋友，謝謝

參考
Health checks in ASP.NET Core

ASP.NET Core MVC - 2.2 Health Checks

Read More

[NETCore] 如何設定 ASP.NET Core 健康檢查（Health Check）功能

前言
過去當應用程式開發完成之後，另外一項重要的事情就是建立上線後的監控機制，尤其是重要性高的服務更是不可或缺的事情，有遇過公司是在站台底下放置一個檔案內容文字是OK，在透過工具固定時間去確認網站底下這檔案是否有正常回傳，就可代表網站是否存活者，各種不同的實作方式都可以達到此目的；在 ASP.NET Core 2.2 開始提供 Health Check 中介層 (Middleware)，透過 HTTP 方式可以即時取得應用程式的健康狀況，在使用與設定上容易上手，此篇就介紹在 ASP.NET Core 中如何使用及設定 Health Check 的方式，即時的取得應用程式健康狀況，若有問題或是錯誤的地方歡迎網路的高手大大給予指導。

基本使用
Health Check 為 ASP.NET Core 2.2 內建，因此使用前不需要透過 nuget 下載任何 package 套件，只需要簡單的註冊服務就可以使用，首先在  Sartup.cs  中的 ConfigureServices 方法中加上 AddHealthChecks 註冊 Health Checks 服務，接著在 configure 中新增 UseHealthChecks middleware 並指定位置，即可完成基本的 Health Chcek 健康檢查的應用，代碼如下

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks();
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseHealthChecks("/health");

    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Navigate to /health to see the health status.");
    });
} 

執行應用程式，透過瀏覽器開啟 /health 就可以看到回傳的結果

HealthCheckOptions
上面介紹了最基本的使用方式，實務上常常會需要得到更多資訊，有時候可能會需要自定義 Health Check 回傳的 HTTP Status 狀態，或是輸出不同的格式情境時，就可以使用  HealthCheclOptions  來自訂不同的檢查行為，以下範例是自訂檢查輸出為 Json，並輸出檢查細節的所有內容資訊

app.UseHealthChecks("/health", new HealthCheckOptions
{
    ResponseWriter = async (context, report) =>
    {
        var json = JsonConvert.SerializeObject(report);
        context.Response.ContentType = "application/json";
        await context.Response.WriteAsync(json);
    }
});

回傳結果為目前應用程式狀態是正常 (Status=2=Health)，以及 Health Check 所花費的時間

{
    "Entries": {},
    "Status": 2,
    "TotalDuration": "00:00:00.0000048"
}

當然如果只想要內容跟結果，可以調整 HealthCheckOptions 內容輸出指定需要的資訊，舉例來說我只想看 Status 跟 error 內容，代碼如下

app.UseHealthChecks("/health",
    new HealthCheckOptions
    {
        ResponseWriter = async (context, report) =>
        {
            var result = JsonConvert.SerializeObject(
                new
                {
                    status = report.Status.ToString(),
                    errors = report.Entries.Select(e => new { key = e.Key, value = Enum.GetName(typeof(HealthStatus), e.Value.Status) })
                });
            context.Response.ContentType = MediaTypeNames.Application.Json;
            await context.Response.WriteAsync(result);
        }
    });

回傳結果如下

{
    "Status": 2,
    "error": []
}

檢查依賴項目健康狀態
應用程式在開發中會使用到資料庫或是不同服務，BeatPulse 提供多個檢查項目的 API，透過這些 API 可以檢查依賴內容的健康狀況，舉例來說可以檢查 SQL、Redis、Network、Kafka、Aws.S3 等不同依賴於應用程式所使用的服務，如果要使用時後僅需要下載對應 package 和使用擴充方法就健康資訊。
舉例來說我的 ASP.NET Core API 有資料庫是使用 MS SQL，Cache 是使用 Redis，另外還有使用到第三方 API，以上可以在 Health Check 中設定，首先須先下載用到的 package

Install-Package AspNetCore.HealthChecks.SqlServer
Install-Package AspNetCore.HealthChecks.Redis
Install-Package AspNetCore.HealthChecks.Uris

接著在ConfigureServices 方法中加上 AddSqlServer、AddRedis、AddUrlGroup 等擴充方法，並指定其連線字串及網址內容 

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddHealthChecks()
        .AddSqlServer(Configuration["ConnectionStrings:DefaultConnection"], name: "SQL Server HealthCheck")
        .AddRedis(Configuration["ConnectionStrings:RedisConn"], name: "Redis HealthCheck")
        .AddUrlGroup(new Uri("https://marcus116.blogspot.com"), "ThirdParty API HealthCheck", HealthStatus.Degraded);
}

執行應用程式並開啟 health 頁面，可以看到檢查 MSSQL、Redis 以及外部服務 Domain 的結果

在每個 Health Check 方法也支援參數指定其標籤、名稱、失敗時的狀態等資訊，以下為 SQL Server 檢查，如果有需要的話也可以建立多個 SQL Server 健康檢查

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddHealthChecks()
                .AddSqlServer(
                    connectionString: Configuration["ConnectionStrings:DefaultConnection"],
                    healthQuery: "select 1",
                    name: "MSSQL Check",
                    failureStatus: HealthStatus.Degraded,
                    tags: new string[] {"database", "sqlServer"});
}

更多細節及說明可以參考 GitHub 上的官網內容 : 傳送門 

自訂健康檢查
假設在 AspNetCore.Diagnostics.HealthChecks 都不符合您的需求，可以透過實作  IHealthCheck  介面來自己定義需要健檢的項目內容，舉例來說可以檢查應用程式記憶體 (Memory) 的使用量，如果使用超過設定值時就會報告狀態為不健康有可能需要降級的動作，下列代碼為參考 MSDN 定義的 MemoryHealthCheck 方法與 MemoryCheckOptions 類別，定義 Memory 上限水位為 1G

public class MemoryHealthCheck : IHealthCheck
{
    private readonly IOptionsMonitor<MemoryCheckOptions> _options;

    public MemoryHealthCheck(IOptionsMonitor<MemoryCheckOptions> options)
    {
        _options = options;
    }

    public string Name => "memory_check";

    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken cancellationToken = default(CancellationToken))
    {
        var options = _options.Get(context.Registration.Name);

        // Include GC information in the reported diagnostics.
        var allocated = GC.GetTotalMemory(forceFullCollection: false);
        var data = new Dictionary<string, object>()
        {
            { "AllocatedBytes", allocated },
            { "Gen0Collections", GC.CollectionCount(0) },
            { "Gen1Collections", GC.CollectionCount(1) },
            { "Gen2Collections", GC.CollectionCount(2) },
        };

        var status = (allocated < options.Threshold) ?
            HealthStatus.Healthy : HealthStatus.Unhealthy;

        return Task.FromResult(new HealthCheckResult(
            status,
            description: "Reports degraded status if allocated bytes " +
                         $">= {options.Threshold} bytes.",
            exception: null,
            data: data));
    }
}

public class MemoryCheckOptions
{
    // Failure threshold (in bytes)
    public long Threshold { get; set; } = 1024L * 1024L * 1024L;
}

接著可以透過兩種方式加入檢查

AddMemoryHealthCheck 擴充方法
要來寫  AddMemoryHealthCheck  擴充方法，在 ConfigureServices 才可以用到

public static class GCInfoHealthCheckBuilderExtensions
{
    public static IHealthChecksBuilder AddMemoryHealthCheck(
        this IHealthChecksBuilder builder,
        string name,
        HealthStatus? failureStatus = null,
        IEnumerable<string> tags = null,
        long? thresholdInBytes = null)
    {
        // Register a check of type GCInfo.
        builder.AddCheck<Startup.MemoryHealthCheck>(
            name, failureStatus ?? HealthStatus.Degraded, tags);

        // Configure named options to pass the threshold into the check.
        if (thresholdInBytes.HasValue)
        {
            builder.Services.Configure<Startup.MemoryCheckOptions>(name, options =>
            {
                options.Threshold = thresholdInBytes.Value;
            });
        }

        return builder;
    }
}

下一步就是與之前說明的相同，到 ConfigureServices 加上 AddMemoryHealthCheck 方法，另外還想知道自訂檢查中的 GC 記憶體用量狀況 (GenCollections 0、1、2)，因此 Config 內容也調整為輸出全部資訊

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddHealthChecks()
        .AddMemoryHealthCheck("Memory Health Check");
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseHealthChecks("/health",
        new HealthCheckOptions
        {
            ResponseWriter = async (context, report) =>
            {
                var result = JsonConvert.SerializeObject(report);
                context.Response.ContentType = MediaTypeNames.Application.Json;
                await context.Response.WriteAsync(result);
            }
        });

    // 省略 
}

重新執行應用程式，成功輸出其內容資訊

AddCheck<T>
使用  AddCheck  注入的方式加入檢查，如下  

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddHealthChecks()
        .AddCheck<MemoryHealthCheck>("Memory Health Check");

        services.AddSingleton<MemoryHealthCheck>();
    // 省略
}

結果與使用 AddMemoryHealthCheck 相同，這裡就不在重複貼。

感想
介紹了很多 ASP.NET Core 新功能 Health Check 的基本使用，相信對於在 ASP.NET Core 中使用 health check 了解更多，以上算是簡單的使用情境說明，當應用程式不只一台或是要健檢的項目變多的時候，確認 health check 回傳的 status 狀況上就會變得不單純，因此下一篇會介紹 Health Check UI 的設定及如何使用 Publisher 方式推到某一台方便進行監控及管理，希望這篇介紹可以有幫助到有需要的朋友，謝謝

參考
Health checks in ASP.NET Core

AspNetCore.Diagnostics.HealthChecks
ASP.NET Core MVC - 2.2 Health Checks
AspNetCore 2.2 新特性---HealthCheck
How to set up ASP.NET Core 2.2 Health Checks 
Using the Microsoft.AspNetCore.HealthChecks Package
Health Checks in ASP.NET Core

Read More