監控節點的度量指標:Grafana 串接 Prometheus

監控節點的度量指標:Grafana 串接 Prometheus

前面的討論中,我們可以用 Prometheus 去監控 End Devices,但 Prometheus 內建的 Dashboard 只是為了開發用,缺乏許多進階功能,在真正需要資料視覺化時並不方便。因此 Prometheus 通常會跟 Grafana 搭配使用。

Grafana 是一套開源的 Dashboard 平台,之前開發產品時,有用過 Grafana 來呈現 Database 中的資料。其實用起來還是偏 Monitor Host,並不適合用在 Domain Data Visualization,但在開發初期,我們可以先借用 Grafana 的呈現能力來確認方向(反正開發初期規格會一直修改,重要的是工具能否快速調整,實不實用倒是其次)。

Install Grafana

跟 Prometheus 一樣,用 docker 來安裝

docker run -p 3000:3000 --user root --name grafana -v "$PWD"/docker/grafana:/var/lib/grafana grafana/grafana &

用 -p 將 port forward 到 3000;用 -v 將 grafana 內的資料 bind 到家目錄的資料夾。

安裝完成後,在瀏覽器輸入 URL,應該能看到登入畫面

Setup Data Source

輸入預設的帳號密碼 admin:admin 後登入

需要在 Grafana 中加入 Data source,Grafana 才知道要去哪裡抓資料,點選 Add data source 的圖示

第一個就是 Prometheus,不用猶豫,點下去

在 URL 中輸入 Promethues 的 URL,port 沒改的話就是 9090。儲存並測試。

Create Dashboard

有了資料來源後,要緊接著加入 Dashboard,Grafana 有提供 Prometheus 的範例 Dashboard,我們來看看

點選上方的 Dashboards 分頁,加入預設的 Dashboard

華麗的 Dashboard 就跑出來了!是不是很簡單!雖然這張表的數據不是我們要的,但光看就是很威啊。

Add Panel

有了範例後,參照 Grafana 的說明慢慢手動調整各個 Panel,就能調出想要的效果啦。假設今天想 Monitor end devices 的 CPU usage,我們可以加入一個新的 Panel

用 Add Query 加入查詢式

查詢式用的是 Prometheus 的查詢語言 PromQL,照樣輸入

100 - (avg by (instance) (irate(node_cpu_seconds_total{job="node",mode="idle"}[5m])) * 100)

查詢結果就自動變成圖表了。

小結

以 Dashboard 來講,Grafana 真的很強大,呈現的樣式多,查詢語言容易上手,但是 Grafana 不適合用來進行資料處理,如果需要呈現處理後的資料,而查詢語言本身又沒有相關的聚合指令的話,記得先處理完後再丟進 Database,或者在 Database 跟 Grafana 中間加入一個中間層,不要用 Grafana 硬幹。

Reference

Read more

標準化之路:Go 1.23 中的迭代器

標準化之路:Go 1.23 中的迭代器

Ian Lance Taylor 在 "Range Over Function Types" 這篇文章聊到 iterator 誕生的原因。如果我們有兩個容器,稱為集合(Set),想要取得這兩個集合中的不重複元素,加到新的集合中形成聯集,我們可以寫個 Union 函式來執行 // Set holds a set of elements. type Set[E comparable] struct { m map[E]struct{} } // Union returns the union of two sets. func Union[E comparable](s1, s2 *Set[

By Ken Chen
OAuth 2.0 的身份認證:OpenID Connect

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2 讓網路服務可以存取第三方的受保護資源,因此,有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差,因為 OAuth 2 當初設計目的是「授權」而不是「認證」,兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定,讓開發者可以在 OAuth 2 授權的基礎上,再加入標準的認證流程。在這篇文章中,我會說明授權跟認證的場景有何差異,並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上,我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程,如果你不熟悉,可以先閱讀另外兩篇文章 * OAuth 2.0:

By Ken Chen
更好的選擇?用 JWT 取代 Session 的風險

更好的選擇?用 JWT 取代 Session 的風險

因為 HTTP 是無狀態協定,為了保持使用者狀態,需要後端實作 Session 管理機制。在早期方式中,使用者狀態會跟 HTTP 的 Cookie 綁定,等到有需要的時候,例如驗證身份,就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後,使用者資訊可以編碼在 JWT 內,也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論,發現 JWT 用來管理身份認證會有些風險。在這篇文章中,我會比較原本的 Session 管理跟 JWT 的差異,並說明可能的風險所在。 Session 管理 Session 是什麼意思?為什麼需要管理?我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態,翻譯成白話,就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢,

By Ken Chen

Goroutine 的併發治理:掌握生命週期

從併發的角度來看,Goroutine 跟 Thread 的概念很類似,都是將任務交給一個執行單元來處理。然而不同的是,Goroutine 將調度放在用戶態,因此更加輕量,也能避免多餘的 Context Switch。我們可以說,Go 的併發處理是由語言原生支援,有著更好的開發者體驗,但也因此更容易忘記底層仍存在著輕量成本,當這些成本積沙成塔,就會造成 Out of Memory。這篇文章會從 Goroutine 的生命週期切入,試著說明在併發的情境中,應該如何保持 Goroutine 的正常運作。 因為這篇講的內容會比較底層,如果對應用情境不熟的人,建議先看過同系列 * Goroutine 的併發治理:由錯誤處理談起 * Goroutine 的併發治理:值是怎麼傳遞? * Goroutine 的併發治理:管理 Worker Pool 再回來看這篇,應該會更容易理解。 Goroutine 的資源使用量 讓我們看個最簡單的例子,假設現在同時開

By Ken Chen