部署Prometheus監控平臺，6個不可少的因素

企業在採用容器的同時，也將容器的監控問題放在了比較優先的位置上，不少企業使用普羅米修斯(Prometheus)監控容器和微服務，對於規模企業通常會更加激進，所以當他們規模部署時將面臨擴充套件的挑戰。

容器使情況複雜化

監控整體環境過去相對簡單，企業具有一定數量的靜態物理伺服器和虛擬機器，以及數量有限的指標。現在由於容器以及向微服務架構的遷移，要跟蹤的實體數量激增。

容器的數量不斷增加，有時每臺機器上有數百臺，而新的機器也在增加，並且與Kubernetes等編排工具一起使用時，使得容器的壽命可能非常短，使得跟蹤它們變得更加困難，並且如果不小心的話，它們可能會造成很多問題。

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

當需要進行雲監控時，IT團隊越來越多地傾向於Prometheus，它是由雲原生計算基金會開源的專案。Prometheus已成為開發人員在雲原生環境中收集和理解指標的首選監控工具。它由一個大型社群支援，有超過700多家企業貢獻者。

預設情況下，典型的雲原生應用程式堆疊(例如Kubernetes，Ngnix，MongoDB，Kafka和golang)會公開Prometheus指標。Prometheus被設計為可垂直縮放的Go程式。例如，將其輕鬆部署為單個容器或單個主機。這意味著從Prometheus入門很容易就能瞭解你的Kubernetes叢集。但這也意味著隨著基礎架構的增長，監控規模也面臨極限的挑戰。

隨著環境的發展，需要跟蹤的時間序列資料數量激增，在某個特定點上，單個Prometheus例項將無法跟上。直接的選擇是在整個企業中執行一批Prometheus伺服器，但這也帶來了一些挑戰。例如，管理和聯合數十或數百個Prometheus伺服器上的資料並不容易。類似地，確定企業工作流、單點登入、基於角色的訪問控制以及遵守SLA或遵從性也不是容易的問題。隨著應用程式的增長，在不中斷開發人員工作的情況下操作一個包羅永珍的監控解決方案將成為一個巨大的可管理性和可靠性問題。

為了解決這個問題，企業採用了一些方法。

簡單的第一步是為每個名稱空間或每個叢集使用單獨的Prometheus伺服器。這種方法顯然很難擴充套件到某個特定的點，除此之外，它還有建立大量斷開連線的資料孤島的缺點。這使得故障排除變得很麻煩，因為大多數問題將跨越多個服務/團隊/叢集。不僅很難在每個環境中找到相同的度量標準，而且還必須將資料結合起來，試圖理解正在發生的事情。

另一種常見的方法是使用如Cortex或thanos等開源工具來聯合多個Prometheus伺服器。它們是功能強大的工具，能夠以集中的方式查詢伺服器，收集資料，然後在單個儀表板共享資料。然而，與任何資料密集型分散式系統一樣，它們需要大量的技能和資源來操作。

對於那些從Prometheus開始，然後尋找商業解決方案來提供整體監控的企業來說，重要的是不要失去所有在Prometheus標準化的開發工作，如儀表盤、警報等工作。然而，這不是你應該考慮的唯一，下面的這些因素或許對你有幫助。

企業選擇的雲供應商、工具或SaaS解決方案需要能夠使用任何可產生Prometheus指標的資料，無論是本地Kubernetes還是任何的雲服務。Prometheus指標相對來說比較瑣碎，但不要忽略一些小事情，例如將指標提取到儲存中或擴充資料時能夠重新標註指標，這樣對環境更加有意義。這些事情疊加，在使用大量收集的資料方面會產生很大的不同。

Prometheus查詢語言用於提取Prometheus儲存的資訊。PromQL能夠詢問有關指標，例如特定服務或特定使用者。它還允許聚合或分段資料，例如可以使用它在應用程式基礎上顯示所有容器的CPU利用率，或者僅顯示Cassandra容器的資料，並將其顯示為每個叢集的單個值。所以，PromQL解鎖了Prometheus的真正價值;因此，在不完全支援PromQL的產品中加入Prometheus度量標準會破壞使用Prometheus的目的。

要真正與Prometheus相容，解決方案必須是可熱插拔的，以便能夠與現有的儀表板、警報和 一起工作。例如，許多使用Prometheus的企業使用Grafana作為儀表盤。這個開源工具與Prometheus很好地整合在一起，包括在查詢級別，並且可以用於生成一系列有用的圖表和指示板。因此，那些聲稱與Prometheus相容的商業產品應該與Grafana這樣的工具相容。僅僅說解決方案可以在Grafana中檢視數字是不夠的。需要能夠按原樣提取現有的Grafana儀表板，並將它們重新應用於商業解決方案中的資料。

訪問控制是評估工具時應該考慮的另一個安全問題。透過使用行業標準協議(包括LDAP、谷歌Oauth、SAML和OpenID)來確保使用者身份驗證的安全，企業能夠透過基於服務的訪問控制來隔離和保護資源。

Kubernetes簡化了容器化應用程式和微服務的部署、伸縮和管理。這有助於保持服務的正常執行，但是要識別和解決底層問題，比如效能下降、失敗的部署和連線錯誤，需要能夠收集和視覺化來自生產環境的深入基礎設施、應用程式和效能資料。不能同時訪問實時資訊和上下文資料，就幾乎不可能在環境中關聯度量，從而更快地解決問題。

最後，如果你正在尋找一個商業答案來幫助解決Prometheus可伸縮性問題，請確保它支援所有級別的警報。實現這一點的關鍵是完全支援警報管理器功能，這反過來需要100%的和PromQL相容性。

原文地址：