第2章
Prometheus簡介
在本章中，我們将介紹Prometheus及其起源，并概述以下内容：
- Prometheus的發展
- Prometheus架構和設計
- Prometheus資料模型
- Prometheus生态系統
這會讓你了解Prometheus是什麼，并了解它在監控領域的适用場景。
本書重點介紹Prometheus 2.0及更高版本。本書的大部分内容并不适用于早期版本。
2.1 Prometheus起源
很久以前，加利福尼亞州山景城有一家名為Google的公司。該公司推出了大量産品，其中最著名的是廣告系統和搜尋引擎平台。為了運作這些不同的産品，該公司建立了一個名為Borg的平台。Borg系統是：“一個叢集管理器，可以運作來自成千上萬個不同應用程式的成千上萬個作業，它跨越多個叢集，每個叢集都有數萬台伺服器。”開源容器管理平台Kubernetes的很多部分都是對Borg平台的傳承。在Borg部署到Google後不久，該公司意識到這種複雜性需要一個同等水準的監控系統。Google建立了這個系統并命名為Borgmon。Borgmon是一個實時的時間序列監控系統，它使用時間序列資料來識别問題并發出警報。
Borg和Borgmon都沒有開源，直到最近才有機會了解它們的工作原理。你可以在Google SRE手冊的實用警報章節中閱讀更多相關内容。
Prometheus的靈感來自谷歌的Borgmon。它最初由前谷歌SRE Matt T. Proud開發，并轉為一個研究項目。在Proud加入SoundCloud之後，他與另一位工程師Julius Volz合作開發了Prometheus。後來其他開發人員陸續加入了這個項目，并在SoundCloud内部繼續開發，最終于2015年1月将其釋出。
與Borgmon一樣，Prometheus主要用于提供近實時的、基于動态雲環境和容器的微服務、服務和應用程式的内省監控。SoundCloud是這些架構模式的早期采用者，而Prometheus的建立也是為了滿足這些需求。如今，Prometheus被更多的公司廣泛使用，通常用來滿足類似的監控需求，但也用來監控傳統架構的資源。
Prometheus專注于現在正在發生的事情，而不是追蹤數周或數月前的資料。它基于這樣一個前提，即大多數監控查詢和警報都是從最近的（通常是一天内的）資料中生成的。Facebook在其内部時間序列資料庫Gorilla的論文中驗證了這一觀點。Facebook發現85％的查詢是針對26小時内的資料。Prometheus假定你嘗試修複的問題可能是最近出現的，是以最有價值的是最近時間的資料，這反映在強大的查詢語言和通常有限的監控資料保留期上。
Prometheus由開源程式設計語言Go編寫，并且是在Apache 2.0許可證下授權的。它孵化于雲原生計算基金會（Cloud Native Computing Foundation）。
2.2 Prometheus架構
Prometheus通過抓取或拉取應用程式中暴露的時間序列資料來工作。時間序列資料通常由應用程式本身通過用戶端庫或稱為exporter（導出器）的代理來作為HTTP端點暴露。目前已經存在很多exporter和用戶端庫，支援多種程式設計語言、架構和開源應用程式，如Apache Web伺服器和MySQL資料庫等。
Prometheus還有一個推送網關（push gateway），可用于接收少量資料—例如，來自無法拉取的目标資料（如臨時作業或者防火牆後面的目标）。
關于Prometheus的具體架構如圖2-1所示。
圖2-1 Prometheus架構
2.2.1 名額收集
Prometheus稱其可以抓取的名額來源為端點（endpoint）。端點通常對應單個程序、主機、服務或應用程式。為了抓取端點資料，Prometheus定義了名為目标（target）的配置。這是執行抓取所需的資訊—例如，如何進行連接配接，要應用哪些中繼資料，連接配接需要哪些身份驗證，或者定義抓取将如何執行的其他資訊。一組目标被稱為作業（job）。作業通常是具有相同角色的目标組—例如，負載均衡器後面的Apache伺服器叢集，它們實際上是一組相似的程序。
生成的時間序列資料将被收集并存儲在Prometheus伺服器本地，也可以設定從伺服器發送資料到外部存儲器或其他時間序列資料庫。
2.2.2 服務發現
可以通過多種方式來處理要監控的資源的發現，包括：
- 使用者提供的靜态資源清單。
- 基于檔案的發現。例如，使用配置管理工具生成在Prometheus中可以自動更新的資源清單。
- 自動發現。例如，查詢Consul等資料存儲，在Amazon或Google中運作執行個體，或使用DNS SRV記錄來生成資源清單。
我們将在第5章介紹如何使用各種服務發現方法。
2.2.3 聚合和警報
伺服器還可以查詢和聚合時間序列資料，并建立規則來記錄常用的查詢和聚合。這允許你從現有時間序列中建立新的時間序列，例如，計算變化率和比率，或者産生類似求和等聚合。這樣就不必重新建立常用的聚合，例如用于調試，并且預計算可能比每次需要時運作查詢性能更好。
Prometheus還可以定義警報規則。這些是為系統配置的在滿足條件時觸發警報的标準，例如，資源時間序列開始顯示異常的CPU使用率。Prometheus伺服器沒有内置警報工具，而是将警報從Prometheus伺服器推送到名為Alertmanager（警報管理器）的單獨伺服器。Alertmanager可以管理、整合和分發各種警報到不同目的地—例如，它可以在發出警報時發送電子郵件，并能夠防止重複發送。
我們将在第6章看到有關Alertmanager的更多資訊。
2.2.4 查詢資料
Prometheus伺服器還提供了一套内置查詢語言PromQL、一個表達式浏覽器（如圖2-2所示）以及一個用于浏覽伺服器上資料的圖形界面。
圖2-2 Prometheus表達式浏覽器
2.2.5 自治
每個Prometheus伺服器都設計為盡可能自治，旨在支援擴充到數千台主機的數百萬個時間序列的規模。資料存儲格式被設計為盡可能降低磁盤的使用率，并在查詢和聚合期間快速檢索時間序列。
為了速度和可靠性，建議Prometheus伺服器充分使用記憶體（Prometheus在記憶體中做很多事）和SSD磁盤。關于SSD的使用可以參考相關視訊。
2.2.6 備援和高可用性
備援和高可用性側重彈性而非資料持久性。Prometheus團隊建議将Prometheus伺服器部署到特定環境和團隊，而不是僅部署一個單體Prometheus伺服器。如果你确實要部署高可用HA模式，則可以使用兩個或多個配置相同的Prometheus伺服器來收集時間序列資料，并且所有生成的警報都由可消除重複警報的高可用Alertmanager叢集來處理。Prometheus備援架構如圖2-3所示。
圖2-3 Prometheus備援架構
我們将在第7章介紹如何實作此配置。
2.2.7 可視化
可視化通過内置表達式浏覽器提供，并與開源儀表闆Grafana內建。此外，Prometheus也支援其他儀表闆。
我們将在第4章了解這種內建。
2.3 Prometheus資料模型
正如之前所述，Prometheus收集時間序列資料。為了處理這些資料，它使用一個多元時間序列資料模型。這個時間序列資料模型結合了時間序列名稱和稱為标簽（label）的鍵/值對，這些标簽提供了次元。每個時間序列由時間序列名稱和标簽的組合唯一辨別。
2.3.1 名額名稱
時間序列名稱通常描述收集的時間序列資料的一般性質—例如，website_visits_total為網站通路的總數。
名稱可以包含ASCII字元、數字、下劃線和冒号。
2.3.2 标簽
标簽為Prometheus資料模型提供了次元。它們為特定時間序列添加上下文。例如，total_website_visits時間序列可以使用能夠識别網站名稱、請求IP或其他特殊辨別的标簽。Prometheus可以在一個時間序列、一組時間序列或者所有相關的時間序列上進行查詢。
标簽共有兩大類：插樁标簽（instrumentation label）和目标标簽（target label）。插樁标簽來自被監控的資源—例如，對于與HTTP相關的時間序列，标簽可能會顯示所使用的特定HTTP動詞。這些标簽在由諸如用戶端或exporter抓取之前會被添加到時間序列中。目标标簽更多地與架構相關—它們可能會識别時間序列所在的資料中心。目标标簽由Prometheus在抓取期間和之後添加。
時間序列由名稱和标簽辨別（盡管從技術上講，名稱本身也是名為__name__的标簽）。如果你在時間序列中添加或更改标簽，那麼Prometheus會将其視為新的時間序列。
你可以了解label就是鍵/值形式的标簽，并且新的标簽會建立新的時間序列。
标簽名稱可以包含ASCII字元、數字和下劃線。
帶有__字首的标簽名稱保留給Prometheus内部使用。
2.3.3 采樣資料
時間序列的真實值是采樣（sample）的結果，它包括兩部分：
- 一個float64類型的數值
- 一個毫秒精度的時間戳
2.3.4 符号表示
結合這些元素，我們可以看到Prometheus如何将時間序清單示為符号（notation），如下所示。
代碼清單2-1 時間序列符号
例如，帶有标簽的total_website_visits時間序列可能如下所示。
代碼清單2-2 時間序列示例
首先是時間序列名稱，後面跟着一組鍵/值對标簽。通常所有時間序列都有一個instance标簽（辨別源主機或應用程式）以及一個job标簽（包含抓取特定時間序列的作業名稱）。
這與OpenTSDB使用的符号大緻相同，受到了Borgmon的影響。
2.3.5 保留時間
Prometheus專為短期監控和警報需求而設計。預設情況下，它在其資料庫中保留15天的時間序列資料。如果要保留更長時間的資料，則建議将所需資料發送到遠端的第三方平台。Prometheus能夠寫入外部資料存儲，我們将在第7章看到更多相關内容。
2.4 安全模型
Prometheus可以通過多種方式進行配置和部署，關于安全有以下兩個假設：
- 不受信任的使用者将能夠通路Prometheus伺服器的HTTP API，進而通路資料庫中的所有資料。
- 隻有受信任的使用者才能通路Prometheus指令行、配置檔案、規則檔案和運作時配置。
從Prometheus 2.0開始，預設情況下某些HTTP API的管理功能被禁用。
是以，Prometheus及其元件不提供任何伺服器端的身份驗證、授權或加密。如果你在一個更加安全的環境中工作，則需要自己實施安全控制—例如，通過反向代理通路Prometheus伺服器或者正向代理exporter。由于不同版本的配置會潛在地發生較大變化，是以本書沒有記錄如何執行這些操作。
2.5 Prometheus生态系統
Prometheus生态系統由Prometheus項目本身提供的元件以及豐富的開源工具和套件組成。生态系統的核心是Prometheus伺服器，我們将在下一章進行詳細介紹。此外還有Alertmanager，它為Prometheus提供警報引擎并進行管理。
Prometheus項目還包括一系列exporter，用于監控應用程式和服務，并在端點上公開相關名額以進行抓取。核心exporter支援常見工具，如Web伺服器、資料庫等。許多其他exporter都是開源的，你可以從Prometheus社群檢視。
Prometheus還釋出了一系列用戶端庫，支援監控由多種語言編寫的應用程式和服務。它們包括主流程式設計語言，如Python、Ruby、Go和Java。其他用戶端庫也可以從開源社群擷取。
2.6 參考連結
- Prometheus官網：- https://prometheus.io/ 。
- Prometheus文檔： https://prometheus.io/docs/
- Prometheus GitHub首頁： https://github.com/prometheus/
- Prometheus GitHub源碼： https://github.com/prometheus/prometheus
- Prometheus參考視訊：大規模Prometheus和時間序列設計（ https://www.youtube. com/watch?v=gNmWzkGViAY）。
- Grafana官網： https://grafana.com/
2.7 小結
本章我們介紹了Prometheus的基本概念，以及Prometheus架構、Prometheus資料模型和Prometheus生态系統等方面的内容。
在下一章，我們将安裝并配置Prometheus，并收集我們的第一個名額。