鬥魚 Juno 監控中心的設計與實現

Juno 監控中心的設計與實現

作者：杜旻翔 @ 鬥魚

前言

伴隨微服務的推廣，程式粒度的日趨小型化，服務數量逐漸增長，需要更多的關注服務本身的監控，服務上下游服務情況，以及相關資料來源中介軟體的狀態。我們需要更加多維度服務監控，能夠對服務呼叫鏈路進行視覺化、對目標服務呼叫時客戶端與服務端的實時監控。在 Juno 監控中心，我們嘗試解決這些問題。

為什麼需要監控中心

   
在行業內越來越多的公司需要開發人員懂得伺服器基礎架構、作業系統、網路、語言特性、業務整體架構、面對線上問題快速分析快速定位、還包括服務效能調優，對這些方面的要求就是 Google 倡導的 SRE（站點可靠性工程師）。這項工作依賴於很多工具才能順利完成，例如日誌系統、釋出系統、監控系統等等。
在鬥魚微服務管理系統 Juno，其中的監控中心的設計就是為協助開發人員進行高效的服務穩定性維護工作，完成對微服務系統的健康支援：

• 水位瓶頸，在鬥魚進行全鏈路壓測，通過監控系統可以找到服務鏈路中的瓶頸，瞭解核心專案的具體水位；
• 故障預防，採用環比和同步資料進行服務健康波動分析，進行一定程度上的異常預防；
• 故障排查，線上故障快速定位，給出服務呼叫鏈路，從監控異常資料開始分析，排查影響範圍，定位問題觸發點。

 

主流產品差異性

只針對市場上的免費解決方案進行分析，目前分析的 Zabbix、Nagios 都比較偏向於基礎運維監控工具。Juno 監控中心是 Grafana 和 Prometheus 的最佳實踐之一，更偏向於業務監控。

	優點	缺點
Zabbix	- 資料採集方式多樣 - 可用性高 - 歷史資料可查詢 - 安全審計	- 效能瓶頸 - 二次開發難度 - housekeeping 的資料庫壓力
Nagios	- 配置靈活 - 多樣性的報警條件設定	- 無歷史資料儲存 - 配置複雜 - 控制檯功能較弱

Juno 監控中心簡介

Juno 監控中心理念

Juno 監控中心有三個核心理念：容量水位；監控預警；快速定位。

容量水位

容量水位：服務可以承受多少的 QPS。通過全鏈路壓測的方式獲取對外提供 API 在微服務體系中的整體鏈路，首先探測服務本身可承載的容量是多少，針對危險水位進行資料採集，並以此作為流量變化後的擴容依據。

監控預警

監控預警：多個維度進行監控預警。

• 服務響應時間、QPS、成功率這三個基礎維度進行告警配置；
• 對各指標根據歷史資料進行環比計算預警；
• 進一步根據服務各自的水位進行兜底告警。

快速定位

快速定位：在故障發生是，通過響應速度來判斷在哪個服務出現了問題，通過 TOP 指標和上下游鏈路解析快速定位異常點，再進一步結合異常服務上下文監控資料和日誌資料進行錯誤分析。在異常恢復後也可以通過監控進行判斷服務狀態。

Juno 監控中心特點

部署簡單	依賴 ETCD 和 prometheus 進行部署，資料採集和服務治理採用基本一致的元件
外掛支援	結合 Juno Agent 進行資料採集外掛化配置
管理後臺	在 web 介面進行配置定製化載入，定製化的互動
配置監控	客戶端配置資訊監控；管理後臺直接展示配置在哪些例項上被哪些服務使用
自動發現	基於 Juno Agent 的心跳上報進行監控資料節點發現
告警配置	服務告警條件配置豐富

Juno 監控中心設計

總體設計

層次設計

下圖描述 Juno 監控中心的總體設計，從下往上分析：

• 採用 Jupiter 框架構建的客戶端，服務啟動之後會在 ETCD 中寫入監控的 KEY；
• Juno Agent 服務監聽到監控的 KEY，生成 Prometheus 的 Target 配置；
• Prometheus 根據 Target 配置讀取 Jupiter Client 的監控資料；
• 在 Juno Admin 內嵌 Grafana 讀取 Prometheus 進行監控資料展示。
  

客戶端設計

下圖簡要描述 Jupiter 客戶端（Jupiter Client）的部分：

1. 使用者構建 Jupiter Client，在 ETCD 中寫入監控的 key-value；
2. 同時 Jupiter Client 提供一個自建的 Prometheus Pushgateway（http://xxx.xxx.xxx.xxx:9999/metrics）；
3. Prometheus 由 Juno Agent 生成 Target 配置後周期性的 pull 監控資料；

服務端設計

核心流程就是 Grafana 增加 Prometheus 資料來源，Prometheus 通過 Juno Agent 生成的配置進行監控資料拉取。這裡 Juno Agent 僅僅只用於 Prometheus 配置的生成，不上報任何的監控資料。
Juno Agent 生成的 Target 配置如下：

- targets:
    - "127.0.0.1:9999"
  labels:
    instance: monitor-demo
    job: jupiter

如果需要增加其他的監控資料，可以不使用 Juno Agent，直接在 Prometheus 中增加期望的 Pushgateway，並且在 Juno Admin 中的 Grafana 配置管理中直接增加模板地址即可進行嵌入展示。以下按照我們使用的監控資料上報格式舉例，Jupiter Client 會將服務啟動時相關的：應用版本、機器 IP、機器名稱、應用資訊寫入 buid_info 中，這些基礎資料會作為其他監控直接的基礎 label，進行後續的監控條件篩選。

kubernetes 叢集部署方案

虛擬容器化是大勢所趨，Juno 監控中心對 k8s 叢集的支援方案基本與物理機部署方案一致，容器會產生 Pushgateway 地址漂移，從管理後臺通過 UI 介面查詢需要根據歷史 POD 資料進行歷史監控資料查詢。

多機房部署方案設計

Juno 監控中心支援多機房（IDC），在實際業務場景中會同時使用多地區的機房，機房之間不進行跨機房通訊，
每個機房都搭建獨立的 ETCD 和 Prometheus，監控資料在各機房進行獨立儲存，管理後臺（Juno Admin）通過內嵌 Grafana 訪問各機房 Prometheus。所有的資料流轉由某一個部署監控中心管理後臺的機房完成，該機房依靠專線與其他機房進行通訊，在遭遇專線網路故障時，可直接切換到外網 IP 保證服務穩定，對不同機房間的操作互相隔離，不產生依賴影響。
!

技術點詳解

監控資料採集實現

1. 部署基礎服務包括 ETCD 和 Prometheus；
2. 採用 Jupiter 框架構建服務，成功啟動服務後會完成兩個操作：
   1. 寫入監控 key-value；
   2. 通過服務治理埠提供 Pushgateway；
3. 在 Prometheus 部署的機器上，進行 Juno Agent 服務部署完成兩個功能：
   1. 進行 ETCD 的監控 key-value 監聽；
   2. 通過監聽的資料產生 Prometheus 需要的 Target 配置；
4. 在 Prometheus 配置生成完畢後，直接拉取 Jupiter Client 的 Pushgateway 資料，完成監控資料的採集。

 

監控採集時序圖

配置的整個生命週期流轉如下圖所示，歸納為四個配置點進行表述：管理後臺（前端互動 UI）、配置服務（管理後臺服務）、下發服務（Minerva Proxy+Minerva Agent）、應用。

閘道器功能

採用 Grafana 子域名配置，直接使用 Juno Admin 的域名例如（http://jupiterconsole.douyu.com/），配置為（http://jupiterconsole.douyu.com/grafana）直接進行訪問，採用 juno 系統的登入態以及使用者資訊，統一了使用者許可權管理。
!
目前閘道器功能在後期可擴充套件成對任意無狀態的三方系統的鑑權支援，只需要在 Juno Admin 閘道器設定中進行域名以及目標地址的配置即可。

可用性分析

分析多故障場景，當前 Juno 監控中心的降級方案如下：

場景	影響	降級方案
Juno Agent 掛掉	新增服務無法生成對應的 Prometheus Target 配置，拉取不到監控資料。不影響已有服務的監控採集與查詢。
某個 ETCD 節點掛掉	無影響。	Juno Agent 可以重連其他 ETCD 節點
全部 ETCD 節點掛掉	Jupiter Client 啟動後無法成功寫入監控 Key，同樣無法生成 Target 配置。不影響已有服務的監控採集與查詢。
Prometheus 掛掉	無法採集監控資料。
Grafana 掛掉	無法查詢監控資料。
專線故障	監控資料拉取失敗。	使用公網 IP 繼續相關操作

為什麼選擇 ETCD

為什麼採用 ETCD 作為監控中心和配置儲存/訂閱通知引擎，而不是使用傳統的 ZK，Eureka？我們大致總結了一下，有以下幾方面的原因：

• 它提供了強大和靈活的 K-V 儲存能力，可以在保證效能的前提下對配置項進行最小粒度對儲存
• 它提供了對 key 或者 key 字首的監聽功能，正好滿足我們對某些配置項需要動態下發的需求
• 我們的專案本身就使用了 ETCD 做服務註冊與發現和儲存功能，維護和使用相對於 zk，Eureka 會熟練的多

為什麼採用 Prometheus

為什麼監控中心採用 Prometheus 進行監控指標儲存，有以下幾個原因：

• Prometheus 是 CNCF 旗下成熟的開源專案，社群活躍；
• 資料模型靈活，多樣性的 label，在資料採集階段支援資料屬性自定義；
• PromQL，強大的查詢能力，多功能封裝的查詢語句，能滿足絕大多數業務場景；
• 良好的效能，支援每秒十萬條以上的監控資料採集；

互動設計

介面概覽

下圖是 Juno 監控中心的首頁。

• 頁面上方：
  • 應用選擇以及環境切換，展示了應用相關的基礎資訊；
  • 機房切換；
  • 應用服務可用功能模組切換；
• 頁面中央，採用按鈕形式展示了可用 Dashboard；
• 頁面下方，嵌入 Grafana 監控頁面。

 

服務概覽

服務概覽有三個側重點：響應時間、QPS、成功率。這是對服務整體質量的評價。

健康檢查

目前服務在某一環境中部署的例項數量，是否存在異常情況，最大的檔案控制程式碼數、CPU 消耗、記憶體使用、QPS 指標，能幫助使用者在第一時間瞭解的當前服務的具體情況，進一步服務心跳更新時間，當前採用的框架版本相關的 git 提交版本，都進行表格化展示，可以為問題排查提供更多的客觀資料。

例項監控

從例項維度進行服務監控分析。

服務端監控

服務本身對外提供服務的情況，依據 HTTP 和 GRPC 進行區分，給出 QPS 和 P99 的資料。

介面監控

對服務提供的具體 API 進行監控指標採集和展示。

客戶端監控

查詢當前服務對下游服務的呼叫情況監控，可以快速定位是服務本身異常，還是下游服務異常。

容器監控

服務容器化部署之後，給出對 pod 情況的獨立監控，可結合服務本身監控進行交集查詢。

模板配置

提供模板配置的功能，使用者可以自行修改 Dashboard 地址，系統會依次展示這些 Dashboard。

總結

本文從 Juno 監控中心的層次結構開始分析，說明了服務監控採集流程包括客戶端、服務端的設計，講解了部分技術點包括採集時序圖、閘道器設計等；在架構分析的基礎上對各個功能點進行分析，希望幫助各位進一步理解我們的設計思維；最後展示監控相關的互動頁面，以及鬥魚 Juno 監控中心設計的監控系統設定介面。

相關資料

• jupiter 官網 http://jupiter.douyu.com
• jupiter 倉庫地址 https://github.com/douyu/jupiter
• juno 倉庫地址 https://github.com/douyu/juno
• demo 演示地址 http://jupiterconsole.douyu.com

 

加入鬥魚開源技術交流群