搭建Prometheus平台，你必須考慮的6個因素

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

目前，Prometheus被許多企業群組織廣泛使用，以監控其容器和微服務。但是在這一過程中，大型公司通常會陷入困境：當應用程式數量越來越多的時候，擴充監控名額則是一個十分重大的挑戰。

不斷增長的容器使情況複雜化

相對來說，監控單體環境常常更簡單，因為靜态實體伺服器和虛拟機數量是确定的，并且監控名額的數量也是有限的。但是，如今由于容器以及需要向微服務架構遷移，要跟蹤監控的執行個體程式數量激增。

如果說位于資料中心的伺服器是寵物，需要我們不斷關注的話，那麼雲執行個體則更像牛（因為有很多，你不必關心單個執行個體），而容器則更像小蜜蜂。它們數量很多，有時每台機器有數百個容器，并且新的容器一直不斷出現，當與諸如Kubernetes的容器編排引擎一起使用時，它們的壽命可能非常短。這使得跟蹤監控它們變得更加困難，而且如果你不小心誤操作的話，它們可能會造成很多損害。

随着複雜性和分布式環境的增加，你需要監控的實體數量也在增加。此外，你可能希望監控更多屬性以確定你對正在發生的事情有準确的了解，或者在進行故障排除或事件響應的情況下，可以了解正在發生的事情。在短暫的環境中，後者尤其成問題，因為當你想了解問題的根本原因時，通常相關的資源已經停用，這意味着監控解決方案必須提供一種能夠存儲足夠的曆史記錄以進行驗證的方法。

流行的監控工具：Prometheus

越來越多需要雲監控的團隊正在轉向Prometheus，這是一個開源的CNCF項目。Prometheus已成為開發人員用來在雲原生環境中收集和了解名額的首選監控工具。它由一個大型社群支援，有來自700多家公司的6300個貢獻者，有13500個代碼送出和7200個拉取請求。

預設情況下，典型的雲原生應用程式堆棧（如Kubernetes、Ngnix、MongoDB、Kafka、golang等）會暴露Prometheus名額。Prometheus是一個可以垂直彈性伸縮的Go程式，為單個容器或單個主機部署它時十分容易。換言之，一開始使用Prometheus極為容易，你可以輕松監控你的第一個Kubernetes叢集，但是這也意味着随着基礎架構的增長，監控會越來越複雜。

應用程式增長帶來的擴充問題

随着環境規模增長，你需要跟蹤監控飛速增長的時間序列資料，并且在資料量達到某個點之後，單個Prometheus執行個體無法繼續跟蹤監控。這一情況下，最直接的選擇是在整個企業中運作一組Prometheus伺服器，但這帶來了一些挑戰。例如，跨數十甚至數百台Prometheus伺服器管理和合并資料并不容易。同樣，了解企業工作流程、單點登入、基于角色的通路控制以及遵守SLA或合規性也不是容易的問題。随着應用程式的增長，在不中斷開發人員工作的情況下運作一個全方位的監控解決方案，這将成為一個可管理性和可靠性的問題。

為了解決這一問題，企業采用了許多方法。

簡單的方法是為每個命名空間或每個叢集都準備一個單獨的Prometheus伺服器。這種方法到一定規模就會難以為繼，此外，它還有一個缺點，那就是會造成大量的斷開的資料孤島。這會使故障排查變得很麻煩，因為大多數問題會跨越多個服務/團隊/叢集。不但在每個環境中很難找到相同的名額，你還需要把資料拼接在一起，以試圖了解發生了什麼。

另一個常見方法是使用類似Cortex或Thanos的開源工具來集合多個Prometheus伺服器。這些高效的工具可以讓你集中查詢伺服器、收集資料然後在統一的dashboard中共享。然而，與任何資料密集型分布式系統一樣，它們需要大量的技能和資源才能運作。

需要考慮的6個因素

對于那些以Prometheus為起點，然後尋求商業化解決方案以獲得全局監控的公司來說，重要的是，不丢失Prometheus上完成的所有标準化開發工作——dashboard、告警、exporter等。然而，這不是需要考慮的唯一事情，如果你繼續使用Prometheus，需要堅持以下标準：

1、 相容性，以支援所有Prometheus功能

你的供應商/所使用的工具/SaaS解決方案需要能夠使用任何可産生Prometheus名額的實體程式中消耗資料，無論是本地Kubernetes還是雲服務。相對來說，消耗Prometheus名額微不足道，但是也不要忽略一些小事情，例如将名額提取到存儲中或增加資料時能夠重新标注名額，這樣對你的環境更有意義。這些小事加起來，能夠收集到的資料将會堆積如山、大不相同。

2、 PromQL相容性

Prometheus查詢語言由Prometheus建立者發明，用于提取存儲在Prometheus中的資訊。PromQL能讓你查詢指定服務或指定使用者的名額，它還能彙總或細分資料。例如，你可以使用它顯示所有容器中每個應用的CPU使用率。或者僅顯示Cassandra容器的資料，并将其顯示為每個叢集的單個值。可以說，PromQL釋放了Prometheus的真正價值，是以如果将Prometheus的名額內建到一個不完全支援PromQL的産品中，就完全違背了使用Prometheus的初衷。

3、 支援熱插拔

要真正與Prometheus相容，該解決方案必須能夠支援熱插拔，以便能夠與你現有的dashboard、告警和腳本一起使用。例如，許多使用Prometheus的企業都将Grafana用于dashboard。這個開源工具能夠與Prometheus很好地內建在一起，包括在查詢級别，并且可以用于生成一系列有用的圖表和dashboard。是以，聲稱與Prometheus相容的商業産品應與Grafana等工具相容。僅僅說解決方案可以讓你在Grafana中檢視數字是遠遠不夠的，你需要能夠按照原樣提取現有的Grafana dashboard，并将它們重新應用于商業解決方案中已安裝的資料。

4、 通路控制

在評估工具時，通路控制是另一個你需要考慮的安全問題。能夠使用行業标準協定（包括LDAP、Google Oauth、SAML和OpenID）保護使用者身份驗證，使公司能夠通過基于服務的通路控制來隔離和保護資源。

5、 故障排查

Kubernetes簡化了部署、彈性伸縮和管理容器化應用程式和微服務。這有助于保持服務的正常運作，但是要識别和解決諸如性能降低、部署失敗和連接配接錯誤之類的根本問題，你需要能夠從整個環境中收集和可視化基礎架構、應用程式和性能資料。由于無法同時通路實時資訊和上下文資料，是以幾乎不可能關聯環境中的名額，是以你可以更快地解決問題。

6、 與現有告警相容

最後，如果你正在尋找商業解決方案來幫助解決Prometheus可擴充性問題，請確定它支援所有級别的告警。能夠實作這一目标的關鍵是全面支援Alert Manager功能，而Alert Manager還要求100%的內建和 PromQL相容性。

如果你找到一個能夠滿足以上标準的商業化工具，你應該能夠輕松将其內建到現有的Prometheus中，并且能夠避免公司遇到的可擴充性問題。開發人員有充分的理由喜愛Prometheus，是以在采用商業化方案之前進行全面、盡職的調查将確定他們仍然可以使用自己喜歡的名額。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/live

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-06-02

本文作者：Rancher

本文來自：“

dockone

”，了解相關資訊可以關注“dockone”