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

做者簡介

Loris Degioanni，Sysdig的創始人和CTO，同時仍是容器安全工具Falco的建立者。

原文連接
https://thenewstack.io/6-things-to-consider-in-a-prometheus-monitoring-platform/

本文轉自Rancher Labs

當前，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，須要堅持如下標準：

一、 兼容性，以支持全部Prometheus功能

你的供應商/所使用的工具/SaaS解決方案須要可以使用任何可產生Prometheus指標的實體程序中消耗數據，不管是本地Kubernetes仍是雲服務。相對來講，消耗Prometheus指標微不足道，可是也不要忽略一些小事情，例如將指標提取到存儲中或增長數據時可以從新標註指標，這樣對你的環境更有意義。這些小事加起來，可以收集到的數據將會堆積如山、大不相同。

二、 PromQL兼容性

Prometheus查詢語言由Prometheus建立者發明，用於提取存儲在Prometheus中的信息。PromQL能讓你查詢指定服務或指定用戶的指標，它還能彙總或細分數據。例如，你可使用它顯示全部容器中每一個應用的CPU使用率。或者僅顯示Cassandra容器的數據，並將其顯示爲每一個集羣的單個值。能夠說，PromQL釋放了Prometheus的真正價值，所以若是將Prometheus的指標集成到一個不徹底支持PromQL的產品中，就徹底違背了使用Prometheus的初衷。

三、 支持熱插拔

要真正與Prometheus兼容，該解決方案必須可以支持熱插拔，以便可以與你現有的dashboard、告警和腳本一塊兒使用。例如，許多使用Prometheus的企業都將Grafana用於dashboard。這個開源工具可以與Prometheus很好地集成在一塊兒，包括在查詢級別，而且能夠用於生成一系列有用的圖表和dashboard。所以，聲稱與Prometheus兼容的商業產品應與Grafana等工具兼容。僅僅說解決方案可讓你在Grafana中查看數字是遠遠不夠的，你須要可以按照原樣提取現有的Grafana dashboard，並將它們從新應用於商業解決方案中已安裝的數據。

四、 訪問控制

在評估工具時，訪問控制是另外一個你須要考慮的安全問題。可以使用行業標準協議（包括LDAP、Google Oauth、SAML和OpenID）保護用戶身份驗證，使公司可以經過基於服務的訪問控制來隔離和保護資源。

五、 故障排查

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

六、 與現有告警兼容

最後，若是你正在尋找商業解決方案來幫助解決Prometheus可擴展性問題，請確保它支持全部級別的告警。可以實現這一目標的關鍵是全面支持Alert Manager功能，而Alert Manager還要求100%的集成和 PromQL兼容性。

若是你找到一個可以知足以上標準的商業化工具，你應該可以輕鬆將其集成到現有的Prometheus中，而且可以避免公司遇到的可擴展性問題。開發人員有充分的理由喜好Prometheus，所以在採用商業化方案以前進行全面、盡職的調查將確保他們仍然可使用本身喜歡的指標。