如何構(gòu)建萬級Kubernetes集群場景下的etcd監(jiān)控平臺

本篇文章給大家分享的是有關(guān)如何構(gòu)建萬級Kubernetes集群場景下的etcd監(jiān)控平臺，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

背景

隨著 Kubernetes 成為容器編排領(lǐng)域的霸主，越來越多的業(yè)務(wù)大規(guī)模在生產(chǎn)環(huán)境使用 Kubernetes 來部署、管理服務(wù)。騰訊云TKE正是基于原生 Kubernetes，提供以容器為核心的、高度可擴(kuò)展的高性能容器管理服務(wù)，自從2017年推出后，隨著 Kubernetes 的火熱，我們的集群規(guī)模也增長到萬級，在這過程中我們的各基礎(chǔ)組件，尤其是etcd面臨了以下挑戰(zhàn)：

• 如何通過一套監(jiān)控系統(tǒng)，采集萬級的TKE集群的etcd等組件 metrics 監(jiān)控?cái)?shù)據(jù)?

• 如何高效治理萬級集群、主動(dòng)發(fā)現(xiàn)故障及潛在隱患？

• 如何快速感知異常，實(shí)現(xiàn)快速處置、乃至自愈？

為了解決以上挑戰(zhàn)，我們基于 Kubernetes 的擴(kuò)展機(jī)制，實(shí)現(xiàn)了一套含etcd集群管理、調(diào)度、遷移、監(jiān)控、備份、巡檢于一體的可視化的etcd平臺，本篇文章重點(diǎn)和你分享的是我們etcd監(jiān)控平臺是如何解決以上挑戰(zhàn)的。

面對大規(guī)模監(jiān)控?cái)?shù)據(jù)采集問題，我們的解決方案從TKE誕生之初的單 Prometheu 實(shí)例、到基于 Promethes-Operator動(dòng)態(tài)構(gòu)建多 Prometheus 實(shí)例、添加監(jiān)控 Target, 再到基于 TKE云原生 Prometheus 產(chǎn)品實(shí)現(xiàn)水平可擴(kuò)展的監(jiān)控系統(tǒng)，成功為萬級 Kubernetes 集群提供穩(wěn)定的 etcd 存儲(chǔ)服務(wù)和監(jiān)控能力，etcd 監(jiān)控平臺治理的 Kubernetes 集群數(shù)也實(shí)現(xiàn)了從個(gè)位數(shù)、到千級、萬級的突破。目前數(shù)據(jù)規(guī)模上，單位時(shí)間內(nèi) Prometheus Target 高達(dá)數(shù)萬個(gè)，單地域指標(biāo)數(shù)據(jù)量 Series 千萬級，面對大規(guī)模監(jiān)控?cái)?shù)據(jù)，監(jiān)控?cái)?shù)據(jù)可用性仍能保持在99.99%以上。

面對復(fù)雜分布式環(huán)境中，各種可能出現(xiàn)的不可控人為操作失誤、硬件、軟件故障，我們基于 Kubernetes 擴(kuò)展機(jī)制、豐富 的etcd 知識與經(jīng)驗(yàn)積累構(gòu)建了多維度、可擴(kuò)展的的巡檢系統(tǒng)，幫助我們高效治理萬級集群、主動(dòng)發(fā)現(xiàn)潛在隱患。

面對監(jiān)控?cái)?shù)據(jù)龐大，告警泛濫，我們基于高可用的監(jiān)控?cái)?shù)據(jù)，結(jié)合運(yùn)營場景，建立標(biāo)準(zhǔn)化的數(shù)據(jù)運(yùn)營體系，大幅減少無效告警，提高告警準(zhǔn)確性，并進(jìn)一步引入多維度的SLO，收斂告警指標(biāo)，為業(yè)務(wù)方提供直觀的服務(wù)水平指標(biāo)。通過標(biāo)準(zhǔn)化的數(shù)據(jù)運(yùn)營體系、告警分類、告警跟進(jìn)、上升機(jī)制、簡單場景的自愈策略等，實(shí)現(xiàn)故障快速處置、乃至自愈。

下面，我們就和你詳細(xì)介紹下，我們是如何解決以上三個(gè)挑戰(zhàn)，快速構(gòu)建可擴(kuò)展的業(yè)務(wù)監(jiān)控系統(tǒng)。

如何構(gòu)建高可用，可擴(kuò)展的監(jiān)控?cái)?shù)據(jù)采集服務(wù)？

首先是第一個(gè)問題，如何通過一套監(jiān)控系統(tǒng)，采集萬級的TKE集群的etcd組件 metrics 監(jiān)控?cái)?shù)據(jù)？

大家都知道，etcd是一個(gè)開源的分布式 key-value 存儲(chǔ)系統(tǒng)，它是 Kubernetes 的元數(shù)據(jù)存儲(chǔ)，etcd的不穩(wěn)定會(huì)直接導(dǎo)致上層服務(wù)不可用，因此etcd的監(jiān)控至關(guān)重要。

2017年，TKE誕生之初，集群少，因此一個(gè)單 Prometheu 實(shí)例就可以搞定監(jiān)控問題了。

2018年，Kubernetes 越來越被大家認(rèn)可，我們的 TKE 集群數(shù)也越來越多，因此我們引入了 Promtheus-Operator 來實(shí)現(xiàn)動(dòng)態(tài)管理 Prometheus 實(shí)例、通過多 Prometheus 實(shí)例，我們基本扛住了數(shù)千的 Kubernetes 集群監(jiān)控需求，下面是其架構(gòu)圖。

Prometheus-Operator架構(gòu)

我們在每個(gè)地區(qū)部署了 Prometheus-Operator, 針對不同業(yè)務(wù)類型創(chuàng)建了不同的 Prometheus 實(shí)例，每新增一個(gè) Kubernetes/etcd 集群的時(shí)候，我們會(huì)通過 API 創(chuàng)建 ServiceMonitor 資源，告知 Prometheus 采集新集群監(jiān)控?cái)?shù)據(jù)。

然而在這套方案中，隨著 Kubernetes/etcd 集群越來越多，etcd監(jiān)控告警的穩(wěn)定性受到挑戰(zhàn)，監(jiān)控鏈路不穩(wěn)定，監(jiān)控曲線出現(xiàn)斷點(diǎn)，告警泛濫，虛告警多，難以跟進(jìn)。

痛點(diǎn)問題

具體有哪些問題呢？

這里我們從監(jiān)控不穩(wěn)定和運(yùn)維成本兩個(gè)角度和你分析下。

監(jiān)控不穩(wěn)定

監(jiān)控組件不穩(wěn)定：過大的監(jiān)控?cái)?shù)據(jù)經(jīng)常會(huì)造成 Prometheus 實(shí)例出現(xiàn)OOM，同時(shí)由于納管etcd過程中會(huì)對 Prometheus 實(shí)例進(jìn)行變更，頻繁的變更會(huì)觸發(fā) Prometheus 的卡死。

監(jiān)控與業(yè)務(wù)耦合：為避免數(shù)據(jù)量過大造成OOM，需要人工拆分Prometheus實(shí)現(xiàn)數(shù)據(jù)分片，這樣不僅增加維護(hù)成本，同時(shí)由于存在自動(dòng)納管的機(jī)制，納管機(jī)制與人工分片強(qiáng)耦合，不利于后期運(yùn)營和功能拓展。

監(jiān)控鏈路不穩(wěn)定：監(jiān)控鏈路主要由 Prometheus-Operator 和 Top-Prometheus 構(gòu)成，由于與其他業(yè)務(wù)共享 Top-Prometheus，Top-Prometheus 面臨大量數(shù)據(jù)，時(shí)常會(huì)出現(xiàn)OOM重啟，同時(shí)由于本地盤存儲(chǔ)數(shù)據(jù)量大，啟動(dòng)加載慢，重啟耗時(shí)長，進(jìn)一步擴(kuò)大了影響，經(jīng)常會(huì)造成較長時(shí)間的數(shù)據(jù)斷點(diǎn)。

運(yùn)維成本

監(jiān)控組件需要自維護(hù)：監(jiān)控?cái)?shù)據(jù)分片需要人工拆分監(jiān)控實(shí)例，監(jiān)控組件需要自運(yùn)維?；?，確保監(jiān)控可用性。

告警規(guī)則維護(hù)難度大：告警規(guī)則大量依賴對 etcd 名稱的正則匹配，規(guī)則維護(hù)難度大，對于新增告警規(guī)則的場景，需要了解現(xiàn)有的規(guī)則配置情況，在添加新規(guī)則前需對現(xiàn)有規(guī)則增加特定 etcd 集群的反選邏輯，新增操作時(shí)常會(huì)出現(xiàn)影響現(xiàn)有告警的情況。

告警難跟進(jìn)：指標(biāo)繁多，告警量大，無法準(zhǔn)確反映業(yè)務(wù)問題，告警指標(biāo)不具備業(yè)務(wù)特性，業(yè)務(wù)難以直接理解，無法將告警信息直接返回業(yè)務(wù)方，告警跟進(jìn)難度大。

另外基于開源的 Prometheus，在添加監(jiān)控 Target 時(shí)，會(huì)導(dǎo)致 Prometheus 異常，服務(wù)重啟，出現(xiàn)數(shù)據(jù)斷點(diǎn)，同時(shí)由于監(jiān)控?cái)?shù)據(jù)量大導(dǎo)致經(jīng)常OOM，監(jiān)控服務(wù)可用性較低。

問題分析

如上圖所示，監(jiān)控服務(wù)主要由下層 Prometheus Server 和上層 Top-Prometheus 組成。

變更為什么會(huì)卡死？

如上圖所示，Secret 資源由etcd 集群產(chǎn)生，Prometheus-Operator 會(huì)根據(jù) Secret，Prometheus CRD和ServiceMonitor生成 Prometheus 實(shí)例的 static_config 文件，Prometheus 實(shí)例最終依賴 config 文件實(shí)現(xiàn)數(shù)據(jù)的拉取。

etcd增加 => Secret增多，Prometheus CRD更新 => static_config更新頻繁 => Prometheus 的拉取配置頻繁變動(dòng)導(dǎo)致 Prometheus 無法正常工作。

容量問題從何而來？

在TKE集群不斷增長和產(chǎn)品化 etcd 上線的背景下，etcd 數(shù)目不斷增加，etcd 自身指標(biāo)量大，同時(shí)為了高效治理集群，提前發(fā)現(xiàn)各種隱患，引入巡檢策略，指標(biāo)數(shù)據(jù)量高達(dá)數(shù)百萬。

Top-Prometheus 除采集 etcd 指標(biāo)外，還需要采集其他支撐服務(wù)，因此，Top-Prometheus 經(jīng)常出現(xiàn) OOM 導(dǎo)致監(jiān)控服務(wù)不可用。

可拓展 Prometheus 架構(gòu)

如何解決以上痛點(diǎn)呢？

TKE團(tuán)隊(duì)推出的云原生 Prometheus 正是為了解決大規(guī)模數(shù)據(jù)場景下的痛點(diǎn)而誕生的，為了解決以上痛點(diǎn)，保證數(shù)據(jù)標(biāo)準(zhǔn)化運(yùn)營底座的穩(wěn)定性，提供高可用的監(jiān)控服務(wù)，我們決定將 etcd 監(jiān)控平臺全面遷移到TKE云原生 Prometheus 進(jìn)行監(jiān)控系統(tǒng)中。

TKE云原生Prometheus監(jiān)控引入 file-sync 服務(wù)實(shí)現(xiàn)配置文件的的熱更新，避免變更導(dǎo)致 Prometheus 重啟，成功解決了我們核心場景過程中的痛點(diǎn)。

同時(shí)TKE云原生Prometheus通過Kvass實(shí)現(xiàn)對監(jiān)控?cái)?shù)據(jù)彈性分片，有效分流大量數(shù)據(jù)，實(shí)現(xiàn)千萬級數(shù)據(jù)的穩(wěn)定采集。

最重要的是，Kvass 項(xiàng)目已開源，下面是其架構(gòu)圖，更多可參考文《如何用Prometheus監(jiān)控十萬container的Kubernetes集群》和GitHub源碼。

云原生可拓展 Prometheus 架構(gòu)

上圖是我們基于可擴(kuò)展的TKE云原生 Prometheus 架構(gòu)圖，下面我簡單為你介紹下各個(gè)組件。

中心化 Thanos 引入

Thanos主要由兩個(gè)服務(wù)構(gòu)成：thanos-query 和 thanos-rule。thanos-query 實(shí)現(xiàn)對監(jiān)控?cái)?shù)據(jù)的查詢，thanos-rule 對監(jiān)控?cái)?shù)據(jù)進(jìn)行聚合實(shí)現(xiàn)告警。

thanos-query：thanos-query 通過配置 store 字段可實(shí)現(xiàn)多個(gè) Prometheus 數(shù)據(jù)查詢?nèi)蝿?wù)，利用查詢能力實(shí)現(xiàn) TKE 云原生 Prometheus 或原有 Prometheus 的數(shù)據(jù)聚合，同時(shí)也為上層監(jiān)控大盤和告警提供統(tǒng)一的數(shù)據(jù)源，起到收斂數(shù)據(jù)查詢?nèi)肟诘淖饔谩?/p>

thanos-rule：thanos-rule 依賴 query 采集的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行聚合，并根據(jù)配置的告警規(guī)則實(shí)現(xiàn)告警，告警能力的收斂和中心化的告警配置使得下層 Prometheus 服務(wù)無論如何變動(dòng)，告警鏈路的穩(wěn)定性都得以保證。

平滑遷移

TKE云原生 Prometheus 完全兼容開源的 Prometheus-Operator 方案，因此在遷移過程，原有 Prometheus-Operator 相關(guān)配置可以全部保留，僅需要添加對應(yīng)標(biāo)簽便于TKE云原生 Prometheus 識別即可。但是由于指標(biāo)暴露由集群內(nèi)遷移至外部TKE云原生 Prometheus，對集群內(nèi)外依賴監(jiān)控指標(biāo)的服務(wù)有所影響。

對外暴露：通過引入中心化 thanos-query，各個(gè)地域指標(biāo)均通過 thanos-query 對外暴露，憑借上層中心化的 query，底層遷移TKE云原生 Prometheus 或者對其進(jìn)行平行拓展，對于依賴監(jiān)控指標(biāo)的外部服務(wù)如監(jiān)控大盤和告警等均無感知。

內(nèi)部依賴：集群內(nèi) custom-metrics 服務(wù)依賴監(jiān)控指標(biāo)，由于采用 TKE 云原生 Prometheus，指標(biāo)無法再依賴內(nèi)部Service 采集，為此，在云原生 Prometheus 所在集群創(chuàng)建對應(yīng)的內(nèi)網(wǎng)LB，使得可被支撐環(huán)境內(nèi)部訪問，通過內(nèi)網(wǎng) LB 對 custom-metrics 進(jìn)行配置，從而實(shí)現(xiàn)監(jiān)控指標(biāo)的采集。

TKE云原生 Prometheus 效果

監(jiān)控可用性：TKE 云原生 Prometheus 基于 Prometheus 對外暴露指標(biāo)以衡量自身監(jiān)控服務(wù)的可用性，常用指標(biāo)有 prometheus_tsdb_head_series 和 up 等，prometheus_tsdb_head_series 用于衡量采集總體監(jiān)控?cái)?shù)據(jù)量，up 指標(biāo)反應(yīng)采集任務(wù)是否健康，通過這兩個(gè)指標(biāo)能夠?qū)ΡO(jiān)控服務(wù)可用性有整體的感知。

數(shù)據(jù)采集成功率：作為業(yè)務(wù)側(cè)，我們更關(guān)心具體業(yè)務(wù)指標(biāo)采集的成功率，為有效衡量可用性，對業(yè)務(wù)指標(biāo)進(jìn)行采樣落地?cái)?shù)據(jù)化。以15s為間隔分別采集遷移前后的數(shù)據(jù)，結(jié)合理論數(shù)據(jù)量判斷數(shù)據(jù)掉點(diǎn)率，以此反映監(jiān)控服務(wù)可用性。經(jīng)過統(tǒng)計(jì)，具體近30天數(shù)據(jù)如下圖所示：

引入 TKE 云原生 Prometheus 后，監(jiān)控?cái)?shù)據(jù)總量一直高達(dá)數(shù)千萬，監(jiān)控告警鏈路穩(wěn)定，巡檢數(shù)據(jù)覆蓋率在70%以上，由于對 etcd 服務(wù)平臺進(jìn)行過改造造成成功率在短時(shí)間內(nèi)所波動(dòng)，除此外，監(jiān)控指標(biāo)拉取成功率均在99.99%以上，近7天數(shù)據(jù)保持在100%，監(jiān)控服務(wù)保持著高可用性。

如何高效治理etcd集群，提前發(fā)現(xiàn)隱患？

其次是第二個(gè)問題，如何高效治理萬級集群、主動(dòng)發(fā)現(xiàn)故障及潛在隱患？

在第一個(gè)問題中，我們已經(jīng)解決了大規(guī)模 etcd 集群的 metrics 采集問題，通過 metrics 我們可以發(fā)現(xiàn)部分隱患，但是它還不夠滿足我們高效治理 etcd 集群的訴求。

為什么這樣說呢？

痛點(diǎn)問題

在大規(guī)模使用 etcd 過程中，我們可能會(huì)遇到各種各樣的隱患和問題，比如常見如下：

• etcd集群因重啟進(jìn)程、節(jié)點(diǎn)等出現(xiàn)數(shù)據(jù)不一致

• 業(yè)務(wù)寫入大 key-value 導(dǎo)致 etcd 性能驟降

• 業(yè)務(wù)異常寫入大量key數(shù)，穩(wěn)定性存在隱患

• 業(yè)務(wù)少數(shù) key 出現(xiàn)寫入 QPS 異常，導(dǎo)致 etcd 集群出現(xiàn)限速等錯(cuò)誤

• 重啟、升級 etcd 后，需要人工從多維度檢查集群健康度

• 變更 etcd 集群過程中，操作失誤可能會(huì)導(dǎo)致 etcd 集群出現(xiàn)分裂

• ......

因此為了實(shí)現(xiàn)高效治理etcd集群，我們將這些潛在隱患總結(jié)成一個(gè)個(gè)自動(dòng)化檢查項(xiàng)，比如：

• 如何高效監(jiān)控 etcd 數(shù)據(jù)不一致性？

• 如何及時(shí)發(fā)現(xiàn)大 key-value?

• 如何及時(shí)通過監(jiān)控發(fā)現(xiàn) key 數(shù)異常增長？

• 如何及時(shí)監(jiān)控異常寫入 QPS?

• 如何從多維度的對集群進(jìn)行自動(dòng)化的健康檢測，更安心變更？

• ......

如何將這些 etcd 的最佳實(shí)踐策略反哺到現(xiàn)網(wǎng)大規(guī)模 etcd 集群的治理中去呢？

答案就是巡檢。

我們基于 Kubernetes 擴(kuò)展機(jī)制、豐富的 etcd 知識與經(jīng)驗(yàn)積累構(gòu)建了多維度、可擴(kuò)展的的巡檢系統(tǒng)，幫助我們高效治理萬級集群、主動(dòng)發(fā)現(xiàn)潛在隱患。

為什么我們基于 Kubernetes 擴(kuò)展機(jī)制構(gòu)建 etcd 平臺呢？

etcd云原生平臺介紹

為了解決我們業(yè)務(wù)中一系列痛點(diǎn)，我們 etcd 云原生平臺設(shè)計(jì)目標(biāo)如下：

• 可觀測性。集群創(chuàng)建、遷移流程支持可視化，隨時(shí)可查看當(dāng)前進(jìn)展，支持暫停、回滾、灰度、批量等。

• 高開發(fā)效率。充分復(fù)用社區(qū)已有基礎(chǔ)設(shè)施組件和平臺，聚焦業(yè)務(wù)，快速迭代，高效開發(fā)。

• 高可用。 各組件無單點(diǎn)，可平行擴(kuò)容，遷移模塊通過分布式鎖搶占任務(wù)，可并發(fā)遷移。

• 可擴(kuò)展性。遷移對象、遷移算法、集群管理、調(diào)度策略、巡檢策略等抽像化、插件化，以支持多種 Kubernetes 集群類型、多種遷移算法、多種集群類型（CVM/容器等）、多種遷移策略、多種 Kubernetes 版本、多種巡檢策略。

回顧我們設(shè)計(jì)目標(biāo)，可觀測性、高開發(fā)效率跟 Kubernetes 和其聲明式編程特別匹配，詳情如下。

• 可觀測性?；?Event 做遷移實(shí)時(shí)進(jìn)展功能，通過 kubectl、可視化的容器控制臺都可以查看、啟動(dòng)、暫停各類任務(wù)

• 高開發(fā)效率。Kubernetes中REST API設(shè)計(jì)優(yōu)雅，定義自定義 API 后，SDK 全自動(dòng)生成，大大減少了開發(fā)工作量，可專注業(yè)務(wù)領(lǐng)域系統(tǒng)開發(fā)，同時(shí)自動(dòng)化監(jiān)控、備份模塊可以基于 Kubernetes 社區(qū)已有的組件，進(jìn)行定制擴(kuò)展性開發(fā)，來滿足我們的功能，解決痛點(diǎn)。

Kubernetes 是個(gè)高度可擴(kuò)展和配置的分布式系統(tǒng)，各個(gè)模塊都有豐富的擴(kuò)展模式和點(diǎn)。在選擇基于 Kubernetes 編程模式后，我們需要將 etcd 集群、遷移任務(wù)、監(jiān)控任務(wù)、備份任務(wù)、遷移策略等抽象成 Kubernetes 自定義資源，實(shí)現(xiàn)對應(yīng)的控制器即可。

下面是etcd云原生平臺的架構(gòu)圖。

下面以 etcd 集群的創(chuàng)建和分配為例，為你簡單介紹下 etcd 平臺的原理：

• 通過 kubectl 或者可視化 Web 系統(tǒng)創(chuàng)建 etcd 集群，本質(zhì)上是提交一個(gè) EtcdCluster 自定義資源

• etcd-apiserver 將CRD寫入到獨(dú)立的etcd存儲(chǔ)，etcd-lifecycle operator 監(jiān)聽到新集群后，根據(jù)EtcdCluster聲明的后端 Provider, 選擇基于 CVM Provider 還是容器化創(chuàng)建 etcd 集群。

• 集群創(chuàng)建完成后，etcd-lifecycle operator 還會(huì)添加一系列備份策略、監(jiān)控策略、巡檢策略，它們本質(zhì)上也是一系列 CRD資源。

• 當(dāng)業(yè)務(wù)需要分配 etcd 集群的時(shí)候，調(diào)度服務(wù)經(jīng)過篩選流程后，得到一系列滿足業(yè)務(wù)條件的候選集群，那如何從中返回最佳的etcd集群給用戶呢？ 這里，我們支持多種評優(yōu)策略，比如按最小連接數(shù)，它會(huì)通過 Kubernetes 的 API 從 Prometheus 中獲取集群的連接數(shù)，優(yōu)先將最小連接數(shù)的集群，返回給業(yè)務(wù)使用，也就是剛剛創(chuàng)建的集群，馬上就會(huì)被分配出去。

etcd巡檢案例介紹

如何給巡檢系統(tǒng)添加一個(gè)巡檢一個(gè)規(guī)則呢？

一個(gè)巡檢規(guī)則其實(shí)對應(yīng)的就是一個(gè) CRD 資源，如下面 yaml 文件所示，它就表示給集群 gz-qcloud-etcd-03 添加一個(gè)數(shù)據(jù)差異化的巡檢策略。

apiVersion: etcd.cloud.tencent.com/v1beta1
kind: EtcdMonitor
metadata:  
creationTimestamp: "2020-06-15T12:19:30Z"  
generation: 1  
labels:    
clusterName: gz-qcloud-etcd-03    
region: gz    
source: etcd-life-cycle-operator  
name: gz-qcloud-etcd-03-etcd-node-key-diff  
namespace: gz
spec:  
clusterId: gz-qcloud-etcd-03  
metricName: etcd-node-key-diff  
metricProviderName: cruiser  
name: gz-qcloud-etcd-03  
productName: tke  
region: gz
status:  
records:  
- endTime: "2021-02-25T11:22:26Z"    
message: collectEtcdNodeKeyDiff,etcd cluster gz-qcloud-etcd-03,total key num is      
122143,nodeKeyDiff is 0     
startTime: "2021-02-25T12:39:28Z"  
updatedAt: "2021-02-25T12:39:28Z"

創(chuàng)建此 yaml 文件后，巡檢服務(wù)就會(huì)執(zhí)行此巡檢策略，并暴露相關(guān) metrics 對外給 Prometheus 服務(wù)采集，最終實(shí)現(xiàn)效果如下。

如何快速感知異常，實(shí)現(xiàn)快速處置、乃至自愈？

基于穩(wěn)定的 TKE 云原生 Prometheus 監(jiān)控鏈路以及較完善的巡檢能力，etcd 平臺已經(jīng)能夠提供 etcd 集群可用性相關(guān)的各類監(jiān)控指標(biāo)，但是由于集群數(shù)較多，指標(biāo)眾多，用戶使用場景眾多，部署環(huán)境又復(fù)雜，難以快速定位異常原因，實(shí)現(xiàn)快速處置，即時(shí)恢復(fù)。

為提高感知異常的能力，實(shí)現(xiàn)快速處置及自愈，主要面臨以下幾個(gè)問題。

• 面對各種規(guī)格的etcd集群，繁雜的業(yè)務(wù)應(yīng)用場景，如何標(biāo)準(zhǔn)化監(jiān)控以及告警？

etcd 的業(yè)務(wù)場景與運(yùn)營場景是有所出入的，基于運(yùn)營需求，對 etcd 集群的接入進(jìn)行標(biāo)準(zhǔn)化，提供運(yùn)營所需標(biāo)準(zhǔn)化監(jiān)控指標(biāo)。依據(jù)標(biāo)準(zhǔn)化后的業(yè)務(wù)以及 etcd 規(guī)格進(jìn)一步落地告警標(biāo)準(zhǔn)化，從而實(shí)現(xiàn)監(jiān)控告警的運(yùn)營標(biāo)準(zhǔn)化。

• 面對海量指標(biāo)，如何有效收斂，快速衡量 etcd 集群可用性，感知異常？

etcd 可用性異常，關(guān)聯(lián)的監(jiān)控往往不同，沒有單一指標(biāo)能夠衡量其可用性，為此引入 SLO，有效反應(yīng) etcd 服務(wù)可用性，并圍繞 SLO 構(gòu)建多維度的監(jiān)控體系實(shí)現(xiàn)快速的異常感知和問題定位，從而進(jìn)一步快速恢復(fù)。

以下將針對上述問題逐一解決，構(gòu)建高效的數(shù)據(jù)運(yùn)營體系，實(shí)現(xiàn)異常的快速感知。

接入標(biāo)準(zhǔn)化

etcd運(yùn)維信息接入CRD：etcd 的持續(xù)運(yùn)維通過CRD進(jìn)行配置，完全遵循 Kubernetes 規(guī)范，Spec 中定義etcd 基礎(chǔ)信息，服務(wù)信息以 Annotation 的形式進(jìn)行拓展，一個(gè) CRD 囊括了 etcd 運(yùn)維所有需要的信息。

云原生的數(shù)據(jù)解決方案：開源 Prometheus 通過配置 Static Config 實(shí)現(xiàn)采集任務(wù)的配置，TKE 云原生 Prometheus 則充分利用開源 Prometheus-Operator 提供的 ServiceMonitor 資源配置采集任務(wù)，僅需配置幾個(gè)篩選標(biāo)簽即可實(shí)現(xiàn)組件 Metrics 的自動(dòng)化接入。etcd 本身作為數(shù)據(jù)存儲(chǔ)一般運(yùn)行于運(yùn)營管理集群之外，為實(shí)現(xiàn)對 etcd 自身監(jiān)控指標(biāo)的采集，利用 Kubernetes 中的No Selector Service實(shí)現(xiàn)，通過直接配置對應(yīng) etcd 節(jié)點(diǎn)的 Endpoints 采集 etcd 自身 Metrics。

標(biāo)準(zhǔn)化規(guī)范：etcd 監(jiān)控指標(biāo)通過 ServiceMonitor 的 Relabel 能力引入產(chǎn)品，場景和規(guī)格三類標(biāo)簽實(shí)現(xiàn)運(yùn)營信息的標(biāo)準(zhǔn)化。產(chǎn)品標(biāo)簽反應(yīng) etcd 服務(wù)對象所屬產(chǎn)品類別，場景標(biāo)簽通過對 etcd 的應(yīng)用場景進(jìn)行劃分而得 ，規(guī)格根據(jù) etcd 節(jié)點(diǎn)規(guī)格和用戶使用量進(jìn)行區(qū)分，初步分為 small，default，large 三檔。

告警統(tǒng)一標(biāo)準(zhǔn)：通過標(biāo)準(zhǔn)化的實(shí)施，告警規(guī)則不再依賴大量正則匹配實(shí)現(xiàn)，通過場景和規(guī)格能夠確定對應(yīng)告警指標(biāo)的閾值，結(jié)合告警指標(biāo)表達(dá)式即可實(shí)現(xiàn)告警規(guī)則的配置，對于新增告警規(guī)則，通過場景和規(guī)格的有效分割，可以在不變動(dòng)現(xiàn)有告警規(guī)則的情況下實(shí)現(xiàn)新增。同時(shí)帶入內(nèi)部自研告警系統(tǒng)的場景和規(guī)格標(biāo)簽?zāi)軌蚍磻?yīng)告警的應(yīng)處理人群，實(shí)現(xiàn)告警的定向推送，分級告警，提高告警的準(zhǔn)確性。

上述標(biāo)準(zhǔn)化流程不僅適用于云原生組件，對于以二進(jìn)制運(yùn)行于機(jī)器的組件，也可以通過自建 No Selector Service 實(shí)現(xiàn)對應(yīng)指標(biāo)的采集，組件根據(jù)使用場景等運(yùn)營信息確定好運(yùn)營類標(biāo)簽后，通過 ServiceMonitor 的 Relabel 能力能快速聯(lián)動(dòng)TKE云原生 Prometheus 實(shí)現(xiàn)監(jiān)控告警鏈路，建立數(shù)據(jù)標(biāo)準(zhǔn)化的運(yùn)營體系。

基于上述標(biāo)準(zhǔn)化流程，落地 etcd 產(chǎn)品化現(xiàn)網(wǎng)運(yùn)營支持，跟隨著產(chǎn)品化 etcd 上線，利用 ServiceMonitor 的 Relabel 能力，在不變動(dòng)監(jiān)控層的情況下實(shí)現(xiàn)了接入即運(yùn)維的特性：

定義接入規(guī)范：引入業(yè)務(wù)和規(guī)格的運(yùn)營類標(biāo)簽，依據(jù)該類標(biāo)簽將etcd使用場景反應(yīng)到監(jiān)控指標(biāo)當(dāng)中，為立體監(jiān)控大盤提供了數(shù)據(jù)依據(jù)，同時(shí)圍繞這類標(biāo)簽實(shí)現(xiàn)告警規(guī)則的配置和運(yùn)維。

通用告警規(guī)則直接適配：圍繞運(yùn)營類標(biāo)簽業(yè)務(wù)和規(guī)格，結(jié)合監(jiān)控指標(biāo)和閾值，直接生成通用告警規(guī)則，實(shí)現(xiàn)不同維度的告警。

分析視圖：基于業(yè)務(wù)場景，結(jié)合不同的監(jiān)控指標(biāo)，直接套用標(biāo)準(zhǔn)化的監(jiān)控視圖生成業(yè)務(wù)維度的 etcd 監(jiān)控大盤。

面向 SLO建設(shè)數(shù)據(jù)運(yùn)營體系

引入SLO

如何抽象一個(gè)SLO：SLO 即服務(wù)水平目標(biāo)，主要面向內(nèi)部，用于衡量服務(wù)質(zhì)量。確定 SLO 前，首先要確定 SLI（服務(wù)水平指標(biāo)）。服務(wù)是面向用戶的，因此一個(gè)重要衡量指標(biāo)是用戶方對服務(wù)的感知，其中，錯(cuò)誤率和延時(shí)感知最為明顯。同時(shí)服務(wù)本身和服務(wù)依賴的第三方服務(wù)也會(huì)決定服務(wù)質(zhì)量。因此對于 etcd 服務(wù)，SLI三要素可確定為請求錯(cuò)誤率及延時(shí)，是否有 Leader 和節(jié)點(diǎn)磁盤IO。節(jié)點(diǎn)磁盤IO在一定程度上會(huì)體現(xiàn)在讀操作的錯(cuò)誤率和延時(shí)，對 SLI 進(jìn)一步分層為 etcd 可用性和讀寫可用性。結(jié)合 Prometheus 實(shí)時(shí)計(jì)算能力，etcd SLO 計(jì)算公式可初步確定。

SLO的計(jì)算：SLO用于衡量服務(wù)質(zhì)量，服務(wù)質(zhì)量由用戶感知，自身服務(wù)狀態(tài)以及依賴的底層服務(wù)決定，因此SLO由基于etcd核心接口RPC（Range/Txn/Put等）的延時(shí)，磁盤IO，是否有Leader以及相關(guān)巡檢指標(biāo)組成。

SLO運(yùn)營方案：經(jīng)過對 etcd 服務(wù)的分析初步得出 SLO 計(jì)算公式并且落地具體SLO指標(biāo)，但只是初步實(shí)現(xiàn)。SLO 需要通過對比實(shí)際異常情況，不斷修正，提高SLO的準(zhǔn)確率。經(jīng)過一段時(shí)間的觀察和修正，SLO 指標(biāo)日趨準(zhǔn)確，逐步形成如下圖的運(yùn)營模式，通過 SLO 聯(lián)動(dòng)監(jiān)控，告警以及現(xiàn)網(wǎng)問題，提高運(yùn)營效率，完善主動(dòng)服務(wù)能力。經(jīng)過一段時(shí)間的運(yùn)營，SLO 告警在數(shù)次異常情況下通過電話告警及時(shí)暴露問題，實(shí)現(xiàn)了異常的主動(dòng)發(fā)現(xiàn)。

TKE云原生Prometheus落地SLO

引入Recording Rules

etcd 可用性和延時(shí)等構(gòu)建SLO的關(guān)鍵指標(biāo)已經(jīng)通過 TKE 云原生 Prometheus 進(jìn)行采集，依托 Promethues 的計(jì)算能力，能夠?qū)崿F(xiàn) SLO 的計(jì)算，但是由于SLO計(jì)算涉及的指標(biāo)較多，etcd 體量大，SLO 計(jì)算延遲大，出現(xiàn)的斷點(diǎn)較多。

Recording Rules 是 Prometheus 的記錄規(guī)則，通過該能力能夠提前設(shè)置好一個(gè)運(yùn)算表達(dá)式，其結(jié)果將被保存為一組新的時(shí)間序列數(shù)據(jù)。通過這種方式，能夠?qū)?fù)雜的SLO計(jì)算公式分解為不同單元，分散計(jì)算壓力，避免數(shù)據(jù)斷點(diǎn)，并且由于計(jì)算結(jié)果已被保存，SLO 歷史數(shù)據(jù)查詢速度極快。同時(shí)，Promethues 通過收到的 SIGNUP 信號量更新記錄規(guī)則，因此記錄規(guī)則的重載是實(shí)時(shí)的，這種特性有利于在SLO實(shí)踐過程不斷修改計(jì)算公式，持續(xù)優(yōu)化SLO。

數(shù)據(jù)價(jià)值運(yùn)營體系建設(shè)

通過SLO的落地，etcd 平臺監(jiān)控告警依托SLO實(shí)現(xiàn)了入口的統(tǒng)一，考慮到 etcd 使用場景繁多，日常排障困難，問題分析不易進(jìn)行，圍繞SLO監(jiān)控體系建立SLO快速排障和立體 SLO 監(jiān)控，整體如下圖所示。

運(yùn)營訴求

基本面確認(rèn)：通過監(jiān)控能夠了解 etcd 的整體概況，如容量信息，組件穩(wěn)定性，服務(wù)可用性等。

不同場景的特性訴求：不同應(yīng)用場景 etcd 的側(cè)重點(diǎn)不同，所關(guān)注的監(jiān)控維度也不相同，監(jiān)控大盤應(yīng)能反應(yīng)不同場景的特性。

運(yùn)維排障：底層 IAAS 層資源抖動(dòng)時(shí)快速確定受影響etcd集群，故障時(shí)快速確定影響面，并且能夠通過告警視圖進(jìn)一步確認(rèn)故障原因。

立體監(jiān)控

etcd 平臺監(jiān)控視圖如下圖所示，總體分為一級，二級，三級以及排障視圖。一級為監(jiān)控大盤，二級劃分為三個(gè)場景，三級為單集群監(jiān)控，是具體問題的關(guān)鍵，排障視圖聯(lián)動(dòng) etcd 與 Kubernetes 實(shí)現(xiàn)雙向查詢。

一級監(jiān)控視圖：SLO 基于多種監(jiān)控指標(biāo)計(jì)算而成，能有效衡量 etcd 可用性，起到了收斂監(jiān)控指標(biāo)的作用，實(shí)現(xiàn)統(tǒng)一入口。依據(jù) SLO 建立多地域的監(jiān)控大盤，能夠整體了解 etcd 情況，快速確認(rèn)故障影響面。

二級監(jiān)控視圖：依據(jù) etcd 應(yīng)用場景，二級監(jiān)控由業(yè)務(wù)，大客戶等場景組成，實(shí)現(xiàn)不同場景的特性需求，業(yè)務(wù)反應(yīng)各個(gè)地域的整體可用性，能夠現(xiàn)實(shí)各業(yè)務(wù)各地域是否具備足夠的 etcd 資源，大客戶則在容量上需要反應(yīng)出其規(guī)模，也需要考慮到開放給客戶使用的情況。

三級監(jiān)控視圖：三級監(jiān)控為單集群監(jiān)控視圖，通過該視圖，能夠確認(rèn) etcd 具體問題所在，為故障恢復(fù)提供依據(jù)。

SLO排障監(jiān)控視圖：etcd 是 Kubernetes 的底層存儲(chǔ)服務(wù)，在排障過程中，etcd 與 Kubernetes 往往需要雙向確認(rèn)，為提高排障效率，SLO排障監(jiān)控由 etcd 與 Kubernetes 集群正向查詢，反向查詢視圖組成。

運(yùn)營成效

SLO監(jiān)控體系基本覆蓋了所有的運(yùn)營場景，在實(shí)際運(yùn)營過程中多次起到了關(guān)鍵作用。

底層IAAS抖動(dòng)：通過一級監(jiān)控快速確認(rèn)影響面，進(jìn)一步在不同場景下確認(rèn)受影響 etcd 集群，可快速確定影響面。

問題定位：接收相應(yīng)SLO告警后，可通過三級監(jiān)控確定SLO告警原因，確認(rèn)影響指標(biāo)，實(shí)現(xiàn)故障的快速恢復(fù)，同時(shí) etcd 與 Kubernetes 的正反查詢不僅方便了 etcd 問題確認(rèn)，也是 Kubernetes 問題確認(rèn)的利器。

主動(dòng)服務(wù)：通過SLO監(jiān)控大盤多次提前發(fā)現(xiàn)etcd異常，并主動(dòng)反饋給上層服務(wù)相關(guān)團(tuán)隊(duì)，有效將服務(wù)故障扼殺在搖籃當(dāng)中。

自愈能力：etcd節(jié)點(diǎn)故障會(huì)影響etcd可用性，通過SLO監(jiān)控告警，能夠快速感知異常，同時(shí)依托容器化部署的優(yōu)勢，產(chǎn)品化etcd集群的節(jié)點(diǎn)均以Pod形式運(yùn)行，當(dāng)出現(xiàn)異常節(jié)點(diǎn)時(shí)，自動(dòng)會(huì)剔除異常POD，添加新的節(jié)點(diǎn)，從而在用戶無感知的前提實(shí)現(xiàn)故障自愈。

以上就是如何構(gòu)建萬級Kubernetes集群場景下的etcd監(jiān)控平臺，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。