作者：李煌東、炎尋

摘要

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

前言

背景與問(wèn)題

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

1、混沌的微服務(wù)架構(gòu)

業(yè)務(wù)架構(gòu)因?yàn)榉止?wèn)題，容易出現(xiàn)服務(wù)數(shù)量多，服務(wù)關(guān)系復(fù)雜的現(xiàn)象（如圖 1）。

圖 1 混沌的微服務(wù)架構(gòu)（圖片來(lái)源見(jiàn)文末）

這樣會(huì)引發(fā)一系列問(wèn)題：

• 無(wú)法回答當(dāng)前的運(yùn)行架構(gòu)；
• 無(wú)法確定特定服務(wù)的下游依賴(lài)服務(wù)是否正常；
• 無(wú)法確定特定服務(wù)的上游依賴(lài)服務(wù)流量是否正常；
• 無(wú)法回答應(yīng)用的 DNS 請(qǐng)求解析是否正常；
• 無(wú)法回答應(yīng)用之間的連通性是否正確；
• ...

2、多語(yǔ)言應(yīng)用

業(yè)務(wù)架構(gòu)里面，不同的應(yīng)用使用不同的語(yǔ)言編寫(xiě)（如圖 2），傳統(tǒng)可觀測(cè)方法需要對(duì)不同語(yǔ)言使用不同的方法進(jìn)行可觀測(cè)。

圖 2 多語(yǔ)言（圖片來(lái)源見(jiàn)文末）

這樣也會(huì)引發(fā)一系列問(wèn)題：

• 不同語(yǔ)言需要不同埋點(diǎn)方法，甚至有的語(yǔ)言沒(méi)有現(xiàn)成的埋點(diǎn)方法；
• 埋點(diǎn)對(duì)應(yīng)用性能影響無(wú)法簡(jiǎn)單評(píng)估；

3、多通信協(xié)議

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

圖 3 多通信協(xié)議

這樣也會(huì)引發(fā)一系列問(wèn)題：

• 不同通信協(xié)議因?yàn)椴煌目蛻舳诵枰煌顸c(diǎn)方法，甚至有的通信協(xié)議沒(méi)有現(xiàn)成的埋點(diǎn)方法；
• 埋點(diǎn)對(duì)應(yīng)用性能影響無(wú)法簡(jiǎn)單評(píng)估；

4、Kubernetes 引入的端到端復(fù)雜度

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

圖 4 端到端軟件棧

這樣也會(huì)引發(fā)一系列問(wèn)題：

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

解決思路與技術(shù)方案

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

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

圖 5 端到端可觀測(cè)性解決思路

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

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

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

圖 6 OpenTelemetry Collector（圖片來(lái)源見(jiàn)文末）

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

背靠 ARMS 已有的基礎(chǔ)設(shè)施，指標(biāo)通過(guò) ARMS Prometheus 進(jìn)行存儲(chǔ)，日志/鏈路通過(guò) XTRACE 進(jìn)行存儲(chǔ)。

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

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

圖 7 核心業(yè)務(wù)場(chǎng)景

永不過(guò)時(shí)的黃金指標(biāo)

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

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.

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

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

圖8 黃金指標(biāo)

主要支持以下場(chǎng)景：

1、性能分析

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

全局視角的應(yīng)用拓補(bǔ)

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

隨著當(dāng)下技術(shù)架構(gòu)、部署架構(gòu)的復(fù)雜度越來(lái)越高，發(fā)生問(wèn)題后定位問(wèn)題變得越來(lái)越棘手，進(jìn)而導(dǎo)致 MTTR 越來(lái)越高。另一個(gè)影響是對(duì)影響面的分析帶來(lái)非常大的挑戰(zhàn)，通常顧得了這頭顧不了那頭。因此，有一張像地圖一樣的大圖非常必要。全局拓?fù)渚哂幸韵绿攸c(diǎn)：

• 系統(tǒng)架構(gòu)感知：系統(tǒng)架構(gòu)圖通常稱(chēng)為程序員了解一個(gè)新系統(tǒng)的重要參考，當(dāng)我們拿到一個(gè)系統(tǒng)，起碼我們得知道流量的入口在哪里，有哪些核心模塊，依賴(lài)了哪些內(nèi)部外部組件等。在異常定位過(guò)程中，有一張全局架構(gòu)的圖對(duì)異常定位進(jìn)程有非常大的推動(dòng)作用。一個(gè)簡(jiǎn)單電商應(yīng)用的拓?fù)涫纠?，整個(gè)架構(gòu)一覽無(wú)遺：

圖 9 架構(gòu)感知

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

圖 10 依賴(lài)分析

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

圖 11 高可用分析

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

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

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

圖 12 協(xié)議詳情

開(kāi)箱即用的告警功能

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

圖 13 告警

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

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

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

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

目前我們關(guān)聯(lián)的上下文有告警信息、黃金指標(biāo)、日志、Kubernetes 元信息等，同時(shí)不斷新增有價(jià)值的信息。比如告警信息，告警信息自動(dòng)關(guān)聯(lián)到對(duì)應(yīng)的服務(wù)或應(yīng)用節(jié)點(diǎn)上，清晰地看到哪些應(yīng)用有異常，點(diǎn)擊應(yīng)用或告警能自動(dòng)展開(kāi)應(yīng)用的詳情、告警詳情、應(yīng)用的黃金指標(biāo)，所有的動(dòng)作都在一個(gè)頁(yè)面中進(jìn)行：

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

其他

一、網(wǎng)絡(luò)性能可觀測(cè)性：

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

圖 15 網(wǎng)絡(luò)性能可觀測(cè)性

eBPF 超能力揭秘

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

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

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

eBPF作為新技術(shù)，人們對(duì)其有些擔(dān)憂是正常的，這里分別作簡(jiǎn)單的回答：

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

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

總結(jié)

產(chǎn)品價(jià)值

阿里云 Kubernetes 可觀測(cè)性是一套針對(duì) Kubernetes 集群開(kāi)發(fā)的一站式可觀測(cè)性產(chǎn)品。基于 Kubernetes 集群下的指標(biāo)、應(yīng)用鏈路、日志和事件，阿里云 Kubernetes 可觀測(cè)性旨在為 IT 開(kāi)發(fā)運(yùn)維人員提供整體的可觀測(cè)性方案。阿里云 Kubernetes 可觀測(cè)性具備以下特性：

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

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

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

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

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

• 場(chǎng)景閉環(huán)：控制臺(tái)的場(chǎng)景設(shè)計(jì)，關(guān)聯(lián)起架構(gòu)感知拓?fù)?、?yīng)用可觀測(cè)性、Prometheus 可觀測(cè)性、云撥測(cè)、健康巡檢、事件中心、日志服務(wù)和云服務(wù)，包含應(yīng)用理解，異常發(fā)現(xiàn)，異常定位的完整閉環(huán)。