作者簡介
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，需要堅持以下標準：
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，因此在採用商業化方案之前進行全面、盡職的調查將確保他們仍然可以使用自己喜歡的指標。