Day 16：Kong + API 的 Grafana 儀表板監控與告警

17th鐵人賽 devops kong grafana

山姆大叔

團隊邦邦不邦邦

2025-09-29 06:38:54

12 瀏覽

分享至

Grafana 的Dashboard

前面有說到，Grafana最大的強項就是漂亮的dashboard，要從頭自己做一個dashboard其實真的很難，第一個議題就是到底這個dashboard要看甚麼？

筆者前面有講到，這些dashboard儀錶板看起來真的很帥氣，但到底哪些需要被呈現在儀表板上？這時候其實我們要思考一下，到底哪一些資訊是內部資訊人員(或長官)真正關心的事務，哪些狀態會真正的影響到系統的維運？進而會需要在警報響起時，維運人員會進場確認，並將問題解決後，可以讓維運不至於陷入危險狀態而可以持續維運。

不過自己要從頭開始設計一個儀表板其實非常不容易，因為Grafana基本上可以接到非常多的資料源，例如：

prometheus：這次筆者就是透過grafana來介接到prometheus這個資料來源，如果要自己客製儀表板，那筆者就需要學會使用 PromQL（Prometheus Query Language），這是一種專門用來查詢時序資料的語言，可以進行聚合、過濾、計算等操作。
Elasticsearch：使用 Lucene 查詢語法或 Elasticsearch Query DSL，這些語法適合搜尋與分析全文索引資料。
SQL Server：使用標準 SQL 查詢語言，適合進行結構化資料的查詢、過濾與彙總。

SQL是筆者在以前寫程式時，就學會的一種語言，但其他的都沒碰過啊!!!!!

幸好，筆者在接觸Grafana時，接觸到了 Grafana 官方 Dashboard 市集，只要搜尋關鍵字，就能找到適合自己服務的 Dashboard，直接匯入後即可快速開始監控，

Kong-Offical

如果讀者直接殺到Grafana 官方 Dashboard 市集，打入Kong official關鍵字，會跑出一大堆的Kong official dashboard，筆者最近在寫文章也才赫然發現，原來有這麼多的官方釋出的儀表板喔？那到底要用哪一個？

看心情，喜歡就好。

上面那句話其實有一點任性，但是其實的確是如此，筆者查過了Kong官方回覆有說過，針對不同情境可能會有不同的儀表板(參考Kong 官方回覆)，因此這次筆者特別找到在prometheus plugin頁面中的建議，採用了編號7424的儀錶板來做為示範。

請讀者在啟動Grafana，登入後點選由上角的Import Dashboard(參考圖16-1)。

圖16-1 Import dashboard

接下來參考圖16-2，將7424的編號填入Find and import dashboards for common application at gragana.com/dashoards的下方輸入欄位，並點選Load。

圖16-2 Import dashboard

接著，請在畫面中選擇Prometheus的資料來源後，按下Import。

圖16-3 匯入儀錶板

剛匯入的時候，可以注意到圖16-4，雖說有帥氣的儀表板，但是目前因為剛開啟服務而已，尚未有任何流量發生，因此並沒有資料出現。不過讀者也不須著急，可以在Grafana 官方 Dashboard 市集再找找有關於API Provider的相關儀表板。待整個監控儀表板都建立後，再來進行實驗確認，這些儀表板是否適用。

圖16-4 沒有資料的儀表板

API Provider (dotnet core)

過去如果要在Grafana 官方 Dashboard 市集找適合的儀表板，就是透過search的方式去挑選。不過筆者這次試圖去搜尋時，發現了Grafana提供了全新的AI 功能。因此筆者也就試著去與AI 對話，來找看看有沒有推薦的儀表板可以使用。

圖16-5 很AI的搜尋

最後筆者在看了AI幾個推薦之後，選擇了第二個 ASP.NET OTEL Metrics(19896)，因為這次的鐵人賽示範專案，就是使用OTEL Collector作為metric的collector。

圖16-6 ASP.NET OTEL Metrics

好，儀表板也很帥，同樣的也可以看到指標都有在動了。

設定Grafana 告警

Contact points 的設定

由於monitor除了儀錶板外，還與告警有很重要的關係，因此這次的範例程式中，在docker-compose.yaml的檔案中，有以下設定區塊。Grafana支援非常多種其他的告警方式，例如teams、line notify(但這筆者記得line已經不提供服務了)以及Google chat。這個設定的區塊是透過gmail的方式發出告警，這是最簡單的一種設定方式。

    environment:
      - GF_SMTP_ENABLED=true
      - GF_SMTP_HOST=smtp.gmail.com:587
      - GF_SMTP_USER=xxxx@gmail.com
      - GF_SMTP_PASSWORD=你的應用程式密碼
      - GF_SMTP_FROM_ADDRESS=xxxx@gmail.com
      - GF_SMTP_FROM_NAME=Grafana
      - GF_SMTP_SKIP_VERIFY=true

上面的設定檔中有一段是GF_SMTP_PASSWORD，這不是指Gmail的密碼，而是在Google 帳戶登入後，上方搜尋欄可以找到應用程式密碼的選項。這是用來建立與這個帳號註冊的APP 密碼，類似於微軟EntraID中的應用程式註冊，透過這種方式就可以追蹤在這帳戶下，各式各樣被註冊的應用程式密碼以及活動狀態。這是相較於直接將使用者帳號密碼註冊出去，還要來的安全許多的方式。

圖16-7 Google 帳戶-應用程式密碼

讀者可以先到Google 帳戶-找到應用程式密碼，貼入本次示範的docker-compose.yaml區塊中，接著在把整個服務重啟，再來就能試試看告警服務的測試是否有效了。

圖16-8 告警發送成功

Alert rules的設定

告警的設定筆者想了很久，發現其實非常不容易在一篇文章中講清楚，因此這邊就用口述，以及提供該Alert rules的匯出檔，如果讀者有興趣玩看看，可以參考筆者匯出的設定檔到自製的Grafana中進行實驗。

檔案皆在示範目錄下：ironman2025\case_ELK_Jaeger_Promethus_Grafana

modify-export-4xx.yaml
- 設定在kong offical的儀錶板上，
  會計算過去 15秒內，所有服務（service）發生 401 錯誤的總數。
- 當 401 次數大於 2（gt: 2）時觸發警示。
modify-export-CPU 70%.yaml
- 設定在API Provider儀錶板，透過查詢會計算指定服務（exported_job 與 exported_instance）在 user 狀態下的 CPU 使用率變化速率。
- 當 CPU 使用率大於 2.8 時觸發警示（這裡的 2.8 代表的是 CPU 使用的核心數，筆者的筆電是4 核心，2.8 約等於 70%）。