如鯨向海，似鳥投林
什麼是Prometheus?
Prometheus 是由前 Google 工程師從 2012 年開始在 Soundcloud 以開源軟件的形式進行研發的系統監控和告警工具包，自此以後，許多公司和組織都採用了 Prometheus 作爲監控告警工具。Prometheus 的開發者和用戶社區非常活躍，它現在是一個獨立的開源項目，可以獨立於任何公司進行維護。爲了證明這一點，Prometheus 於 2016 年 5 月加入 CNCF 基金會，成爲繼 Kubernetes 之後的第二個 CNCF 託管項目。2017年底發佈了基於全新存儲層的2.0版本，能更好地與容器平臺、雲平臺配合。
與常見監控系統比較
對於常用的監控系統，如Nagios、Zabbix的用戶而言，往往並不能很好的解決上述問題。這裏以Nagios爲例，如下圖所示是Nagios監控系統的基本架構：
Nagios監控系統
Nagios的主要功能是監控服務和主機。Nagios軟件需要安裝在一臺獨立的服務器上運行，該服務器稱爲監控中心。每一臺被監控的硬件主機或者服務都需要運行一個與監控中心服務器進行通信的Nagios軟件後臺程序，可以理解爲Agent或者插件。
Nagios主機監控頁面
首先對於Nagios而言，大部分的監控能力都是圍繞系統的一些邊緣性的問題，主要針對系統服務和資源的狀態以及應用程序的可用性。 例如：Nagios通過check_disk插件可以用於檢查磁盤空間，check_load用於檢查CPU負載等。這些插件會返回4種Nagios可識別的狀態，0(OK)表示正常，1(WARNING)表示警告，2(CRITTCAL)表示錯誤，3(UNKNOWN)表示未知錯誤，並通過Web UI顯示出來。對於Nagios這類系統而言，其核心是採用了測試和告警(check&alert)的監控系統模型。 對於基於這類模型的監控系統而言往往存在以下問題：
- 與業務脫離的監控：監控系統獲取到的監控指標與業務本身也是一種分離的關係。好比客戶可能關注的是服務的可用性、服務的SLA等級，而監控系統卻只能根據系統負載去產生告警；
- 運維管理難度大：Nagios這一類監控系統本身運維管理難度就比較大，需要有專業的人員進行安裝，配置和管理，而且過程並不簡單；
- 可擴展性低： 監控系統自身難以擴展，以適應監控規模的變化；
- 問題定位難度大：當問題產生之後（比如主機負載異常增加）對於用戶而言，他們看到的依然是一個黑盒，他們無法瞭解主機上服務真正的運行情況，因此當故障發生後，這些告警信息並不能有效的支持用戶對於故障根源問題的分析和定位。
Prometheus的優勢
Prometheus是一個開源的完整監控解決方案，其對傳統監控系統的測試和告警模型進行了徹底的顛覆，形成了基於中央化的規則計算、統一分析和告警的新模型。
1. 易於管理
Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數據庫，緩存等等)。唯一需要的就是本地磁盤，因此不會有潛在級聯故障的風險。
**Prometheus基於Pull模型的架構方式，**可以在任何地方（本地電腦，開發環境，測試環境）搭建我們的監控系統。對於一些複雜的情況，還可以使用Prometheus服務發現(Service Discovery)的能力動態管理監控目標。
2. 由度量標準名稱和鍵/值對標識的時間序列數據組成的多維數據模型。
所有采集的監控數據均以指標(metric)的形式保存在內置的時間序列數據庫當中(TSDB)。所有的樣本除了基本的指標名稱以外，還包含一組用於描述該樣本特徵的標籤。
http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
每一條時間序列由指標名稱(Metrics Name)以及一組標籤(Labels)唯一標識。每條時間序列按照時間的先後順序存儲一系列的樣本值。
表示維度的標籤可能來源於你的監控對象的狀態，比如code=404或者content_path=/api/path。也可能來源於的你的環境定義，比如environment=produment。基於這些Labels我們可以方便地對監控數據進行聚合，過濾，裁剪。
3. 強大的查詢語言PromQL。
Prometheus內置了一個強大的數據查詢語言PromQL。 通過PromQL可以實現對監控數據的查詢、聚合。同時PromQL也被應用於數據可視化(如Grafana)以及告警當中。
通過PromQL可以輕鬆回答類似於以下問題：
在過去一段時間中95%應用延遲時間的分佈範圍？
預測在4小時後，磁盤空間佔用大致會是什麼情況？
CPU佔用率前5位的服務有哪些？(過濾)
4. 不依賴分佈式存儲，單節點具有自治能力。
Prometheus對於聯邦集羣的支持，可以讓多個Prometheus實例產生一個邏輯集羣，當單實例Prometheus Server處理的任務量過大時，通過使用功能分區(sharding)+聯邦集羣(federation)可以對其進行擴展。
5. 時間序列數據是服務端通過HTTP協議主動拉取獲得的。
6. 或者通過中間網關來推送時間序列數據。
7. 可以通過靜態配置文件或者服務發現獲取監控目標。
使用Prometheus可以快速搭建監控服務，並且可以非常方便地在應用程序中進行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等語言的客戶端SDK，基於這些SDK可以快速讓應用程序納入到Prometheus的監控當中，或者開發自己的監控數據收集程序。同時這些客戶端收集的監控數據，不僅僅支持Prometheus，還能支持Graphite這些其他的監控工具。
同時Prometheus還支持與其他的監控系統進行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。
Prometheus社區還提供了大量第三方實現的監控數據採集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。
8. 支持多種類型的圖標和儀表盤。
Prometheus Server中自帶了一個Prometheus UI，通過這個UI可以方便地直接對數據進行查詢，並且支持直接以圖形化的形式展示數據。同時Prometheus還提供了一個獨立的基於Ruby On Rails的Dashboard解決方案Promdash。最新的Grafana可視化工具也已經提供了完整的Prometheus支持，基於Grafana可以創建更加精美的監控圖標。基於Prometheus提供的API還可以實現自己的監控可視化UI。
Prometheus的組件
Prometheus 生態系統由多個組件組成，其中有許多組件是可選的：
Prometheus Server 作爲服務端，用來存儲時間序列數據。
客戶端庫用來檢測應用程序代碼。
用於支持臨時任務的推送網關。
Exporter 用來監控 HAProxy，StatsD，Graphite 等特殊的監控目標，並向 Prometheus 提供標準格式的監控樣本數據。
alartmanager 用來處理告警。
其他各種周邊工具。
大多數組件都是用Go編寫的，因此很容易構建和部署微靜態二進制文件
Prometheus 的架構
Prometheus 的整體架構以及生態系統組件如下圖所示：
Prometheus Server 直接從監控目標中或者間接通過推送網關來拉取監控指標，它在本地存儲所有抓取到的樣本數據，並對此數據執行一系列規則，以彙總和記錄現有數據的新時間序列或生成告警，可以通過Grafana或者其他工具來實現監控數據的可視化。
Exporter 將監控數據採集的端口通過HTTP服務的形式暴露給Prometheus Server，Prometheus Server通過訪問改Exporter提供的Endpoint端點，就能獲取到需要採集的監控數據。
Prometheus targets：探針（exporter）提供採集接口，或應用本身提供的支持Prometheus數據模型的採集接口。
AlertManager 在Prometheus Server中支持基於PromQL創建報警規則，若滿足PromQL定義的規則，則會產生一條報警，而報警後續的處理流程是由AlertManager進行管理。在AlertManager中我們可以與郵件，Slack等內置的報警方式進行集成，也可以通過Webhook自定義報警處理方式。AlertManager即Prometheus體系中的報警處理中心。
PushGateway 由於Prometheus數據採集基於Pull模型進行設計，因此在網絡環境的配置上必須要讓Prometheus Server能夠直接與Exporter進行通信。 當這種網絡需求無法直接滿足時，就可以利用PushGateway來進行中轉。可以通過PushGateway將內部網絡的監控數據主動Push到Gateway當中。而Prometheus Server則可以採用同樣Pull的方式從PushGateway中獲取到監控數據。
Web UI Prometheus內置的Web控制檯，可以查詢指標，查看配置信息或者Service Discovery等，在實踐中一般使用Grafana，Prometheus作爲Grafana的數據源
TSDB(Time Series Database) 時間序列數據庫 簡單的理解爲一個優化後用來處理時間數據的軟件即可，並且數據中的數組是由時間進行索引的。
Service discovery 支持根據配置file_sd監控本地配置文件的方式實現服務發現（需配合其他工具修改本地配置文件），同時支持配置監聽Kubernetes的API來動態發現服務。
Prometheus 適用於什麼場景
Prometheus 適用於記錄文本格式的時間序列，它既適用於以機器爲中心的監控，也適用於高度動態的面向服務架構的監控。在微服務的世界中，它對多維數據收集和查詢的支持有特殊優勢。Prometheus 是專爲提高系統可靠性而設計的，它可以在斷電期間快速診斷問題，每個 Prometheus Server 都是相互獨立的，不依賴於網絡存儲或其他遠程服務。當基礎架構出現故障時，你可以通過 Prometheus 快速定位故障點，而且不會消耗大量的基礎架構資源。
Prometheus 不適合什麼場景
Prometheus 非常重視可靠性，即使在出現故障的情況下，你也可以隨時查看有關係統的可用統計信息。如果你需要百分之百的準確度，例如按請求數量計費，那麼 Prometheus 不太適合你，因爲它收集的數據可能不夠詳細完整。這種情況下，你最好使用其他系統來收集和分析數據以進行計費，並使用 Prometheus 來監控系統的其餘部分。
官方文檔地址：https://prometheus.io/docs/introduction/overview/
幫助文檔：https://yunlzheng.gitbook.io/prometheus-book/