Cortex：多租戶、可橫向擴充套件的Prometheus即服務

作者：Luc Perkins

Prometheus是用於監控和可觀察性的標準開源解決方案之一。 Prometheus於2012年起源於SoundCloud，迅速獲得廣泛採用，後來成為首批CNCF專案之一，第二個畢業專案（僅次於Kubernetes）。它被許多具有前瞻性思維的公司用於生產，包括DigitalOcean、Fastly和Weaveworks等重量級公司，並擁有自己的年度會議PromCon。

Prometheus：強大但有意地限制

Prometheus之所以成功，部分原因是核心Prometheus伺服器及其各種補充程式，如Alertmanager、Grafana和匯出生態系統，形成了一個引人注目的端到端解決方案，解決了一個至關重要的難題。但是，Prometheus並沒有提供你期望從一個成熟的“即服務”平臺中獲得的一些功能，例如多租戶、身份驗證和授權以及內建的長期儲存。

Cortex於9月作為沙箱專案加入CNCF，是一個開源的Prometheus即服務平臺，旨在填補這些空白，從而提供完整、安全、多租戶的Prometheus體驗。我會在以下說很多關於Cortex的，首先，讓我們短暫地遊覽更熟悉的Prometheus世界。

為何選擇Prometheus？

作為CNCF開發者的倡導者，我有機會熟悉Prometheus社群和Prometheus作為工具（主要研究文件和Prometheus Playground）。由於各種原因，它的巨大成功對我來說並不奇怪：

• Prometheus例項易於部署和管理。我特別喜歡近乎即時的配置重新載入，以及所有Prometheus元件都提供靜態二進位制檔案。
• Prometheus提供了簡單易用的指標展示格式，可以輕鬆編寫自己的指標匯出器。這種格式甚至通過OpenMetrics專案（最近也加入了CNCF沙箱）變成了開放標準。
• Prometheus提供了簡單，但功能強大的基於標籤的查詢語言PromQL，用於處理時間序列資料。我覺得PromQL非常直觀。

為何選擇Prometheus即服務？

早期，Prometheus的核心工程師做出明智的決定，讓Prometheus保持簡潔和可組合。從一開始，Prometheus設計成可以很好地完成一小部分工作，並與其他可選元件無縫協作（而不是讓Prometheus負擔過重，增加了一系列硬編碼功能和整合）。以下是Prometheus設計範圍外的一些內容：

• 長期儲存 - 單個Prometheus例項提供持久儲存時間序列資料，但它們不能作為分散式資料儲存系統，不提供像具有跨節點複製和自動修復等功能。這意味著，耐久性保證僅限於單臺機器。幸運的是，Prometheus提供了一個遠端寫入API，可用於將時間序列資料傳輸到其他系統。
• 全域性資料檢視 - 如上面要點所述，Prometheus例項充當隔離資料儲存單元。Prometheus例項可以聯邦，但這會給Prometheus設定增加很多複雜性，而且Prometheus不是設計為分散式資料庫。這意味著，沒有簡單的途徑來實現時間序列資料的單一，一致的“全域性”檢視。
• 多租戶 - Prometheus本身沒有的租戶概念。這意味著，它無法對特定於租戶的資料訪問和資源使用配額等事物，提供任何形式的細粒度控制。

為何選擇Cortex？

作為Prometheus即服務平臺，Cortex充分填補所有這些關鍵缺口，為即使是最苛刻的監控和可觀察性使用案例，提供了完整的開箱即用解決方案。

• 它支援四種開箱即用的長期儲存系統：AWS DynamoDB、AWS S3、Apache Cassandra和Google Cloud Bigtable。
• 它提供了Prometheus時間序列資料的全域性檢視，其中包括長期儲存中的資料，極大地擴充套件了PromQL用於分析目的的有用性。
• 它的核心支援多租戶。通過Cortex的所有Prometheus指標都與特定租戶相關聯。

Cortex的架構

Cortex具有基於服務的設計，其基本功能分為單個用途元件，可以獨立擴充套件：

• Distributor - 使用Prometheus的遠端寫入API處理由Prometheus例項寫入Cortex的時間序列資料。傳入資料會自動複製和分片，並且並行傳送到多個Cortex Ingester。
• Ingester - 從distributor節點接收時間序列資料，然後將該資料寫入長期儲存後端，壓縮資料到Prometheus塊以提高效率。
• Ruler - 執行規則並生成警報，將它們傳送到Alertmanager（Cortex安裝包括Alertmanager）。
• Querier - 處理來自客戶端（包括Grafana儀表板）的PromQL查詢，對短期時間序列資料和長期儲存中的樣本進行抽象。

這些元件每一個都可以獨立管理，這是Cortex可擴充套件性和運營的關鍵。你可以在下面看到Cortex及與其互動的系統的基本圖表：

如圖所示，Cortex“完成”Prometheus監控系統。要適應現有的Prometheus安裝，你只需重新配置Prometheus例項以遠端寫入Cortex群集，Cortex將處理其餘部分。

多租戶

單租戶系統往往適用於小型用例和非生產環境，但對於擁有大量團隊、用例和環境的大型組織而言，這些系統變得站不住腳（沒有雙關語意）。為了滿足這些大型組織的嚴格要求，Cortex不是作為附加元件或外掛提供多租戶，而是作為頭等功能。

多租戶被編織到Cortex的結構中。從Prometheus例項到達Cortex的所有時間序列資料，都在請求元資料中標記所屬於的特定租戶。從那裡，該資料只能由同一個租戶查詢。警報也是多租戶，每個租戶都可以使用Alertmanager配置設定自己的警報。

從本質上講，每個租戶都有自己的系統“檢視”，其自身以Prometheus為中心的世界。如果你以單租戶的方式使用Cortex，你可以隨時擴充套件到無限大的租戶群。

用例

經過幾年的發展，Cortex的使用者傾向於分為兩大類：

1. 服務供應商構建託管的管理平臺，提供監控和可觀察性元件。例如，如果你正在構建像Heroku或Google App Engine這樣的平臺即服務產品，Cortex使你能夠為平臺上執行的每個應用程式，提供Prometheus提供的全部功能，並處理每個應用程式（ 或者每個帳戶或客戶）作為系統的單獨租戶。Weave Cloud和Grafana Labs使用Cortex使客戶能夠充分利用Prometheus，他們是綜合雲平臺的示例。
2. 企業擁有許多內部客戶，執行自己的應用程式、服務和“堆疊”。EA和StorageOS是受益於Cortex的大型企業的例子。

Cortex、Prometheus的生態系統和CNCF

Cortex有一些非常引人注目的技術特性，但在當前的行業氛圍下，我也認為指出其開源特性也很重要：

• Cortex使用Apache 2.0許可授權，並由CNCF支援。
• 它僅與其他Apache 2.0 CNCF專案緊密耦合，沒有與閉源、專有或特定於供應商技術的強連結。
• 專案合作者包括像Goutham Veeramachaneni和Tom Wilkie這樣的Prometheus核心維護者，來自Weaveworks、Grafana Labs、Platform9等公司的工程師，以及其他大量投資於監控和可觀察性領域的工程師。
• Cortex已經投入生產，為Weave Cloud和Grafana Cloud提供支援，這兩個雲產品（和核心貢獻者）的成功關鍵取決於Cortex未來的發展軌跡。

通過在CNCF沙箱中新增Cortex，現在CNCF保護傘下有三個與Prometheus相關的專案（包括Prometheus本身和OpenMetrics）。我們知道監控和可觀察性是雲原生正規化的重要組成部分，我們很高興看到圍繞Prometheus社群有機出現的一些核心基礎的持續融合。Cortex專案正在大力推進這項工作，我很興奮Prometheus生態系統的Prometheus即服務分支成型。