容器監控的基石Prometheus 2.0到來

Kubernetes使得複雜環境的管理變得容易，但是為了確保可用性，對Kubernetes組件以及群集上運行的所有應用程序進行操作深入分析至關重要。在CoreOS，我們相信監控是良好生產環境的基石，這也是我們投入開發Prometheus監控系統（https://prometheus.io/）的原因。作為一個由Cloud Native Computing Foundation（CNCF）支持的項目，Prometheus迅速獲得了基礎設施及應用監控方面的熱度，今天是它更進一步的時候。

CoreOS將Prometheus作為我們企業級Kubernetes平台Tectonic的集成組件，並且我們也一直在努力提升其對Kubernetes用戶的價值。今年早些時候，我們分享了關於下一代Prometheus（version 2.0）的新存儲層方面的工作。為了穩固這項工作，我們和Prometheus團隊以及我們的用戶進行了更加密切的合作。在3個alpha版本，6個beta版本以及3個RC版本之後，今天Prometheus 2.0正式宣布穩定版本。感謝Brian Brazil和Goutham Veeramachaneni，他們在這項工作中付出巨大。在我們探索該發行版的優點之前，讓我們回過頭來，先探討一下我們為何需要一個新的存儲層。

時間序列和動態環境

Prometheus關於監控的理念鼓勵在堆棧的每一層都採用高度詳細的度量工具。容器的狀態，通過的請求流，甚至是運行於其中的應用的深層信息都通過度量工具對外可見。Prometheus帶來了一款強力的查詢語言幫助將度量數據匯總轉換成行動方案。

Prometheus通過時間序列的方式收集和存儲數據，它是通過固定間隔收集到的帶有時間戳數據的序列。這種設計可以使運行中的容器輕鬆產生成千的時間序列。隨著容器的規模從成百擴展到成千，在集群中很可能產生數百萬被跟蹤的時間序列。

為上百萬的時間序列持續寫入數據顯然是一項技術難題。更糟糕的是，Kubernetes使得持續銷毀和創建容器變得十分容易。該項模型對於持續部署，自動擴容以及批處理作業調度而言是極為強大的，因此只會隨著時間的推移而變得越來越普遍。

每個容器都有一個獨一無二的標識符，所有其時間序列均包含該標識符，以達到最佳的視角。因此當被跟蹤的活躍時間序列總數大致固定時，Prometheus中可以對外訪問的所有歷史時間序列數據是持續增長的。允許查詢十億級的時間序列是一項全新的挑戰，但我們決定讓Prometheus很好地支持該特性。

新的存儲引擎就是用來解決這項挑戰的。受到全文搜索的啟發，它使用倒排索引以提供對於Prometheus時間序列可能擁有的任意緯度進行快速檢索。新的磁碟格式確保相關的時間序列數據良好分佈，另外write-ahead日誌也使得Prometheus 2.0n能夠從崩潰中恢復。

Prometheus同樣變得更易操作了。Prometheus 1.x的用戶應該對調整期望負載的存儲配置十分熟悉。然而，有了新的存儲層之後，這些控制就不再需要了。

基準測

這項工作的真實結果是令人印象深刻的。Prometheus 2.0的資源消耗得到了顯著降低，使用率更加穩定，並且新的索引方式帶來了更低且一致的查詢延遲。

下方的圖是一個基準測試集的結果，它來自一個運行著成百個應用Pod並被監控的Kubernetes集群。Pod按照高頻率替換以產生時間序列的擾動。各有2個Prometheus 1.5和Prometheus 2.0實例運行採集新數據。不同版本中，各有1個實例對外服務，以產生適中性的高查詢負載。

從前2個圖中，我們可以看到Prometheus 2.0的內存和CPU消耗均明顯更低，並且自啟動后，它們很快到達穩定狀態。Prometheus 1.5則需要更多的資源，並且其資源使用率難以預測。

Prometheus 2.0中最大的改進是其每秒寫入磁碟的數據量，可以查看下圖。新版本的寫入量較之前低了近2個數量級。很明顯，這能增加SSD的壽命（譯者：SSD壽命由PE次數決定，與寫入數據量密切相關），進而降低成本。在高序列擾動的情況下，即使使用相同的序列壓縮演算法，依舊可以觀察到顯著的磁碟空間節省。

在Prometheus 1.5中，隨著更多的時間序列被創建，查詢的延遲是線性增長的。Prometheus 2.0則從一開始就維持了穩定的性能，它使得查詢的反饋更加敏捷，正如下圖所示。

其餘新特性

Prometheus 2.0的大多數工作都聚焦於提升性能並使其更加易於操作。但是新的存儲層同樣被設計以更好地和Prometheus的外部交互，這使得圍繞收集到的時間序列數據進行廣泛的定製處理成為可能。

快照備份是一項被頻繁要求的特性。當使用flag --web.enable-admin-api時，只需要通過簡單的API調用，Prometheus 2.0便可原生支持它們。

bash$ curl -XPOST http://<prometheus>/api/v2/admin/tsdb/snapshot{"name":"2017-10-18T13:44:35Z-3f6a679bb001e65d"}

快照存放於名為返回值的目錄中，且可以被上傳到歸檔存儲中，它們幾乎不會佔用額外的磁碟空間。最棒的是，新的Prometheus伺服器可以從備份的數據啟動，你只需將數據移動到新的伺服器數據目錄中即可。

關於完整的變更列表以及如何從Prometheus 1.x遷移，請查看官方聲明（https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/）以及遷移指南（https://prometheus.io/docs/prometheus/2.0/migration/）。

敬請嘗試

有關Prometheus 2.0增強的最佳部分是，Prometheus當前不但可以比以往更好地支持Kubernetes的工作負載，更在於當Kubernetes在基礎設施中活力倍增時，它預留了足夠的空間來支撐屆時的工作負載。

想要了解Prometheus，請關注11月16日上午8時webinar上關於新特性的PT（來自Prometheus開發者Frederic Branczyk）。

如果你想要親自了解集成Prometheus支持是如何使得CoreOS Tectonic成為真正的企業級Kubernetes平台的，你可以免費部署一個不多於10個節點的Tectonic集群。你將能夠使用最新的Prometheus操作器不費吹灰之力地在集群中部署Prometheus 2.0，而無需額外的配置。

聲明：本文中的基準測試通過prombench（https://github.com/prometheus/prombench）生成。為了復現它們，你需要一個配置好的AWS賬戶，並且你必須指定想要執行的基準測試spec。spec.example.yaml正是生成本文所用圖的spec。