搭建Prometheus平台,你必須考慮的6個因素_網頁設計

1{icon} {views}

※推薦評價好的iphone維修中心

擁有專業的維修技術團隊,同時聘請資深iphone手機維修專家,現場說明手機問題,快速修理,沒修好不收錢

作者簡介

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,因此在採用商業化方案之前進行全面、盡職的調查將確保他們仍然可以使用自己喜歡的指標。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

網頁設計最專業,超強功能平台可客製化

窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸,為每一位客戶客製建立行銷脈絡及洞燭市場先機。