*作者：馮詩淳（行疾）*

## ACK 可觀測體系介紹

### 全景概要介紹

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c70c84b45b5447f3a125337585ea300c~tplv-k3u1fbpfcp-zoom-1.image "1.png")

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

最上層是最接近使用者業務的 **Business Monitoring**，包括使用者業務的前端的流量、PV、前端效能、JS 響應速度等監控。透過容器服務的 IngressDashboard 來監測 Ingress 的請求量以及請求的狀態，使用者可以定製業務日誌，透過容器服務的日誌監控來實現業務的自定義監控。

第二層是 **Application Performance Monitoring**，包括使用者的應用監控，由 ARMS APM 產品提供使用者Java Profiling 和 Tracing等能力，也支援 OpenTracing和 OpenTelemetric 協議的多語言監控方案。

第三層是 **Container Monitoring**，包括容器的叢集資源、容器 runtime 層、容器引擎以及容器叢集的穩定性。使用阿里雲 Prometheus 在一張 Global view 的大盤中展示不同叢集層面的資源應用，包括效能、水位、雲資源，也包括事件體系和日誌體系，由事件中心和日誌中心覆蓋。

最下層是 **Infrastructure Monitoring**，包括不同的雲資源、虛擬化層、作業系統核心層等。容器層和基礎架構層都可以使用基於 eBPF 的無侵入式架構和 K8s 監控能力做網路和呼叫的 tracing。

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

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

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/35dd7f92aa1f4cf290592285bf39057a~tplv-k3u1fbpfcp-zoom-1.image "2.png")

使用者的異常診斷案例

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

系統第一時間報警核心業務的 Pod 定位，結合業務日誌進行分析，加上 ARMS Java 的 APM 應用監控，定位到產生快取 bug 是由於早上 9 點鐘業務流量飆升引發了 bug 最後造成頻繁的資料庫讀寫，呼叫鏈也反映可能出現了資料庫的慢查詢,最後透過修復 bug 徹底閉環整個異常。

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

### 事件體系介紹

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/425749396bbb4b1ea42b4c9f311ef68c~tplv-k3u1fbpfcp-zoom-1.image "3.png")

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

-   **應用異常**：對於 K8s 的應用事件提供了使用者灰度釋出以及 HPA 等異常行為的事件監控。

-   **管控操作事件**：增加了叢集的管控事件、使用者對叢集的異常操作以及重要變更，甚至包括成本和預算超標等。

-   **叢集核心元件異常**：叢集的穩定性很大一部分由叢集核心元件的健康來保證。對於叢集核心元件包括 API server、ETCD、Scheduler、CCM 等都做了異常事件的增強，出現異常事件能夠第一時間進行觸達。此外，還包括使用者側核心元件 addon 事件，比如 Terway、儲存等。

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

-   **節點異常**：包括 OS/核心層異常，比如作業系統核心當機、作業系統配置的異常等，也包括資源層異常比如網路資源異常、儲存資源異常、其他雲資源異常等，為容器服務的運維保障及功能更強的覆蓋提供了支援。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb843e0a42b34661b0328b76620b28f2~tplv-k3u1fbpfcp-zoom-1.image "4.png")

ACK 提供了開箱即用的事件中心能力，一鍵開啟事件中心，即可享受複雜的事件體系帶來的強大功能。它提供了預置的試驗中心大盤，能夠對重要的事件進行突出以及統計，也提供了強大、靈活易用的資料分析能力，為後面基於事件驅動的 OPS 體系提供了基礎。ACK K8s 叢集更多的是對資源的生命週期進行管控，事件中心也提供了以事件為錨點的資源生命週期的管控能力。可以對生命週期中最重要的幾個時間點進行效能的除錯最佳化以及對異常 Pod 狀態快速反應。

### 日誌體系介紹

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f5259d7a70b94e9b8d7c435c45d9ed85~tplv-k3u1fbpfcp-zoom-1.image "5.png")

Logging 在 K8s 中的第一個使用場景是重要流量，如 Ingress 等。ACK 的日誌中心預設提供了 Ingress 等重要場景的大盤，一鍵接入 Ingress 大盤後即可快速檢視叢集 Ingress 流量，此外還包括 PV、UV、應用的異常狀態以及統計，快速清晰，易於應用。

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

我們提供了雲原生無侵入式的日誌獲取方式，使用者只需透過簡單的 CRD 或在 Pod 上打 annotation ，即可將日誌採集到日誌中心，並享受日誌中心多維、強大的分析能力。

### Metric 體系介紹

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/16424690e9b9448888e14f1be4c52788~tplv-k3u1fbpfcp-zoom-1.image "6.png")

Metrics 體系是做穩定性保障和效能調優時最常用的體系，水位等關鍵指標都能透過大盤進行直觀展示。產品側預置了 ARMS Prometheus 大盤產品，購買了 ACK K8s 叢集后，可以一鍵開啟 Prometheus 大盤。此外，體系內預置了重要場景的 Prometheus 大盤，都是經過 K8s 上業務運維成熟經驗的沉澱。Prometheus 方案涉及到不同的服務，不僅包括容器服務側最核心的 K8s 應用、網路、核心控制面指標，還包括比如 AI 場景、 GPU 指標以及儲存 CSI 等外部儲存場景，以及資源的最佳化或成本的最佳化指標。

使用統一的 Prometheus 資料鏈路方案，不進能夠支援容器場景的指標，也支援不同雲產品的指標以及雲產品上不同中介軟體的指標，可以將所有層級指標都在 Prometheus 資料鏈路中進行統一展示。

ACK 叢集控制面的核心元件 API Server、ETCD 、scheduler 、CCM 等也做了指標加強。Pro 叢集不只負責託管這部分核心元件、維護其 SLA，同時也會將透明指標效能暴露給使用者，讓使用者使用安心。

-   **場景二：穩定性保障 - 2022 冬奧會 ACK 助力圓滿平穩舉行**

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ea5ee2fb519e41fb9f664251fffde4dd~tplv-k3u1fbpfcp-zoom-1.image "7.png")

指標場景是穩定性保障的重要支援能力。ACK 非常榮幸地為 2022 年的冬奧會服務，助力冬奧系統圓滿平穩執行。

ACK 叢集中部署了冬奧會多個核心業務系統，包括冬奧的國際官網、比賽場館、票務系統等，為多個核心繫統保駕護航。核心系統多為 Java 系微服務架構，實際使用時有近千個 Deployment 例項。我們透過引入壓測的方式進行容量評估，同時配合為冬奧定製的首屏運維大盤，實時進行應用和叢集穩定性的保障，保證了冬奧訪系統訪問的順滑。

-   **場景三：生產級規模叢集穩定性保障實踐**

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aee784583d0c4a2d9b30f066a37819bd~tplv-k3u1fbpfcp-zoom-1.image "8.png")

很多使用者的生產系統規模很大，到達千級別節點的叢集規模後，使用者在叢集上會進行密集、大規模的叢集資源訪問，極易出現叢集穩定性問題。

比如，使用者在大規模叢集中頻繁密集地訪問叢集資源，首先會使 API Server 的請求數較高，API ServerMutating 請求數也會處於高位。API Server 負載過高會導致出現丟棄請求的情況，這也是 API Server 的降級特性，會影響使用者業務的釋出或使用者的變更。

再比如，密集的叢集資源訪問也可能打滿 API Server 頻寬，API Server 的請求延時 RT 會升至高位，一次 API 的訪問可能需要幾十秒，會嚴重影響使用者的業務，API Server 的只讀請求數也會飆升。

我們提供了 control plane 核心元件的監控大盤，可以快速發現 API Server 的水位和請求響應時間的延時問題，然後根據 API Server 的訪問日誌快速定位是哪個應用的什麼動作導致 API Server 的水位和資源請求高，最終找到具體應用進行止血，解決問題。

### Prometheus For ACK Pro

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c3e54270ea944ce5a035ea069f811d83~tplv-k3u1fbpfcp-zoom-1.image "9.png")

阿里雲近期推出了 Prometheus for ACK Pro ，它是 Prometheus 的升級服務，能夠在同一張大盤上看到多個資料來源，包括叢集事件日誌、基於 eBPF 的無侵入式的應用指標、網路指標等，提供一致性的體驗。使用者可以透過一張大盤的關聯分析邏輯，從總覽到細節，透過多資料來源、多角度的可觀測能力進行不同角度的排查。

### Tracing 體系介紹

-   **應用層 Trace**

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d54177388f304bbe878f3ffbba823539~tplv-k3u1fbpfcp-zoom-1.image "10.png")

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

第一部分是應用層的 Tracing，提供 ARMS APM 能力，支援 OpenTracing、OpenTelemetric 協議，可以支援多種語言的應用。針對 Java 也提供了無侵入式的 APM 能力，只需要在 Pod 上打上 annotation， Java 應用的 Pod 即可享受實時的監控資料服務，可以檢視實時的應用水位、 JVM 的效能指標、應用上下游分散式和微服務的全域性呼叫 top 圖等，也支援 Profiling 以及程式碼堆疊級的呼叫監控能力。不同語言可以匯聚成同一張分散式呼叫追蹤大圖，自上而下地檢視一次分散式呼叫，從而定位、診斷問題。

-   **叢集網路、呼叫 Trace**

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d06be7e479074532bedd37ddd188b0c5~tplv-k3u1fbpfcp-zoom-1.image "11.png")

第二部分是叢集網路和呼叫 Trace。

近期我們推出了基於 eBPF 網路層面的 Tracing 能力。透過 eBPF 插樁技術，在核心層面實現了零程式碼改動且非常低效能消耗的網路 Tracing 能力。提供了全域性拓撲、快速定位問題呼叫鏈的網路拓撲展示以及資源層面展示，也支援在統一的全域性架構檢視中集合 Metrics、Tracing 和 Logging 多個角度進行可觀測能力觀察。

## 基於 ACK 可觀測能力建設 AIOps體系

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b411bd9cf5343d1a3777e88ed6bca60~tplv-k3u1fbpfcp-zoom-1.image "12.png")

事件驅動的 AIOps 體系，使用者可以將事件作為統一的驅動資料來源進行問題的發現、觸達以及 AI 智慧化運維操作的橋樑。以 ACK 事件中心為核心，構造了統一的事件格式規範，K8s 的事件會以統一的事件配置格式提供給使用者，最後以事件中心為核心，透過統一的事件處理流提供給使用者。使用者可以透過訂閱事件做事件的智慧化運維以及構建其體系。使用者可以透過某個應用的業務進行業務事件推送，並對業務事件進行智慧化運維處理，比如智慧的擴容或縮容等。

此外，我們也提供了 ACK 報警中心，透過統一的報警配置為使用者構建 AIOps 的體系，幫助使用者快速建立運維的訂閱、收發和問題排障、處理體系。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1814597430564435afbf7899b30be960~tplv-k3u1fbpfcp-zoom-1.image "13.png")

報警中心會為使用者提供統一的配置，幫助使用者快速建立 ACK 場景上異常診斷的異常規則集。ACK 報警中心提供了開箱即用的報警能力，沉澱了常用的容器場景異常規則集，開箱即用。其次，可以透過報警訊息的細粒度訂閱關係構建 ITOps 體系，不同的異常可以透過報警中心的訂閱配置關係投遞到真正能夠解決異常的人手裡。ACK 也沉澱了標準的異常以及對應標準異常處理的 SOP 手冊，發現報警時，會提示異常型別，以及為使用者提供處理異常的標準 SOP 修復流程。

## 基於 ACK 可觀測能力建設 FinOps 體系

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/462381b81ded462b9aeadccdcb72da4a~tplv-k3u1fbpfcp-zoom-1.image "14.png")

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

-   上雲之前——如何上雲，難規劃；

-   上雲之後——雲產品種類豐富，叢集資源型別也豐富，計費難；

-   高度 SaaS 化的應用部署在同一個叢集中進行共享，成本分賬難；

-   每年都會有新的業務生成和下線，叢集和資源的使用關係是動態的，難以進行持續的最佳化和治理；

-   此前一般使用 Excel 表對能力進行管理，在雲原生的場景下有豐富的使用者應用和有豐富的賬單資源型別，難以管理。

ACK 提供了雲原生企業 IT 成本治理方案，透過多維度的成本分攤和估算模型，為叢集的資源進行成本估算和分攤。可以透過根因的下鑽和趨勢的預測進行成本洞察，叢集上多個應用業務的成本可以細粒度下鑽，進行成本拆分。對多叢集場景上的成本提供了成熟的解決方案覆蓋，以及提供企業雲原生 IT 成本治理的專家服務。

此外，我們還推出了內建的應用資源畫像以及應用資源的智慧推薦，可以為資源推薦合適的成本以及進行預算控制，最後會根據不同的場景進行成本最佳化，如大資料、AI、遊戲等。

最後，支援多樣化場景，包括多雲和混合雲等都能在統一的平面進行展示和管理。

### 客戶案例

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7bf3ec19858047ab8fc4a92b70f0e0b3~tplv-k3u1fbpfcp-zoom-1.image "15.png")

中華財險作為網際網路金融的頭部公司，有千核級別的叢集規模，同時管理運維多個 SaaS 化線上業務，具有高度多租化、對業務穩定性要求高、對業務資源/成本趨勢敏感度高等行業特點。

中華財險從傳統 IT 架構到雲原生化的過程中，面臨著容量規劃難、算清成本難、閒置資源難發現以及成本最佳化和業務穩定性難以平衡的挑戰。

我們透過 ACK 的成本治理解決方案為它進行了壓測、容量規劃，透過 ACK 成本分析進行業務分賬的賬單 管理和分析，解決了閒置資源的最佳化，為其提供了分配資源的最佳化策略，最後透過容器服務提供了細粒度的容器部署以及彈性策略等最佳化手段。

上雲前，客戶叢集的資源分配閒置率高達 30%+，而透過我們提供的成本治理方案，閒置率降至 10% 以下，為行業領先水平。

瞭解更多可觀測能力，點選[此處](https://www.aliyun.com/product/arms)。

阿里雲 ACK 容器服務生產級可觀測體系建設實踐

相關文章