搭建Prometheus平臺需要考慮哪些因素

這篇文章主要介紹搭建Prometheus平臺需要考慮哪些因素，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

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

相對來說，監(jiān)控單體環(huán)境常常更簡單，因為靜態(tài)物理服務器和虛擬機數(shù)量是確定的，并且監(jiān)控指標的數(shù)量也是有限的。但是，如今由于容器以及需要向微服務架構遷移，要跟蹤監(jiān)控的實例程序數(shù)量激增。

如果說位于數(shù)據(jù)中心的服務器是寵物，需要我們不斷關注的話，那么云實例則更像牛（因為有很多，你不必關心單個實例），而容器則更像小蜜蜂。它們數(shù)量很多，有時每臺機器有數(shù)百個容器，并且新的容器一直不斷出現(xiàn)，當與諸如Kubernetes的容器編排引擎一起使用時，它們的壽命可能非常短。這使得跟蹤監(jiān)控它們變得更加困難，而且如果你不小心誤操作的話，它們可能會造成很多損害。

隨著復雜性和分布式環(huán)境的增加，你需要監(jiān)控的實體數(shù)量也在增加。此外，你可能希望監(jiān)控更多屬性以確保你對正在發(fā)生的事情有準確的了解，或者在進行故障排除或事件響應的情況下，可以了解正在發(fā)生的事情。在短暫的環(huán)境中，后者尤其成問題，因為當你想了解問題的根本原因時，通常相關的資源已經(jīng)停用，這意味著監(jiān)控解決方案必須提供一種能夠存儲足夠的歷史記錄以進行取證的方法。

流行的監(jiān)控工具：Prometheus

越來越多需要云監(jiān)控的團隊正在轉(zhuǎn)向Prometheus，這是一個開源的CNCF項目。Prometheus已成為開發(fā)人員用來在云原生環(huán)境中收集和理解指標的首選監(jiān)控工具。它由一個大型社區(qū)支持，有來自700多家公司的6300個貢獻者，有13500個代碼提交和7200個拉取請求。

默認情況下，典型的云原生應用程序堆棧（如Kubernetes、Ngnix、MongoDB、Kafka、golang等）會暴露Prometheus指標。Prometheus是一個可以垂直彈性伸縮的Go程序，為單個容器或單個主機部署它時十分容易。換言之，一開始使用Prometheus極為容易，你可以輕松監(jiān)控你的第一個Kubernetes集群，但是這也意味著隨著基礎架構的增長，監(jiān)控會越來越復雜。

應用程序增長帶來的擴展問題

隨著環(huán)境規(guī)模增長，你需要跟蹤監(jiān)控飛速增長的時間序列數(shù)據(jù)，并且在數(shù)據(jù)量達到某個點之后，單個Prometheus實例無法繼續(xù)跟蹤監(jiān)控。這一情況下，最直接的選擇是在整個企業(yè)中運行一組Prometheus服務器，但這帶來了一些挑戰(zhàn)。例如，跨數(shù)十甚至數(shù)百臺Prometheus服務器管理和合并數(shù)據(jù)并不容易。同樣，了解企業(yè)工作流程、單點登錄、基于角色的訪問控制以及遵守SLA或合規(guī)性也不是容易的問題。隨著應用程序的增長，在不中斷開發(fā)人員工作的情況下運行一個全方位的監(jiān)控解決方案，這將成為一個可管理性和可靠性的問題。

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

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

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

需要考慮的6個因素

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

1、 兼容性，以支持所有Prometheus功能

你的供應商/所使用的工具/SaaS解決方案需要能夠使用任何可產(chǎn)生Prometheus指標的實體程序中消耗數(shù)據(jù)，無論是本地Kubernetes還是云服務。相對來說，消耗Prometheus指標微不足道，但是也不要忽略一些小事情，例如將指標提取到存儲中或增加數(shù)據(jù)時能夠重新標注指標，這樣對你的環(huán)境更有意義。這些小事加起來，能夠收集到的數(shù)據(jù)將會堆積如山、大不相同。

2、 PromQL兼容性

Prometheus查詢語言由Prometheus創(chuàng)建者發(fā)明，用于提取存儲在Prometheus中的信息。PromQL能讓你查詢指定服務或指定用戶的指標，它還能匯總或細分數(shù)據(jù)。例如，你可以使用它顯示所有容器中每個應用的CPU使用率?；蛘邇H顯示Cassandra容器的數(shù)據(jù)，并將其顯示為每個集群的單個值?？梢哉f，PromQL釋放了Prometheus的真正價值，因此如果將Prometheus的指標集成到一個不完全支持PromQL的產(chǎn)品中，就完全違背了使用Prometheus的初衷。

3、 支持熱插拔

要真正與Prometheus兼容，該解決方案必須能夠支持熱插拔，以便能夠與你現(xiàn)有的dashboard、告警和腳本一起使用。例如，許多使用Prometheus的企業(yè)都將Grafana用于dashboard。這個開源工具能夠與Prometheus很好地集成在一起，包括在查詢級別，并且可以用于生成一系列有用的圖表和dashboard。因此，聲稱與Prometheus兼容的商業(yè)產(chǎn)品應與Grafana等工具兼容。僅僅說解決方案可以讓你在Grafana中查看數(shù)字是遠遠不夠的，你需要能夠按照原樣提取現(xiàn)有的Grafana dashboard，并將它們重新應用于商業(yè)解決方案中已安裝的數(shù)據(jù)。

4、 訪問控制

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

5、 故障排查

Kubernetes簡化了部署、彈性伸縮和管理容器化應用程序和微服務。這有助于保持服務的正常運行，但是要識別和解決諸如性能降低、部署失敗和連接錯誤之類的根本問題，你需要能夠從整個環(huán)境中收集和可視化基礎架構、應用程序和性能數(shù)據(jù)。由于無法同時訪問實時信息和上下文數(shù)據(jù)，因此幾乎不可能關聯(lián)環(huán)境中的指標，所以你可以更快地解決問題。

6、 與現(xiàn)有告警兼容

最后，如果你正在尋找商業(yè)解決方案來幫助解決Prometheus可擴展性問題，請確保它支持所有級別的告警。能夠?qū)崿F(xiàn)這一目標的關鍵是全面支持Alert Manager功能，而Alert Manager還要求100%的集成和 PromQL兼容性。

如果你找到一個能夠滿足以上標準的商業(yè)化工具，你應該能夠輕松將其集成到現(xiàn)有的Prometheus中，并且能夠避免公司遇到的可擴展性問題。開發(fā)人員有充分的理由喜愛Prometheus，因此在采用商業(yè)化方案之前進行全面、盡職的調(diào)查將確保他們?nèi)匀豢梢允褂米约合矚g的指標。

以上是“搭建Prometheus平臺需要考慮哪些因素”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關知識，歡迎關注億速云行業(yè)資訊頻道！