微服務監控告警：Prometheus

來源：
《微服務架構實戰160講》

微服務監控告警

prometheus是多維度（標籤）的，使用拉模式，黑盒白盒都支持，對DevOps友好，適用中小規模

支持的Metric種類：計數器、測量儀、直方圖、彙總圖

prometheus的Metrics案例：

influxDB不僅可以做監控，還可以對業務進行一些分析

1 四種主要監控方式

prometheus主要是Metrics方式（可以對離散數據進行聚合運算，還可以打標籤）和Healthchecks方式結合

• 適用場景
  
• Metrics監控架構
  
  Alerts可以對接郵件、微信等，可以做去重、分組、路由

2 時間序列

一系列時間點連起來就形成時間序列

如圖產生了一個時間序列矩陣，本質就是不同時間點產生不同的值，存儲在數據庫中，給出的紅框案例爲四個時間序列，request_total、errors_total是時間序列的名稱，path和method是標籤，不同標籤，時間序列也不同

3 架構設計

一般情況是拉取（Jobs/Exporters），對於短週期可以使用推（Short-lived jobs）到push網關再去拉，也可以pull其他PrometheusServer，這也就是集羣

拉取的話就需要知道要拉取的服務地址，即需要服務發現，所以有了ServiceDiscovery

Retrieval模塊定時拉取數據，並通過Storage模塊保存數據，而PromQL爲Prometheus提供查詢語法，PromQL模塊通過解析語法樹，調用Storage模塊查詢接口獲取監控數據。

右側是告警和頁面展現：
Prometheus將告警推送到alertmanger，然後通過alertmanger對告警進行處理並執行相應動作。
數據展現除了Prometheus自帶的WebUI，還可以通過Grafana等組件查詢Prometheus監控數據。

Exporters是用來間接採集的，如果不能直接採集就只能通過Exporters來間接採集，如Redis、Mysql等都可以做Exporters

• 存儲設計

以一個時間間隔作爲一個時間塊，一開始爲mutable，在內存中，如果滿了就變爲Immutable，每兩個小時產生一個mutable：

查詢時，根據時間定位到塊

每一個塊的數據：

4 實踐

• 四個黃金指標

延遲、流量/吞吐、錯誤、飽和度（衡量資源使用情況）

• Cardinality（基數）

爲Label的可能取值，新增一個 Label 值=新增一個時間序列

經驗值：單實例 Cardinality <= 10個

以下屬性不適合做 Label：
• Email Email 地址
• 用戶名
• IP 地址
• HTTP Path HTTP Path

一般關注 10 個最大的 metrics，而高Cardinality場景，如要監控ip等，用 Log系統

• 高可用

做HA，兩個Prometheus來實現，而數據可以交給遠程存儲，因爲本地的15天就會過期；如果規模太大，還可以加上聯邦集羣，不同團隊使用不同的Prometheus，由上層兩個Prometheus進行聚合：

5 ZMon：分佈式監控平臺

Prometheus是基於團隊的，每個團隊自己搭建一個，而Zmon是基於整體的

適合大規模，使用拉模式，基於KairosDB實現，其架構如下：

可以看作是一個任務隊列，使用消費者生產者模型，左側產生任務，交給Redis，由右邊的Worker處理完後，存儲到DB或Redis