原文發表于kubernetes中文社區，為作者原創翻譯 ，原文地址
更多kubernetes文章，請多關注kubernetes中文社區
目錄
挑戰1：手動配置應用程式
解決方案：利用GitOps保持控制
挑戰2：手動創建組態檔和儀表盤
解決方案：代碼生成器
挑戰3：配置同步
解決方案：使用抽象方法來實作重用，并保持生成的檔案同步
可觀察性，對于在Kubernetes集群中運行大量的作業負載至關重要，Prometheus是一個監視系統和時間序列資料庫，已經被廣泛證明其擅長于管理大規模，動態的Kubernetes環境，實際上，Prometheus被認為是在Kubernetes上運行應用程式的基礎構建塊，并已成為在Kubernetes環境中進行可見性和監視的事實上標準，
盡管Prometheus是開源的，但它并不免費提供監視Kubernetes作業負載所需的配置，
注意：在本文中，我不會討論Prometheus和多集群高可用性設定所面臨的挑戰，相反，我專注于如何將Prometheus擴展到更多的應用程式并為每個應用程式創建儀表板，以便更多的人可以使用它，如果你對高可用性設定感興趣，可以參考諸如Thanos或VictoriaMetrics之類的專案，
要開始使用Prometheus，你可以配置 scraping 以從服務中提取指標，使用Grafana構建儀表板，并為生產環境中超出閾值的重要指標定義警報（請參見下圖），
一旦你選擇了Prometheus，第一個挑戰就是為整個應用程式和環境擴展和管理Prometheus，
挑戰1：手動配置應用程式
現代軟體的作業負載通常由成百上千個微服務組成，它們既是同一應用程式的多個實體，又是彼此通信的不同的較小應用程式，它們都是由Kubernetes精心組織的，這些作業負載不是在單個集群或單個環境中運行，而是分布在多個集群和環境（例如開發，測驗和生產）中，
例如，截至2019年底，Uber的作業量已增長到4,000多個微服務，要管理和操作此類復雜的應用程式，你需要高級可觀察性，這需要針對每個應用程式進行抓取，儀表板和警報的專用配置，你不僅要必須創建這些配置，而且還必須將它們應用到每種環境，而且，每次發生更改時常常以手動方式完成，
問題：這全都意味著，要管理Prometheus和Grafana生態系統中的配置，需要付出的巨大人工，
解決方案：利用GitOps保持控制
你可以采用“ GitOps”方法，而不是臨時應用配置，其中Git存盤庫保存所有配置以及檔案和代碼，并且operator 組件自動將其應用于要管理的系統-例如Prometheus，Grafana ，甚至Kubernetes集群，
不直接對Prometheus配置或Grafana儀表盤進行任何更改，而是必須將所有更改首先提交給Git存盤庫，然后將其同步到Prometheus，Grafana或其他工具，
GitOps方法的眾多好處之一就是能夠對所有配置進行版本控制，以識別何時以及為何發生每項更改，對于有問題的更改，你可以輕松地將其回滾，使用這種方法，你還可以使用 pull requests 的概念來提升配置，
下圖顯示了一個Git存盤庫和operator 來管理所有組態檔，operator 必須擁有將配置底層系統的邏輯和權限，
手動應用的配置與GitOps方法的對比
挑戰2：手動創建組態檔和儀表盤
第一步，設定受版本控制，并保存所有配置到GitOps是第一步，但是仍然有很多手動配置需要處理，
學習Prometheus中的PromQL查詢不是一件容易的事，除了PromQL，你還需要Grafana儀表板配置（以JSON格式撰寫）以全面了解你的應用程式，你還需要Prometheus中的警報規則（用Yaml格式撰寫）來設定故障警報，
問題：你需要一支由不同配置語言組成的工程師團隊，來撰寫和維護所有手動配置，
解決方案：代碼生成器
代碼生成器可以解救！你可以使用代碼生成器來減輕手動作業，而不必手動為Prometheus、警報管理器，以及為Grafana儀表板撰寫配置，
一個很好的例子是根據SRE概念生成的Prometheus警報和記錄規則，例如 Golden Signals 或RED方法，甚至USE方法，它們被廣泛認為是最有用和最關鍵的指標，另一個示例是生成Grafana儀表板（例如，請參見GitHub網站上的uber / grafana-dash-gen，metalmatze / slo-libsonnet和prometheus-operator / kube-prometheus，以及Grafana Labs網站上的Scripted Dashboards），
使用代碼生成器可以加快配置作業，生成的檔案存盤在Git存盤庫中，以獲取我之前討論的所有好處，
下圖將手動配置與代碼生成的配置進行了比較，并顯示了后一種方法如何完成繁重的作業并減少用戶出錯，
手動撰寫配置與使用代碼生成器
挑戰3：配置同步
一旦開始使用代碼生成器，最終將獲得大量自動生成的組態檔，存盤在Git存盤庫中的那些配置彼此獨立，沒有控制機制保證它們基于相同的輸入檔案，實際上，這甚至是不可能的，因為代碼生成器可能依賴于不同種類的輸入，
例如：更改代碼生成器1的輸入引數所輸出的結果，與代碼生成器2或3的輸出不同步，這就導致了，生成的檔案之間沒有同步機制，
只有少數解決方案可以解決此問題，例如prometheus-operator / kube-prometheus，
問題：需要人工操作才能將每種輸入進行的更改，創建成為新一代版本的組態檔，
解決方案：使用抽象方法來實作重用，并保持生成的檔案同步
軟體工程中的抽象方法實作了重用，可以幫助克服組態檔不同步的挑戰，引入具備SRE( Site Reliability Engineering ，網站可靠性工程 )概念的中間語言可以幫助提供技識訓礎，
下圖顯示了如何引入諸如jsonnet或其他中間語言，使你可以定義通用概念并為Prometheus和Grafana等不同平臺生成特定的組態檔，使用這種高級編程語言，你可以抽象實作細節，但你使用的語言必須提供Prometheus監視域中普遍存在的所有概念，
一個成熟的SRE概念是基于服務級別目標（SLO）的概念，該概念允許你為每個微服務定義目標，使用機器和人類可讀的代碼（如Yaml檔案）中，可以為多個工具生成配置，并使所有配置符合定義的服務級別目標，這降低了復雜性，使你可以更輕松地應對Prometheus環境的操作和擴展，
將沒有抽象的方法與基于SRE概念的抽象的新方法進行比較
譯文鏈接：https://thenewstack.io/3-key-configuration-challenges-for-kubernetes-monitoring-with-prometheus/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/190576.html
標籤：其他