部署普羅米修斯(Prometheus)監(jiān)控平臺(tái)前需考慮的六大因素

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

容器使情況復(fù)雜化

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

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

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

Prometheus

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

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

規(guī)模問題

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

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

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

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

要考慮的六個(gè)因素

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

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

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

2. PromQL兼容性

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

3. 熱插拔

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

4. 訪問控制

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

5. 故障排除

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

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

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