作者：李煌東、炎尋

摘要

阿里云目前推出了面向 Kubernetes 的一站式可觀測性系統(tǒng)，旨在解決 Kubernetes 環(huán)境下架構復雜度高、多語言&多協(xié)議并存帶來的運維難度高的問題，數(shù)據(jù)采集器采用當下火出天際的 eBPF 技術，產(chǎn)品上支持無侵入地采集應用黃金指標，構建成全局拓撲，極大地降低了公有云用戶運維 Kubernetes 的難度。

前言

背景與問題

當前，云原生技術主要是以容器技術為基礎圍繞著 Kubernetes 的標準化技術生態(tài)，通過標準可擴展的調(diào)度、網(wǎng)絡、存儲、容器運行時接口來提供基礎設施，同時通過標準可擴展的聲明式資源和控制器來提供運維能力，兩層標準化推進了細化的社會分工，各領域進一步提升規(guī)?；蛯I(yè)化，全面達到成本、效率、穩(wěn)定性的優(yōu)化，在這樣的背景下，大量公司都使用云原生技術來開發(fā)運維應用。正因為云原生技術帶來了更多可能性，當前業(yè)務應用出現(xiàn)了微服務眾多、多語言開發(fā)、多通信協(xié)議的特征，同時云原生技術本身將復雜度下移，給可觀測性帶來了更多挑戰(zhàn)：

1、混沌的微服務架構

業(yè)務架構因為分工問題，容易出現(xiàn)服務數(shù)量多，服務關系復雜的現(xiàn)象（如圖 1）。

圖 1 混沌的微服務架構（圖片來源見文末）

這樣會引發(fā)一系列問題：

• 無法回答當前的運行架構；
• 無法確定特定服務的下游依賴服務是否正常；
• 無法確定特定服務的上游依賴服務流量是否正常；
• 無法回答應用的 DNS 請求解析是否正常；
• 無法回答應用之間的連通性是否正確；
• ...

2、多語言應用

業(yè)務架構里面，不同的應用使用不同的語言編寫（如圖 2），傳統(tǒng)可觀測方法需要對不同語言使用不同的方法進行可觀測。

圖 2 多語言（圖片來源見文末）

這樣也會引發(fā)一系列問題：

• 不同語言需要不同埋點方法，甚至有的語言沒有現(xiàn)成的埋點方法；
• 埋點對應用性能影響無法簡單評估；

3、多通信協(xié)議

業(yè)務架構里面，不同的服務之間的通信協(xié)議也不同（如圖 3），傳統(tǒng)可觀測方法通常是在應用層特定通信接口進行埋點。

圖 3 多通信協(xié)議

這樣也會引發(fā)一系列問題：

• 不同通信協(xié)議因為不同的客戶端需要不同埋點方法，甚至有的通信協(xié)議沒有現(xiàn)成的埋點方法；
• 埋點對應用性能影響無法簡單評估；

4、Kubernetes 引入的端到端復雜度

復雜度是永恒的，我們只能找到方法來管理它，無法消除它，云原生技術的引入雖然減少了業(yè)務應用的復雜度，但是在整個軟件棧中，他只是將復雜度下移到容器虛擬化層，并沒有消除（如圖 4）。

圖 4 端到端軟件棧

這樣也會引發(fā)一系列問題：

• Deployment 的期望副本數(shù)和實際運行副本數(shù)不一致；
• Service 沒有后端，無法處理流量；
• Pod 無法創(chuàng)建或者調(diào)度；
• Pod 無法達到 Ready 狀態(tài)；
• Node 處于 Unknown 狀態(tài)；
• ...

解決思路與技術方案

為了解決上面的問題，我們需要使用一種支持多語言，多通信協(xié)議的技術，并且在產(chǎn)品層面盡可能得覆蓋軟件棧端到端的可觀測性需求，通過調(diào)研我們提出一種立足于容器界面和底層操作系統(tǒng)，向上關聯(lián)應用性能觀測的可觀測性解決思路（如圖 5）。

數(shù)據(jù)采集

圖 5 端到端可觀測性解決思路

我們以容器為核心，采集關聯(lián)的 Kubernetes 可觀測數(shù)據(jù)，與此同時，向下采集容器相關進程的系統(tǒng)和網(wǎng)絡可觀測數(shù)據(jù)，向上采集容器相關應用的性能數(shù)據(jù)，通過關聯(lián)關系將其串聯(lián)起來，完成端到端可觀測數(shù)據(jù)的覆蓋。

數(shù)據(jù)傳輸鏈路

我們的數(shù)據(jù)類型包含了指標，日志和鏈路，采用了 open telemetry collector 方案（如圖 6）支持統(tǒng)一的數(shù)據(jù)傳輸。

圖 6 OpenTelemetry Collector（圖片來源見文末）

數(shù)據(jù)存儲

背靠 ARMS 已有的基礎設施，指標通過 ARMS Prometheus 進行存儲，日志/鏈路通過 XTRACE 進行存儲。

產(chǎn)品核心功能介紹

核心場景上支持架構感知、錯慢請求分析、資源消耗分析、DNS 解析性能分析、外部性能分析、服務連通性分析和網(wǎng)絡流量分析。支持這些場景的基礎是產(chǎn)品在設計上遵循了從整體到個體的原則：先從全局視圖入手，發(fā)現(xiàn)異常的服務個體，如某個 Service，定位到這個 Service 后查看這個 Service 的黃金指標、關聯(lián)信息、Trace等進行進一步關聯(lián)分析。

圖 7 核心業(yè)務場景

永不過時的黃金指標

什么是黃金指標？用來可觀測性系統(tǒng)性能和狀態(tài)的最小集合：latency、traffic、errors、saturation。以下引自 SRE 圣經(jīng) Site Reliability Engineering 一書：

The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.

為什么黃金指標非常重要？一，直接了然地表達了系統(tǒng)是否正常對外服務。二，面向客戶的，能進一步評估對用戶的影響或事態(tài)的嚴重性，這樣能大量節(jié)省SRE或研發(fā)的時間，想象下如果我們?nèi)?CPU 使用率作為黃金指標，那么 SRE 或研發(fā)將會奔于疲命，因為 CPU 使用率高可能并不會造成多大的影響，尤其在運行平穩(wěn)的 Kubernetes 環(huán)境中。所以 Kubernetes 可觀測性支持這些黃金指標：

• 請求數(shù)/QPS
• 響應時間及分位數(shù)（P50、P90、P95、P99）
• 錯誤數(shù)
• 慢調(diào)用數(shù)

圖8 黃金指標

主要支持以下場景：

1、性能分析

2、慢調(diào)用分析

全局視角的應用拓補

不謀全局者，不足謀一域 。--諸葛亮

隨著當下技術架構、部署架構的復雜度越來越高，發(fā)生問題后定位問題變得越來越棘手，進而導致 MTTR 越來越高。另一個影響是對影響面的分析帶來非常大的挑戰(zhàn)，通常顧得了這頭顧不了那頭。因此，有一張像地圖一樣的大圖非常必要。全局拓撲具有以下特點：

• 系統(tǒng)架構感知：系統(tǒng)架構圖通常稱為程序員了解一個新系統(tǒng)的重要參考，當我們拿到一個系統(tǒng)，起碼我們得知道流量的入口在哪里，有哪些核心模塊，依賴了哪些內(nèi)部外部組件等。在異常定位過程中，有一張全局架構的圖對異常定位進程有非常大的推動作用。一個簡單電商應用的拓撲示例，整個架構一覽無遺：

圖 9 架構感知

• 依賴分析：有一些問題是出現(xiàn)在下游依賴，如果這個依賴不是自己團隊維護就會比較麻煩，當自己系統(tǒng)和下游系統(tǒng)沒有足夠的可觀測性的時候就更麻煩了，這種情況下就很難跟依賴的維護者講清楚問題。在我們的拓撲中，通過將黃金指標的上下游用調(diào)用關系連起來，形成了一張調(diào)用圖。邊作為依賴的可視化，能查看對應調(diào)用的黃金信號。有了黃金信號就能快速地分析下游依賴是否存在問題。下圖為底層服務調(diào)用微服務發(fā)生慢調(diào)用導致應用整體 RT 高的定位示例，從入口網(wǎng)關，到內(nèi)部服務，到 MySQL 服務，最終定位到發(fā)生慢 SQL 的語句：

圖 10 依賴分析

• 高可用分析：拓撲圖能方便地看出系統(tǒng)之間的交互，從而看出哪些系統(tǒng)是主要核心鏈路或者是被重度依賴的，比如 CoreDNS，幾乎所有的組件都會通過 CoreDNS 進行 DNS 解析，所以我們進一步看到可能存在的瓶頸，通過檢查 CoreDNS 的黃金指標預判應用是否健康、是否容量不足等。

圖 11 高可用分析

• 無侵入：跟螞蟻的 linkd 和集團的 eagleeye 不同的是，我們的方案是完全無侵入的。有時候我們之所以缺少某個方面的可觀測性，并不是說做不到，而是因為應用需要改代碼。作為 SRE 為了更好的可觀測性固然出發(fā)點很好，但是要讓全集團的應用 owner 陪你一起改代碼，顯然是不合適的。這時候就顯示出無侵入的威力了：應用不需要改代碼，也不需要重啟。所以在接入成本上是非常低的。

協(xié)議 Trace 方便根因定位

協(xié)議 Trace 區(qū)別于分布式追蹤，只跟蹤一次調(diào)用。協(xié)議 Trace 同樣是無入侵、語言無關的。如果請求內(nèi)容中存在分布式鏈路 TraceID，能自動識別出來，方便進一步下鉆到鏈路追蹤。應用層協(xié)議的請求、響應信息有助于對請求內(nèi)容、返回碼進行分析，從而知道具體哪個接口有問題。

圖 12 協(xié)議詳情

開箱即用的告警功能

任何一個可觀測性系統(tǒng)不支持告警是不合適的。1、默認模板下發(fā)，閾值經(jīng)過業(yè)界最佳實踐。

圖 13 告警

2、支持用戶多種配置方式

• 靜態(tài)閾值，用戶只需要配置閾值即可，不需要手動寫 PromQL
• 基于靈敏度調(diào)節(jié)的動態(tài)閾值，適合不好確定閾值的場景
• 兼容 PromQL，需要一定的學習成本，適合高級用戶

豐富的上下文關聯(lián)

datadog 的 CEO 在一次采訪中直言 datadog 的產(chǎn)品策略不是支持越多功能越好，而是思考怎樣在不同團隊和成員之間架起橋梁，盡可能把信息放在同一個頁面中（to bridge the gap between the teams and get everything on the same page）。產(chǎn)品設計上我們將關鍵的上下文信息關聯(lián)起來，方便不同背景的工程師理解，從而加速問題的排查。

目前我們關聯(lián)的上下文有告警信息、黃金指標、日志、Kubernetes 元信息等，同時不斷新增有價值的信息。比如告警信息，告警信息自動關聯(lián)到對應的服務或應用節(jié)點上，清晰地看到哪些應用有異常，點擊應用或告警能自動展開應用的詳情、告警詳情、應用的黃金指標，所有的動作都在一個頁面中進行：

圖 14 上下文關聯(lián)

其他

一、網(wǎng)絡性能可觀測性：

網(wǎng)絡性能導致響應時間變長是經(jīng)常遇到的問題，由于 TCP 底層機制屏蔽了一部分的復雜性，應用層對此是無感的，這對丟包率高、重傳率高這種場景帶來一些麻煩。Kubernetes 支持了重傳&丟包、TCP 連接信息來表征網(wǎng)絡狀況，下圖展示了重傳高導致 RT 高的例子：

圖 15 網(wǎng)絡性能可觀測性

eBPF 超能力揭秘

圖 16 數(shù)據(jù)處理流程

eBPF 相當于在內(nèi)核中構建了一個執(zhí)行引擎，通過內(nèi)核調(diào)用將這段程序 attach 到某個內(nèi)核事件上，做到監(jiān)聽內(nèi)核事件；有了事件我們就能進一步做協(xié)議推導，篩選出感興趣的協(xié)議，對事件進一步處理后放到 ringbuffer 或者 eBPF 自帶的數(shù)據(jù)結構 Map 中，供用戶態(tài)進程讀??；用戶態(tài)進程讀取這些數(shù)據(jù)后，進一步關聯(lián) Kubernetes 元數(shù)據(jù)后推送到存儲端。這是整體處理過程。

eBPF 的超能力體現(xiàn)在能訂閱各種內(nèi)核事件，如文件讀寫、網(wǎng)絡流量等，運行在 Kubernetes 中的容器或者 Pod 里的一切行為都是通過內(nèi)核系統(tǒng)調(diào)用來實現(xiàn)的，內(nèi)核知道機器上所有進程中發(fā)生的所有事情，所以內(nèi)核幾乎是可觀測性的最佳觀測點，這也是我們?yōu)槭裁催x擇 eBPF 的原因。另一個在內(nèi)核上做監(jiān)測的好處是應用不需要變更，也不需要重新編譯內(nèi)核，做到了真正意義上的無侵入。當集群里有幾十上百個應用的時候，無侵入的解決方案會幫上大忙。

eBPF作為新技術，人們對其有些擔憂是正常的，這里分別作簡單的回答：

1、eBPF 安全性如何？eBPF 代碼有諸多限制，如最大堆?？臻g當前為 512、最大指令數(shù)為 100 萬，這些限制的目的就是充分保證內(nèi)核運行時的安全性。

2、eBPF探針的性能如何？大約在 1% 左右。eBPF 的高性能主要體現(xiàn)在內(nèi)核中處理數(shù)據(jù)，減少數(shù)據(jù)在內(nèi)核態(tài)和用戶態(tài)之間的拷貝。簡單說就是數(shù)據(jù)在內(nèi)核里算好了再給用戶進程，比如一個 Gauge 值，以往的做法是將原始數(shù)據(jù)拷貝到用戶進程再計算。

總結

產(chǎn)品價值

阿里云 Kubernetes 可觀測性是一套針對 Kubernetes 集群開發(fā)的一站式可觀測性產(chǎn)品?；?Kubernetes 集群下的指標、應用鏈路、日志和事件，阿里云 Kubernetes 可觀測性旨在為 IT 開發(fā)運維人員提供整體的可觀測性方案。阿里云 Kubernetes 可觀測性具備以下特性：

• 代碼無侵入：通過旁路技術，不需要對代碼進行埋點即可獲取到豐富的網(wǎng)絡性能數(shù)據(jù)。

• 語言無關：在內(nèi)核層面進行網(wǎng)絡協(xié)議解析，支持任意語言，任意框架。

• 高性能：基于 eBPF 技術，能以極低的消耗獲取豐富的網(wǎng)絡性能數(shù)據(jù)。

• 強關聯(lián)：通過網(wǎng)絡拓撲，資源拓撲，資源關系從多個維度描述實體關聯(lián)，與此同時也支持各類數(shù)據(jù)（可觀測指標、鏈路、日志和事件）之間的關聯(lián)。

• 數(shù)據(jù)端到端覆蓋：涵蓋端到端軟件棧的觀測數(shù)據(jù)。

• 場景閉環(huán)：控制臺的場景設計，關聯(lián)起架構感知拓撲、應用可觀測性、Prometheus 可觀測性、云撥測、健康巡檢、事件中心、日志服務和云服務，包含應用理解，異常發(fā)現(xiàn)，異常定位的完整閉環(huán)。