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

容器使情況復雜化

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

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

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

Prometheus

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

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

規模問題

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

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

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

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

要考慮的六個因素

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

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

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

2. PromQL兼容性

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

3. 熱插拔

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

4. 訪問控制

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

5. 故障排除

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

6. 現有警報的兼容性

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