前言
隨着容器技術這幾年的迅速發展，Kubernetes已經逐漸成爲雲生態圈CNCF（Cloud Native Computing Foundation）當之無愧的老大。而Prometheus穩坐CNCF基金會的“第二把交椅”，已然成爲Kubernetes羣集監控系統的必要組成部分。
現在有越來越多的企業，有意向或正在由傳統技術基礎架構向雲環境遷移。在開源監控系統方面，企業有Zabbix、Prometheus等系統可以選擇。不可否認，Zabbix的產品成熟度很高，同時也與時俱進，且仍然佔據整個市場的很大比例，但它隨着雲生態的發展暴露出一些問題。
與之相對的，Prometheus不僅更加適配雲生態，而且具有了很多無可比擬的特性，如具備多維的數據模型，支持靈活的查詢及聚合語句，不依賴分佈式存儲運行，各節點自治等。在使用場景上，它既適用於以服務器爲中心的監控，也適用於高動態的面向服務架構的監控。在部署方式上， Prometheus不僅支持雲環境部署，同時也支持非雲環境部署。現在它已經成爲企業部署開源監控系統中的重要選擇。
技術中臺採用Prometheus作爲其監控系統，對其下管控的各節點機及服務進行監控。那麼，Prometheus到底有哪些優勢呢？又是如何與技術中臺結合的呢？
本文將帶着這些問題，帶您深入剖析Prometheus監控系統，並帶您領略其在技術中臺發出的光彩。
- 應用監控的三板斧？
我們先考慮一個問題：爲什麼企業需要一套應用監控系統？
可以想象，如果一個互聯網企業，不知道網站運行時的服務器的CPU、內存、存儲空間等實時指標，也不知道涉及業務訪問的應用相應時間（RT）、吞吐量（TPS）、併發用戶數或每秒查詢率（QPS）指標，還不知道中間件、應用服務調用狀態，甚至不知道用戶訪問時應用的健康狀態是否正常，那無異於在刀尖上跳舞。
所以我們可以說，一套好的監控系統可以幫助企業在出現系統故障時及時通知和快速定位問題，是保障互聯網企業應用健康穩定運行的系統中不可或缺的重要組成。
在一套完整的監控系統中，需要考慮監控手段、監控指標、獲取監控數據的方法等與監控相關的具體實現方式。每一項技術實現方式均有其獨特的功能特點。
監控手段的選擇：黑盒監控vs白盒監控
從監控手段上說，監控分爲黑盒監控和白盒監控兩種模式。
所謂黑盒監控，即注重業務表現，從外部探測應用系統發現哪些功能故障，通過模擬訪問請求的方式快速發現故障。
所謂白盒監控，即注重問題產生的原因，從內部系統檢測運行指標，比如用“埋點”等方式將應用訪問時的錯誤率等信息暴露出來，以便在出現故障和即將出現故障時，可以快速定位故障原因。
監控指標的選擇：USE原則vs RED原則
監控系統中可監控的指標衆多，指導監控系統選擇指標的原則主要有兩個，分別是USE原則和RED原則。
USE原則側重以下監控指標：
利用率（Utilization）：資源被有效利用起來提供服務的平均時間佔比；
飽和度（Saturation）：資源擁擠的程度，比如工作隊列的長度；
錯誤率（Errors）：錯誤的數量，單位時間內訪問錯誤數的比率。
而RED原則，側重以下監控指標：
每秒請求數量（Rate）：服務每秒請求數量；
每秒錯誤數量（Errors）：應用服務每秒錯誤數量；
服務響應時間（Duration）：服務完成相應請求的時間數。
獲取監控的選擇：pull vs push
獲取監控數據的方法很重要，這直接決定了監控系統架構的特點。在實際中，監控系統需要在功能實現、數據獲取速度、穩定性、安全性等層面做架構設計，並在各關鍵功能點上做出最大平衡。
一般來說，監控數據可以分爲Pull方法和Push方法。
Pull方法：服務端主動拉取監控指標數據。優勢能夠完成水平監控，對於被監控端無感知，架構複雜性相對小，降低耦合。缺點是直接暴露監控數據存在一定的安全風險。
Push方法：被監控端主動上傳監控指標數據。優勢不需要服務端發起，可以實時接受監控數據，缺點是如果上傳監控數據併發過大，會造成服務端阻塞。
- Prometheus技術架構特點
Prometheus的技術架構
在架構上，Prometheus監控系統由以下組件組成。
Prometheus Server： 服務端，用於收集監控數據，包含時間序列數據庫TSDB；
Push Gateway： 客戶端使用push的方式上報監控數據到Push Gateway，Prometheus會定期從Push Gateway拉取數據；
Exporters： 用於暴露監控信息metrics 給 Prometheus Server；
Alertmanager： 從 Prometheus server 端接收到 alerts 後，會進行去除重複數據和分組，並路由到對收的接受方式，發出報警。常見的接收方式有：電子郵件、企業微信、webhook 等；
Grafana：設置數據源爲prmetheus將監控數據做前端展示。
Prometheus的功能特點
在功能上，與其他監控系統相比，Prometheus有如下重要的不同之處：
1）Prometheus的數據庫使用的是時序型數據庫TSDB，而一些其他監控系統使用的是關係型數據庫MySQL.如果監控集羣規模很大，傳統關係型數據庫可能存在性能瓶頸，同時擴展難度也隨之增加；
2）在監控指標聚合上，Prometheus使用的是時序類數據庫的查詢語言PromQL，可以非常靈活的完成監控數據聚合等操作；
3）Prometheus整個生態非常熱火，官網上提供多種類型的exporter，用於負責監控指標採集工作，同時也可以根據不同的業務場景自行編寫exporter，監控指標採集的靈活度非常高；
4）Prometheus與Kubernetes結合度很高。通過標準的kubernetes API可以將Pod中的metric監控數據暴露出來。這樣，Prometheus就可以通過訪問對應Kubernetes API接口，收集羣集中Pod、Node、Service等監控信息。
將Prometheus與kubernetes結合
在Kubernetes集羣中，Prometheus獲取Metrics數據的方式大概有兩類：
1） 檢測獲取node節點的監控信息
一般會在node節點上安裝node_exporter，該Pod的種類會是以DaemonSet的方式運行，保證每臺Node節點有對應的node_exporter運行，Prometheus會收集每一臺Node上的CPU、內存、磁盤、網絡帶寬等監控信息。
2） 檢測kubernetes集羣中運行的Pod、Service等種類的監控信息
這類metrics信息主要來自於cAdvisor所提供，可以監控到Pod的CPU負載、所使用內存和網絡開銷等信息。
其中監控數據可以結合Metrics Server通過kubernetes API將監控數據暴露出來。這樣，用戶就可以通過標準的API接口訪問Pod、Service等監控信息。
- Prometheus在開發者中心的落地與實踐
在開發者中心部署Prometheus
在開發者中心將主機接入資源池的時候，部署腳本會自動安裝Prometheus、node_exporter、cAdvisor等組件。因此，直接按提示執行開發者中心提供的腳本，就可以監控每一臺Node節點的主機資源情況和每個應用Pod上的資源使用情況。
查看主機監控
在開發者中心將節點機接入資源池後，就可以依次點擊菜單“容器服務”、“資源池”、“查看監控”、“資源池監控”，在頁面中就可以查看接入主機的CPU使用率、TCP連接數、磁盤IO使用情況、根分區容量、網絡負載等信息。
查看應用監控
在開發者中心部署好業務應用後，依次點擊“容器服務”、“資源池”、“查看監控”、“應用監控”，在頁面中即可查看接入應用程序的CPU負載、內存負載、網絡負載等信息。
實現應用自動水平擴展功能
點擊 “應用管理”菜單，進入部署應用的詳情頁面後，可以在“自動擴縮”中配置應用的最大、最小實例數。開發者中心會根據設置的CPU、內存百分比，獲取MetricsServer中的監控信息，實現Kubernetes的HPA自動水平擴展功能，在業務訪問量突增時，自動完成應用集羣的擴展操作。
- 總結與展望
Prometheus在雲環境中地位越來越重要，其系統監控功能強大而完善。與Kubernetes的搭配也對企業實現對業務的監控等功能有重要意義。現在的用友開發者中心已經在採用Kubernetes容器調度系統的基礎上，將Promethesus與自身完美融合，實現了對節點機、業務應用Pod等各項Metric指標的採集和監控，並用於報警和自動擴容縮容等場景。
但是我們知道，“行百里者半九十”，我們要走的路仍然很遠。比如對自定義Metric指標的檢測，並根據企業中應用場景來完成自動容縮；比如收集當網站的RPS（Requests Per Second）指標，當RPS到達極限值時對業務Pod的自動擴容等。
在用友雲提出的“大技術中臺”戰略中，業務數據的監控與收集是其中重要環節之一。讓我們爲技術中臺目標繼續努力前進。
套用一句廣告語做總結：“我聽說，Prometheus與技術中臺更配哦！”