上海阿里云代理商：阿里云 ACK 容器服務(wù)生產(chǎn)級可觀測體系建設(shè)實踐

　　【聚搜云】（www.gzjcsc123.com）是上海聚搜信息技術(shù)有限公司旗下品牌，坐落于魔都上海，服務(wù)于全球、2019年成為阿里云代理商生態(tài)合作伙伴。與阿里云代理商、騰訊云、華為云、西部數(shù)碼、美橙互聯(lián)、AWS亞馬遜云國際站代理商、聚搜云,長期戰(zhàn)略合作的計劃！阿里云國際站代理商專業(yè)的云服務(wù)商！

　　作者：馮詩淳（行疾）

　　ACK 可觀測體系介紹

　　全景概要介紹

　　上圖為 ACK 可觀測體系全景圖金字塔，從上至下可分為四層：

　　最上層是最接近用戶業(yè)務(wù)的 Business Monitoring，包括用戶業(yè)務(wù)的前端的流量、PV、前端性能、JS 響應(yīng)速度等監(jiān)控。通過容器服務(wù)的 IngressDashboard 來監(jiān)測 Ingress 的請求量以及請求的狀態(tài)，用戶可以定制業(yè)務(wù)日志，通過容器服務(wù)的日志監(jiān)控來實現(xiàn)業(yè)務(wù)的自定義監(jiān)控。

　　第二層是 Application Performance Monitoring，包括用戶的應(yīng)用監(jiān)控，由 ARMS APM 產(chǎn)品提供用戶Java Profiling 和 Tracing等能力，也支持 OpenTracing和 OpenTelemetric 協(xié)議的多語言監(jiān)控方案。

　　第三層是 Container Monitoring，包括容器的集群資源、容器 runtime 層、容器引擎以及容器集群的穩(wěn)定性。使用阿里云 Prometheus 在一張 Global view 的大盤中展示不同集群層面的資源應(yīng)用，包括性能、水位、云資源，也包括事件體系和日志體系，由事件中心和日志中心覆蓋。

　　最下層是 Infrastructure Monitoring，包括不同的云資源、虛擬化層、操作系統(tǒng)內(nèi)核層等。容器層和基礎(chǔ)架構(gòu)層都可以使用基于 eBPF 的無侵入式架構(gòu)和 K8s 監(jiān)控能力做網(wǎng)絡(luò)和調(diào)用的 tracing。

　　可觀測體系的每一層都和可觀測的三大支柱 Logging、Tracing、Metrics 有不同程度的映射。

　　場景一：異常診斷場景的可觀測能力實踐

　　用戶的異常診斷案例

　　早上 9 點多業(yè)務(wù)流量激增時出現(xiàn)了異常診斷，收到容器報警提示某 Pod Down 影響業(yè)務(wù)流量。用戶收到報警后快速反應(yīng)，對核心業(yè)務(wù)的 Pod 進行重啟或擴容，查找問題根因。首先通過 IngressDashboard 從入口流量自上而下分析，發(fā)現(xiàn)對外業(yè)務(wù)的訪問成功率下降以及出現(xiàn) 4XX 返回碼的請求，說明這次異常影響了用戶業(yè)務(wù)。再從資源以及負(fù)載層面分析，可以發(fā)現(xiàn)是由于朝九晚五的流量導(dǎo)致水位負(fù)載，在當(dāng)天早上 9 點時存在與故障對齊的明顯水位飆升，這也是故障所在。

　　系統(tǒng)第一時間報警核心業(yè)務(wù)的 Pod 定位，結(jié)合業(yè)務(wù)日志進行分析，加上 ARMS Java 的 APM 應(yīng)用監(jiān)控，定位到產(chǎn)生緩存 bug 是由于早上 9 點鐘業(yè)務(wù)流量飆升引發(fā)了 bug 最后造成頻繁的數(shù)據(jù)庫讀寫，調(diào)用鏈也反映可能出現(xiàn)了數(shù)據(jù)庫的慢查詢,最后通過修復(fù) bug 徹底閉環(huán)整個異常。

　　上述流程是非常典型的貫穿了整個 ACK 可觀測不同能力異常診斷的排查過程，能夠幫助我們更好地理解 ACK 可觀測體系如何相互協(xié)調(diào)完成工作。

　　事件體系介紹

　　社區(qū)的 K8s 中包含了非常成熟的事件體系，提供了應(yīng)用層的事件以及 runtime 層的事件。ACK 可觀測體系在社區(qū)的事件體系之上，從表層到底層都進行了覆蓋和增強，做到了可觀測事件體系的全覆蓋。

　　? 應(yīng)用異常：對于 K8s 的應(yīng)用事件提供了用戶灰度發(fā)布以及 HPA 等異常行為的事件監(jiān)控。

　　? 管控操作事件：增加了集群的管控事件、用戶對集群的異常操作以及重要變更，甚至包括成本和預(yù)算超標(biāo)等。

　　? 集群核心組件異常：集群的穩(wěn)定性很大一部分由集群核心組件的健康來保證。對于集群核心組件包括 API server、ETCD、Scheduler、CCM 等都做了異常事件的增強，出現(xiàn)異常事件能夠第一時間進行觸達。此外，還包括用戶側(cè)核心組件 addon 事件，比如 Terway、存儲等。

　　? 集群容器引擎層異常：對集群容器引擎層做了增強，包括了 Container Runtime、Kubelet、Cgroup 等異常。

　　? 節(jié)點異常：包括 OS/內(nèi)核層異常，比如操作系統(tǒng)內(nèi)核宕機、操作系統(tǒng)配置的異常等，也包括資源層異常比如網(wǎng)絡(luò)資源異常、存儲資源異常、其他云資源異常等，為容器服務(wù)的運維保障及功能更強的覆蓋提供了支持。

　　ACK 提供了開箱即用的事件中心能力，一鍵開啟事件中心，即可享受復(fù)雜的事件體系帶來的強大功能。它提供了預(yù)置的試驗中心大盤，能夠?qū)χ匾氖录M行突出以及統(tǒng)計，也提供了強大、靈活易用的數(shù)據(jù)分析能力，為后面基于事件驅(qū)動的 OPS 體系提供了基礎(chǔ)。ACK K8s 集群更多的是對資源的生命周期進行管控，事件中心也提供了以事件為錨點的資源生命周期的管控能力?？梢詫ι芷谥凶钪匾膸讉€時間點進行性能的調(diào)試優(yōu)化以及對異常 Pod 狀態(tài)快速反應(yīng)。

　　日志體系介紹

　　Logging 在 K8s 中的第一個使用場景是重要流量，如 Ingress 等。ACK 的日志中心默認(rèn)提供了 Ingress 等重要場景的大盤，一鍵接入 Ingress 大盤后即可快速查看集群 Ingress 流量，此外還包括 PV、UV、應(yīng)用的異常狀態(tài)以及統(tǒng)計，快速清晰，易于應(yīng)用。

　　第二個日志使用場景是審計。集群中的資源經(jīng)常被不同的賬號訪問使用，集群的安全也迫切需要重點關(guān)注。我們提供了審計日志大盤，可以快速分析集群資源的訪問和使用軌跡，針對未被授權(quán)的訪問可進行報警和預(yù)警，為集群提供更安全的環(huán)境。

　　我們提供了云原生無侵入式的日志獲取方式，用戶只需通過簡單的 CRD 或在 Pod 上打 annotation ，即可將日志采集到日志中心，并享受日志中心多維、強大的分析能力。

　　Metric 體系介紹

　　Metrics 體系是做穩(wěn)定性保障和性能調(diào)優(yōu)時最常用的體系，水位等關(guān)鍵指標(biāo)都能通過大盤進行直觀展示。產(chǎn)品側(cè)預(yù)置了 ARMS Prometheus 大盤產(chǎn)品，購買了 ACK K8s 集群后，可以一鍵開啟 Prometheus 大盤。此外，體系內(nèi)預(yù)置了重要場景的 Prometheus 大盤，都是經(jīng)過 K8s 上業(yè)務(wù)運維成熟經(jīng)驗的沉淀。Prometheus 方案涉及到不同的服務(wù)，不僅包括容器服務(wù)側(cè)最核心的 K8s 應(yīng)用、網(wǎng)絡(luò)、核心控制面指標(biāo)，還包括比如 AI 場景、 GPU 指標(biāo)以及存儲 CSI 等外部存儲場景，以及資源的優(yōu)化或成本的優(yōu)化指標(biāo)。

　　使用統(tǒng)一的 Prometheus 數(shù)據(jù)鏈路方案，不進能夠支持容器場景的指標(biāo)，也支持不同云產(chǎn)品的指標(biāo)以及云產(chǎn)品上不同中間件的指標(biāo)，可以將所有層級指標(biāo)都在 Prometheus 數(shù)據(jù)鏈路中進行統(tǒng)一展示。

　　ACK 集群控制面的核心組件 API Server、ETCD 、scheduler 、CCM 等也做了指標(biāo)加強。Pro 集群不只負(fù)責(zé)托管這部分核心組件、維護其 SLA，同時也會將透明指標(biāo)性能暴露給用戶，讓用戶使用安心。

　　? 場景二：穩(wěn)定性保障 - 2022 冬奧會 ACK 助力圓滿平穩(wěn)舉行

　　指標(biāo)場景是穩(wěn)定性保障的重要支持能力。ACK 非常榮幸地為 2022 年的冬奧會服務(wù)，助力冬奧系統(tǒng)圓滿平穩(wěn)運行。

　　ACK 集群中部署了冬奧會多個核心業(yè)務(wù)系統(tǒng)，包括冬奧的國際官網(wǎng)、比賽場館、票務(wù)系統(tǒng)等，為多個核心系統(tǒng)保駕護航。核心系統(tǒng)多為 Java 系微服務(wù)架構(gòu)，實際使用時有近千個 Deployment 實例。我們通過引入壓測的方式進行容量評估，同時配合為冬奧定制的首屏運維大盤，實時進行應(yīng)用和集群穩(wěn)定性的保障，保證了冬奧訪系統(tǒng)訪問的順滑。

　　? 場景三：生產(chǎn)級規(guī)模集群穩(wěn)定性保障實踐

　　很多用戶的生產(chǎn)系統(tǒng)規(guī)模很大，到達千級別節(jié)點的集群規(guī)模后，用戶在集群上會進行密集、大規(guī)模的集群資源訪問，極易出現(xiàn)集群穩(wěn)定性問題。

　　比如，用戶在大規(guī)模集群中頻繁密集地訪問集群資源，首先會使 API Server 的請求數(shù)較高，API ServerMutating 請求數(shù)也會處于高位。API Server 負(fù)載過高會導(dǎo)致出現(xiàn)丟棄請求的情況，這也是 API Server 的降級特性，會影響用戶業(yè)務(wù)的發(fā)布或用戶的變更。

　　再比如，密集的集群資源訪問也可能打滿 API Server 帶寬，API Server 的請求延時 RT 會升至高位，一次 API 的訪問可能需要幾十秒，會嚴(yán)重影響用戶的業(yè)務(wù)，API Server 的只讀請求數(shù)也會飆升。

　　我們提供了 control plane 核心組件的監(jiān)控大盤，可以快速發(fā)現(xiàn) API Server 的水位和請求響應(yīng)時間的延時問題，然后根據(jù) API Server 的訪問日志快速定位是哪個應(yīng)用的什么動作導(dǎo)致 API Server 的水位和資源請求高，最終找到具體應(yīng)用進行止血，解決問題。

　　Prometheus For ACK Pro

　　阿里云近期推出了 Prometheus for ACK Pro ，它是 Prometheus 的升級服務(wù)，能夠在同一張大盤上看到多個數(shù)據(jù)源，包括集群事件日志、基于 eBPF 的無侵入式的應(yīng)用指標(biāo)、網(wǎng)絡(luò)指標(biāo)等，提供一致性的體驗。用戶可以通過一張大盤的關(guān)聯(lián)分析邏輯，從總覽到細(xì)節(jié)，通過多數(shù)據(jù)源、多角度的可觀測能力進行不同角度的排查。

　　Tracing 體系介紹

　　? 應(yīng)用層 Trace

　　在 ACK 可觀測體系里， Tracing 體系提供了最終定位根因的能力，它分為兩部分:

　　第一部分是應(yīng)用層的 Tracing，提供 ARMS APM 能力，支持 OpenTracing、OpenTelemetric 協(xié)議，可以支持多種語言的應(yīng)用。針對 Java 也提供了無侵入式的 APM 能力，只需要在 Pod 上打上 annotation， Java 應(yīng)用的 Pod 即可享受實時的監(jiān)控數(shù)據(jù)服務(wù)，可以查看實時的應(yīng)用水位、 JVM 的性能指標(biāo)、應(yīng)用上下游分布式和微服務(wù)的全局調(diào)用 top 圖等，也支持 Profiling 以及代碼堆棧級的調(diào)用監(jiān)控能力。不同語言可以匯聚成同一張分布式調(diào)用追蹤大圖，自上而下地查看一次分布式調(diào)用，從而定位、診斷問題。

　　? 集群網(wǎng)絡(luò)、調(diào)用 Trace

　　第二部分是集群網(wǎng)絡(luò)和調(diào)用 Trace。

　　近期我們推出了基于 eBPF 網(wǎng)絡(luò)層面的 Tracing 能力。通過 eBPF 插樁技術(shù)，在內(nèi)核層面實現(xiàn)了零代碼改動且非常低性能消耗的網(wǎng)絡(luò) Tracing 能力。提供了全局拓?fù)?、快速定位問題調(diào)用鏈的網(wǎng)絡(luò)拓?fù)湔故疽约百Y源層面展示，也支持在統(tǒng)一的全局架構(gòu)視圖中集合 Metrics、Tracing 和 Logging 多個角度進行可觀測能力觀察。

　　基于 ACK 可觀測能力建設(shè) AIOps體系

　　事件驅(qū)動的 AIOps 體系，用戶可以將事件作為統(tǒng)一的驅(qū)動數(shù)據(jù)源進行問題的發(fā)現(xiàn)、觸達以及 AI 智能化運維操作的橋梁。以 ACK 事件中心為核心，構(gòu)造了統(tǒng)一的事件格式規(guī)范，K8s 的事件會以統(tǒng)一的事件配置格式提供給用戶，最后以事件中心為核心，通過統(tǒng)一的事件處理流提供給用戶。用戶可以通過訂閱事件做事件的智能化運維以及構(gòu)建其體系。用戶可以通過某個應(yīng)用的業(yè)務(wù)進行業(yè)務(wù)事件推送，并對業(yè)務(wù)事件進行智能化運維處理，比如智能的擴容或縮容等。

　　此外，我們也提供了 ACK 報警中心，通過統(tǒng)一的報警配置為用戶構(gòu)建 AIOps 的體系，幫助用戶快速建立運維的訂閱、收發(fā)和問題排障、處理體系。

　　報警中心會為用戶提供統(tǒng)一的配置，幫助用戶快速建立 ACK 場景上異常診斷的異常規(guī)則集。ACK 報警中心提供了開箱即用的報警能力，沉淀了常用的容器場景異常規(guī)則集，開箱即用。其次，可以通過報警消息的細(xì)粒度訂閱關(guān)系構(gòu)建 ITOps 體系，不同的異常可以通過報警中心的訂閱配置關(guān)系投遞到真正能夠解決異常的人手里。ACK 也沉淀了標(biāo)準(zhǔn)的異常以及對應(yīng)標(biāo)準(zhǔn)異常處理的 SOP 手冊，發(fā)現(xiàn)報警時，會提示異常類型，以及為用戶提供處理異常的標(biāo)準(zhǔn) SOP 修復(fù)流程。

　　基于 ACK 可觀測能力建設(shè) FinOps 體系

　　越來越多的用戶面臨了上云階段或上云后治理階段的降本增效問題，主要存在以下幾個方面的痛點：

　　? 上云之前——如何上云，難規(guī)劃；

　　? 上云之后——云產(chǎn)品種類豐富，集群資源類型也豐富，計費難；

　　? 高度 SaaS 化的應(yīng)用部署在同一個集群中進行共享，成本分賬難；

　　? 每年都會有新的業(yè)務(wù)生成和下線，集群和資源的使用關(guān)系是動態(tài)的，難以進行持續(xù)的優(yōu)化和治理；

　　? 此前一般使用 Excel 表對能力進行管理，在云原生的場景下有豐富的用戶應(yīng)用和有豐富的賬單資源類型，難以管理。

　　ACK 提供了云原生企業(yè) IT 成本治理方案，通過多維度的成本分?jǐn)偤凸浪隳Ｐ停瑸榧旱馁Y源進行成本估算和分?jǐn)?。可以通過根因的下鉆和趨勢的預(yù)測進行成本洞察，集群上多個應(yīng)用業(yè)務(wù)的成本可以細(xì)粒度下鉆，進行成本拆分。對多集群場景上的成本提供了成熟的解決方案覆蓋，以及提供企業(yè)云原生 IT 成本治理的專家服務(wù)。

　　此外，我們還推出了內(nèi)置的應(yīng)用資源畫像以及應(yīng)用資源的智能推薦，可以為資源推薦合適的成本以及進行預(yù)算控制，最后會根據(jù)不同的場景進行成本優(yōu)化，如大數(shù)據(jù)、AI、游戲等。

　　最后，支持多樣化場景，包括多云和混合云等都能在統(tǒng)一的平面進行展示和管理。

　　客戶案例

　　中華財險作為互聯(lián)網(wǎng)金融的頭部公司，有千核級別的集群規(guī)模，同時管理運維多個 SaaS 化線上業(yè)務(wù)，具有高度多租化、對業(yè)務(wù)穩(wěn)定性要求高、對業(yè)務(wù)資源/成本趨勢敏感度高等行業(yè)特點。

　　中華財險從傳統(tǒng) IT 架構(gòu)到云原生化的過程中，面臨著容量規(guī)劃難、算清成本難、閑置資源難發(fā)現(xiàn)以及成本優(yōu)化和業(yè)務(wù)穩(wěn)定性難以平衡的挑戰(zhàn)。

　　我們通過 ACK 的成本治理解決方案為它進行了壓測、容量規(guī)劃，通過 ACK 成本分析進行業(yè)務(wù)分賬的賬單管理和分析，解決了閑置資源的優(yōu)化，為其提供了分配資源的優(yōu)化策略，最后通過容器服務(wù)提供了細(xì)粒度的容器部署以及彈性策略等優(yōu)化手段。

　　上云前，客戶集群的資源分配閑置率高達 30%+，而通過我們提供的成本治理方案，閑置率降至 10% 以下，為行業(yè)領(lǐng)先水平。