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

容器使情況復雜化

監(jiān)控整體環(huán)境過去相對簡單，企業(yè)具有一定數(shù)量的靜態(tài)物理服務器和虛擬機，以及數(shù)量有限的指標。現(xiàn)在由于容器以及向微服務架構的遷移，要跟蹤的實體數(shù)量激增。

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

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

Prometheus

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

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

規(guī)模問題

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

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

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

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

要考慮的六個因素

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

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

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

2. PromQL兼容性

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

3. 熱插拔

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

4. 訪問控制

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

5. 故障排除

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

6. 現(xiàn)有警報的兼容性

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