Promethues 的 Agent 模式：高效轉發(fā)云原生指標

Bartek Plotka 是紅帽的首席軟件工程師，從 2019 年開始擔任 Prometheus 項目的維護者，也是 CNCF Thanos 項目的共同作者之一，同時還擔任 CNCF 大使以及 CNCF 可觀察性 TAG 的技術領導者。他在業(yè)余和 O’Reilly 出版了《Efficient Go》一書。

—?1?—

前言

Promethues 對于目標的極度專注是我喜歡并加入這個項目的原因。Prometheus 用務實、可靠、經(jīng)濟的方式，推出了無價的指標監(jiān)控系統(tǒng)。Prometheus 提供了極其穩(wěn)定和健壯的 API、查詢語言和用于進行集成的協(xié)議（例如遠端寫入和 OpenMetrics），這一穩(wěn)固的基礎，讓云原生的監(jiān)控生態(tài)欣欣向榮：

• 社區(qū)提供了包羅萬象的 Exporter，例如容器、eBPF、我的世界甚至還有針對園藝的健康監(jiān)測；
• 現(xiàn)在多數(shù) CNCF 項目都會提供基于 HTTP/HTTPS 的?/metrics?端點，讓 Prometheus 可以讀取指標數(shù)據(jù)。
  這原本是 Google 內部秘而不宣的一個概念，Prometheus 項目將其公諸于世；
• 可觀察性的范式發(fā)生了變化。
  從一開始 SRE 和開發(fā)者就非常依賴指標數(shù)據(jù)，對軟件的韌性、排障能力以及數(shù)據(jù)驅動的決策過程產(chǎn)生了很好的推動作用

最后，我們極少會看到?jīng)]有運行 Prometheus 的 Kubernetes。

備受矚目的 Prometheus 社區(qū)讓其它項目也同步成長，讓 Prometheus 脫離了單節(jié)點部署的局限性（例如 Context、Thanos 等等），更有采用 Promethues API 和數(shù)據(jù)模型的云供應商（例如亞馬遜和谷歌的托管 Promethues、Grafana 云等）。如果 Prometheus 只有一個原因，那么這個原因只能是——把監(jiān)控社區(qū)的焦點聚集在重要的事情上面。

本文中將會介紹 Prometheus 的新特性：“Agent”。這一特性內置于 Prometheus 之中。Agent 模式禁用了 Prometheus 的一些特性，優(yōu)化了指標抓取和遠程寫入的能力。這一特性使得一種新的應用模式成為可能。本文中我會陳述該功能讓 CNCF 生態(tài)中游戲規(guī)則發(fā)生的變化——是的他讓我非常興奮。

—?2?—

轉發(fā)模式的歷史

Prometheus 的核心設計從未變更。這是一個向 Google Borgmon 監(jiān)控系統(tǒng) 致敬的產(chǎn)品，要監(jiān)控一個應用，就隨應用部署一個 Prometheus 服務，告知 Promethues 如何聯(lián)系到這個服務，允許 Prometheus 定期抓取當前的指標數(shù)據(jù)。這種工作方式通常被稱為拉取模型，這種模型保障 Promethues 的輕量和韌性。另外它還極大簡化了應用監(jiān)控和 Exporter——只需要提供一個簡單易讀的 HTTP 端點，在其中提供 OpenMetrics 格式的當前指標值即可。這其中沒有用到復雜的推送機制，也沒有客戶端庫。一個簡單的 Prometheus 監(jiān)控部署如下圖所示：

這種方式工作良好，過去幾年中我們看到了上百萬的部署案例，其中或長或短的留存了大量的監(jiān)控數(shù)據(jù)。其中的指標數(shù)據(jù)可以進行查詢、告警，并記錄管理員和開發(fā)者都關注的數(shù)據(jù)指標。

然而云原生世界一直在發(fā)展和進化。隨著托管 Kubernetes 方案的成長，幾秒鐘就能隨需創(chuàng)建 Kubernetes 集群，我們已經(jīng)能夠把集群當做牲畜而非寵物（換句話說，我們不再關注特定的實例）。在 kcp 和 Fargate 中這樣的產(chǎn)品中甚至沒有了集群的概念。

另一個有意思的概念就是經(jīng)常被用在電信、汽車和 IoT 領域的邊緣集群和網(wǎng)絡。我們會看到越來越多資源有限的小集群。規(guī)模限制導致他們無法在本地進行保存，包含監(jiān)控數(shù)據(jù)在內的大量數(shù)據(jù)都需要被傳送到遠端的更大的節(jié)點上。

這意味著必須對必須對監(jiān)控數(shù)據(jù)進行聚合，向用戶進行呈現(xiàn)，甚至需要有全局級別的存儲。這通常被稱為全局視角。

要實現(xiàn)全局視角，最直接的辦法就是在全局層次部署 Prometheus，通過遠程網(wǎng)絡抓取指標，或者從遠端應用直接寫入監(jiān)控數(shù)據(jù)。我認為兩種辦法都爛透了，原因如下：

跨越網(wǎng)絡邊界的抓取行為會在監(jiān)控管線中引入不確定因素。本地的拉取模型讓 Prometheus 能夠清晰獲知待抓取目標的問題，例如宕機或者配置錯誤、重啟、抓取緩慢（CPU 耗盡）、無法進行服務發(fā)現(xiàn)、缺乏訪問憑據(jù)、DNS 故障，網(wǎng)絡甚至整個集群失靈。外置抓取端引發(fā)的不穩(wěn)定性可能讓我們丟失信息。如果網(wǎng)絡中斷，可能會喪失可見性，相信我，不要這樣做。

應用從遠端直接向中心推送數(shù)據(jù)也不是什么好辦法——尤其是在監(jiān)控目標數(shù)量巨大時。得到指標之前，無法得到任何遠端應用的信息，這個應用活著嗎？是我的管線故障了嗎？也許應用認證失敗了？和前面的辦法一樣，跨網(wǎng)絡的傳輸總面臨著更大的風險。

Serverless 應用以及類似的短壽命容器經(jīng)常會讓我們將遠端推送方式當做救命稻草。這種情況下我們希望把細碎的事件和指標能夠聚合到一個較長存活期的時間序列里。我們對這一主題也進行了討論，歡迎加入，一起完善這個方案。

Prometheus 用三種方式來支持全局視圖，每種都有不同的優(yōu)缺點。注意下圖橘色部分：

• 聯(lián)邦：這是第一種用于聚合目的的方案。這種方案里，全局級的 Prometheus 服務器或從基層 Prometheus 中抓取指標的子集。這種級聯(lián)方式里，聯(lián)邦節(jié)點暴露的指標中包含了原始采樣的時間戳，因此降低了跨網(wǎng)絡抓取的風險，但是如果網(wǎng)絡間的時延達到分鐘級，可能就無法在不損失數(shù)據(jù)的情況下完成數(shù)據(jù)聯(lián)合了。
• Prometheus 遠程讀取：從遠端 Prometheus 服務器的數(shù)據(jù)庫中繞過 PromQL，直接提取原始數(shù)據(jù)?？梢栽谌忠患壊渴?Prometheus 或者 Thanos 方案，用抓取自多個站點的遠程數(shù)據(jù)來執(zhí)行 PromQL 查詢。這種方式很強大——數(shù)據(jù)存儲在“本地”，還可以按需訪問。不幸的是，這種方式也有缺點，如果沒有 Query Pushdown，一個簡單的查詢可能就要拉取上 GB 的壓縮數(shù)據(jù)。類似地，如果網(wǎng)絡失聯(lián)，服務就不可用了，另外有些集群只允許 Egress，禁止 Ingress
• 最后一種就是遠程寫入：這似乎是目前最流行的選擇。Agent 模式也是聚焦于遠程寫入的，因此我們要詳細描述一下這個模式

—?3?—

遠程協(xié)助

Prometheus 遠程寫入?yún)f(xié)議讓用戶可以把部分或者全部指標數(shù)據(jù)寫入到遠端，可以對 Prometheus 進行配置，將一些指標（其中甚至可以代入所有的元數(shù)據(jù)和范例）轉發(fā)給一個或多個遠端的寫入 API。實際上 Prometheus 是同時支持遠端接收和寫入的，所以可以部署全局級的 Prometheus 來接收跨集群的聚合數(shù)據(jù)。

Prometheus 遠程寫入 API 規(guī)范還在評審階段，但整個生態(tài)接受了遠端寫入?yún)f(xié)議作為缺省指標導出協(xié)議。例如 Cortext、Thanos、OpenTelemetry 以及 Amazon、Google、Grafana、Logz.io 等云廠商，都支持這一協(xié)議的寫入。

Prometheus 官方提供了官方的 API 兼容性測試，能通過遠程寫入合規(guī)性測試的方案，就可以提供遠程寫入的客戶端能力。對于自行實現(xiàn)的工具來說這個功能非常有幫助，能幫助自實現(xiàn)工具確認協(xié)議實現(xiàn)的正確性。

抓取得到的流數(shù)據(jù)進行中心化存儲之后，就有了全局視圖的實現(xiàn)基礎。這樣也實現(xiàn)了關注點的分離。應用程序不受可觀察性團隊的管理的情況下，這種方式很有優(yōu)勢。這種方式讓服務商們能夠將這種工作從客戶側剝離開來，因此得以廣泛采用。

但是 Bartek 你剛剛說過，從應用推送指標不是個好主意！

沒錯，不過有意思的是，遠程寫入的情況下，Prometheus 還是使用拉取模式從應用端獲得指標數(shù)據(jù)的，然后對取樣和序列進行批處理，把數(shù)據(jù)進行導出，推送到遠程寫入端點，有效地降低了中心點在應用失聯(lián)時面臨的風險。

遠程寫入的可靠性和效率，是一個亟待解決的難題。普羅米修斯社區(qū)花了大約三年的時間完成了穩(wěn)定和可擴展的實現(xiàn)。WAL（寫前日志）經(jīng)過多次重構后，增加了內部隊列、分片、智能備份等等。所有這些對用戶來說都是隱藏的，用戶可以在集中存儲的場景下得到良好的流性能和數(shù)據(jù)量支持。

Katacoda 教程：遠程寫入

在 Prometheus 中這些都不新鮮，很多用戶都在使用這種抓取應用信息后向遠端進行寫入的方式。

要體驗這種遠端寫入能力，推薦使用 Katacoda 提供的 Prometheus 遠程寫入 Thanos 教程，其中解釋了 Prometheus 遠程轉發(fā)的所有步驟。這個課程是免費的，注冊賬號嘗試一下就好。

這里用接收模式的 Thanos 作為遠程存儲?，F(xiàn)在還可以使用大量與遠程寫入 API 兼容的其它項目。

遠程寫入這么好，為什么還要給 Prometheus 加入 Agent 模式？

Prometheus 的 Agent 模式

Prometheus v2.32.0 開始，用戶可以使用測試版參數(shù)?--enable-feature=agent?來啟動啟動 Prometheus。

Agent 模式優(yōu)化了遠程寫入的用例。它禁止了查詢、告警和本地存儲，取而代之的是一個自定義的 TSDB WAL。其它部分原封不動：抓取邏輯、服務發(fā)現(xiàn)和相關的配置。如果只是想把數(shù)據(jù)轉發(fā)到遠端的 Prometheus 服務器或其它兼容的項目，這種方式非常值得一試。工作方式如下圖所示：

如果你不想在本地進行查詢和告警，只是把指標輸出到外部，使用 Agent 有什么好處呢？

第一個就是效率。Agent 中使用的 TSDB WAL 在轉發(fā)成功后會立刻刪除數(shù)據(jù)。如果遠程端點無法連接，就會將數(shù)據(jù)保存起來，等待端點恢復。這種行為很像非 Agent 模式的 Prometheus，目前的緩沖有效期是兩個小時，未來可能打破這個限制。這樣一來我們就無需分配大塊內存，也不用為查詢準備完全索引。代理模式的資源消耗比標準服務實例低得多。

在邊緣或者類似的環(huán)境中，CPU 和內存資源可能會很有限，效率是個非常重要的問題。另外目前使用指標進行監(jiān)控的模式已經(jīng)非常成熟。這意味著同樣成本之下，能獲得越多的監(jiān)控指標，就越有性價比。

Agent 模式是針對特定使用場景的，標準模式的 Promethues Server 更穩(wěn)定、更易維護，仍是缺省建議；Agent 模式的遠端存儲引入了更高的復雜性，還需謹慎使用。

另外，Agent 模式便于搭建縱向伸縮的數(shù)據(jù)接收架構。

指標接收端的彈性伸縮

數(shù)據(jù)抓取側的自動伸縮方案需要根據(jù)抓取目標和指標數(shù)量進行判斷。抓取的數(shù)據(jù)越多，就要自動部署更多實例。如果目標和指標數(shù)量下降了，就應該進行縮容，移除部分實例。自動伸縮能夠降低 Promethues 規(guī)模調整造成的手工操作負擔，并防止低谷期間浪費系統(tǒng)資源。

Server 模式的 Prometheus 是有狀態(tài)的，很難應對這種需求。這種模式下搜集的數(shù)據(jù)保存在本地，縮容過程需要在中止實例之前將數(shù)據(jù)進行備份。接下來還要面對指標重疊、誤導性的過期標記等問題。

這種場景下，我們需要能夠聚合所有實例所有數(shù)據(jù)的全局視圖（例如 Thanos Query 或者 Promxy）來進行查詢。普通模式下的 Prometheus 的職責不僅限于指標采集，還包含了告警、錄制、查詢、壓縮、遠程寫入等，這些任務都會消耗資源。

Agent 模式將服務發(fā)現(xiàn)、指標抓取和遠程寫入放到一個單獨的服務中，如此就將工作焦點集中到了指標搜集上面。Agent 模式的 Prometheus 變得更加的“無狀態(tài)”。是的為了防止數(shù)據(jù)丟失，我們需要部署一對 HA 實例，并掛接持久存儲。但是技術上來說，我們有幾千個目標（容器），我們可以部署多個 Prometheus Agent，安全地把抓取目標分配給特定實例。這么做的根本原因就是這些數(shù)據(jù)都會被推送給同一個中央存儲。

總的說來，Agent 模式的 Prometheus 讓自動的水平伸縮成為可能，從而有了針對監(jiān)控指標規(guī)模變更進行應對的能力。我們將會和 Prometheus Kubernetes Operator 社區(qū)一起在這個方向努力。

那么 Agent 模式的 Prometheus 是否真的可用呢？

Agent 模式得到了大規(guī)模驗證

Prometheus 會把 Agent 模式作為實驗性功能加入下一個版本。參數(shù)、API 以及 WAL 的格式會發(fā)生變更。但是這種實現(xiàn)的性能已經(jīng)在 Grafana Lab 的幫助下得到了實際驗證。

Agent 的自定義 WAL 最初的實現(xiàn)是受到了 Robert Fratto 在 2019 年為 TSDB 實現(xiàn)的 WAL 的啟發(fā)，期間得到了 Prometheus Maintainer Tom Wilkie 的指導。這個格式后來被用于 Grafana Agent 項目，得到了很多 Grafana 云的用戶的采用。這一方案的成熟后，捐獻給了 Promethues，希望得到集成和更多的發(fā)展和采用。Grafana 實驗室的 Robert 在 Redhat 的 Srikrishna 以及社區(qū)幫助下，把這些代碼移植到了 Prometheus，然后只用了半個月就合并進入到?main?分支。

有些 Prometheus Maintainer 也曾經(jīng)為 Grafana Agent 項目貢獻過代碼，Grafana 的新 WAL 格式也是受到了 Prometheus WAL 格式的啟發(fā)，捐獻的過程非常平滑，并且目前的 Prometheus TSDB Maintainer 也能夠方便的進行管理。并且 Robot 已經(jīng)加入 Prometheus 團隊，成為 TSDB 的 Maintainer。

接下來講講如何使用。

—?4?—

Agent 總結

Prometheus 的幫助（--help?參數(shù)）內容中會看到類似內容：

usage: prometheus []

The Prometheus monitoring server

Flags:
  -h, --help                     Show context-sensitive help (also try --help-long and --help-man).
      (... other flags)
      --storage.tsdb.path="data/"
                                 Base path for metrics storage. Use with server mode only.
      --storage.agent.path="data-agent/"
                                 Base path for metrics storage. Use with agent mode only.
      (... other flags)
      --enable-feature= ...      Comma separated feature names to enable. Valid options: agent, exemplar-storage, expand-external-labels, memory-snapshot-on-shutdown, promql-at-modifier, promql-negative-offset, remote-write-receiver,
                                 extra-scrape-metrics, new-service-discovery-manager. See https://prometheus.io/docs/prometheus/latest/feature_flags/ for more details.

Agent 模式是需要用?--enable-feature=agent?參數(shù)的啟用的。這種模式下能夠使用同樣的指標抓取配置以及遠程寫入能力。Agent 模式下，Web UI 的查詢功能是被禁用的，只能用于展示構建信息、配置內容、抓取指標和服務發(fā)現(xiàn)信息。

在 Katacoda 上嘗試 Prometheus Agent

可以在 Katacoda 上嘗試 Promtheus Agent，真切體會其中的易用性。