DeepFlow在小米落地現(xiàn)狀以及挑戰(zhàn)

編者按：本文整理自小米集團(tuán)高級(jí)工程師譚槊在《藍(lán)鯨 X DeepFlow 可觀測(cè)性 Meetup》 中的分享實(shí)錄，詳細(xì)闡述了將DeepFlow 融入小米現(xiàn)有的可觀測(cè)體系中的一線落地經(jīng)驗(yàn)，用 DeepFlow 零插樁、全覆蓋的能力解決了現(xiàn)有痛點(diǎn)，還解決了傳統(tǒng)主機(jī)下 cBPF 如何關(guān)聯(lián)流與進(jìn)程、 LVS NAT 造成的服務(wù)拓?fù)鋽噫湹入y題，并展望了與 DeepFlow 合作共建的未來，構(gòu)建小米全新的可觀測(cè)體系新階段。

大家好，我是來自小米的譚槊，今天非常高興來參加 DeepFlow X 藍(lán)鯨的線下 Meetup。我先做一下自我介紹，我是目前在小米監(jiān)控系統(tǒng)組的高級(jí)工程師， 21 年加入小米。今天來這邊分享的目的是簡(jiǎn)短地介紹一下目前 DeepFlow 在小米在業(yè)務(wù)中的切入點(diǎn)。因?yàn)槲沂且痪€研發(fā)，所以我大致講一下在落地的過程中遇到了哪些挑戰(zhàn)，以及遇到這些挑戰(zhàn)后，我們和社區(qū)是如何努力去解決這些問題的。最后我講一下在小米內(nèi)部落地的一些業(yè)務(wù)。

我今天的分享分五部分展開：第一章會(huì)說一下小米可觀測(cè)性的現(xiàn)狀和規(guī)劃，這一部分大致介紹一下我們的團(tuán)隊(duì)，以及我們是干什么的。我們團(tuán)隊(duì)在項(xiàng)目中會(huì)有一個(gè)主線作為年度目標(biāo)，以及大致講一下團(tuán)隊(duì)項(xiàng)目的全景圖。第二章是為什么我們要引入 DeepFlow，在我們團(tuán)隊(duì)已經(jīng)有一個(gè)很明確的主線的情況下，引入 DeepFlow 的動(dòng)機(jī)和動(dòng)力是什么？第三章 DeepFlow 在小米內(nèi)部的部署架構(gòu)介紹，我這邊是從研發(fā)角度上而不是從產(chǎn)品角度上（來介紹部署架構(gòu)），研發(fā)層面上我們是通過技術(shù)上部署（和架構(gòu)調(diào)整），來介紹如何把 DeepFlow 從架構(gòu)上和我們小米內(nèi)部已有的一套可觀測(cè)性架構(gòu)進(jìn)行融合。第四章講我們已經(jīng)把 DeepFlow 部署起來了，在推廣它的時(shí)候遇到了一些挑戰(zhàn)，過程不是一帆風(fēng)順的，我們針對(duì)遇到的挑戰(zhàn)有技術(shù)上的一些解法，最后會(huì)給大家看一下，目前給我們的用戶，也就是給業(yè)務(wù)方帶來的可觀測(cè)產(chǎn)品，目前產(chǎn)品不是很多，會(huì)有一個(gè)長(zhǎng)期的如何跟 DeepFlow 展開深入合作的規(guī)劃路線圖。 我還補(bǔ)充一下，目前小米和 DeepFlow 合作的方式是以社區(qū)共建的形式合作的，我們這邊也投入人力，然后在社區(qū)中走的都是社區(qū)的正規(guī)流程，提 FR、PR，然后我本人也提供過多個(gè) FR 和多個(gè) PR。

小米可觀測(cè)性的現(xiàn)狀與規(guī)劃

第一章介紹我們團(tuán)隊(duì)，我們組為小米集團(tuán)提供日志、指標(biāo)、鏈路等可觀測(cè)性的數(shù)據(jù)，這是可觀測(cè)性數(shù)據(jù)的三個(gè)維度，通過平臺(tái)將這些數(shù)據(jù)結(jié)合，幫助業(yè)務(wù)發(fā)現(xiàn)、定位和解決問題。先介紹一下我們的歷史成果，以往我們主要面向的用戶群體是 SRE，我們的第一階段叫 SREOps，這個(gè)是我們提供的覆蓋全集團(tuán)的主機(jī)基礎(chǔ)指標(biāo)監(jiān)控能力。這里面主要就是技術(shù)（編者按：基礎(chǔ)設(shè)施）的指標(biāo)，包括 CPU，內(nèi)存，這塊我們已經(jīng)把它做完了，全集團(tuán)已經(jīng)鋪開了，所有的機(jī)器都裝了我們的采集器。這是第一階段。

第二階段主要是做可觀測(cè)性，集中突破 DevOps，我們的目標(biāo)用戶從 SRE，也就是專業(yè)的運(yùn)維同學(xué)，變成一線業(yè)務(wù)研發(fā)同學(xué)，這個(gè)階段是當(dāng)前的重點(diǎn)階段，也是我們現(xiàn)在做的一塊。目前這個(gè)平臺(tái)已經(jīng)差不多做完了，但是還沒有向集團(tuán)全部推出去，這是我們目前的目標(biāo)。然后未來愿景，也是我們今年的具有挑戰(zhàn)性的下一個(gè)目標(biāo)，就是在全集團(tuán)實(shí)現(xiàn) DevOps 能力，覆蓋任何應(yīng)用，覆蓋任何鏈路。

首先講下 Falcon，如果是做可觀測(cè)性的話，應(yīng)該對(duì) Falcon 這個(gè)產(chǎn)品比較了解。這是小米內(nèi)部孵化的，也是我們團(tuán)隊(duì)目前在維護(hù)的一塊，它重點(diǎn)面向的核心用戶群體是我們的 SRE 。Falcon 提供的都是主機(jī)粒度的一些指標(biāo)，比如 CPU、內(nèi)存，磁盤、網(wǎng)絡(luò) IO 之類。目前部署范圍是全部的主機(jī)，包括國(guó)內(nèi)、歐洲、新加坡、印度、美國(guó)等多個(gè)機(jī)房，超過上萬臺(tái)主機(jī)。目前這個(gè)產(chǎn)品功能已經(jīng)非常完善了，我們就不在上面繼續(xù)進(jìn)行深入迭代了。

除了我們自己做的 Falcon 之外，還有一些基于開源的知名項(xiàng)目（作為）我們的核心項(xiàng)目，我們做了一些日志鏈路和指標(biāo)的一些單品，所謂單品即它們是各自為一個(gè)平臺(tái)，沒有一個(gè)統(tǒng)一的平臺(tái)，相當(dāng)于我們給業(yè)務(wù)方提供的散點(diǎn)指標(biāo)數(shù)據(jù)，但是并沒有提供一套完整的平臺(tái)幫業(yè)務(wù)解決、發(fā)現(xiàn)問題或者定位問題。 日志相關(guān)的組件就是 Loki 和 ES，Loki 主要是面向于成本需求比較高的業(yè)務(wù)，ES 面向功能和性能要求比較高的業(yè)務(wù)。鏈路我就不多說了，就 OpenTelemetry 部分，我們跟他們架構(gòu)是一樣的，功能也是一樣的。 指標(biāo)相關(guān)的組件除了 Falcon 以外，F(xiàn)alcon 我們前面也說了它是主機(jī)維度監(jiān)控，而小米最近也在做云原生的發(fā)展，所以也引入了 Prometheus 來彌補(bǔ) Falcon 在云原生上的短板。

后面會(huì)重點(diǎn)介紹一下，這是我們今年在做的 DevOps 的能力，也就是 Hera 可觀測(cè)性平臺(tái)。Hera 可觀測(cè)平臺(tái)做了一件事情，在我們之前已經(jīng)有日志、鏈路和指標(biāo)這三個(gè)維度的基礎(chǔ)之上，把這些指標(biāo)進(jìn)行融合，提出了一個(gè)應(yīng)用為中心的維度，我們會(huì)有一個(gè)應(yīng)用中心（作為可觀測(cè)的入口）。 為什么要以應(yīng)用為中心？因?yàn)楝F(xiàn)在主流的 DevOps 的展開都更加貼近業(yè)務(wù)方，應(yīng)用對(duì)于業(yè)務(wù)方來說是更加親近的，相當(dāng)于我們把所有數(shù)據(jù)進(jìn)行了應(yīng)用維度的融合，右邊是我們對(duì)接的平臺(tái)，還是分兩部分，一個(gè)是小米內(nèi)部的容器平臺(tái)，另一個(gè)就是小米內(nèi)部的主機(jī)部署平臺(tái)，因?yàn)樾∶變?nèi)部在做云原生的時(shí)候遷移過程比較艱辛，導(dǎo)致它目前主機(jī)部署和云原生部署兩套方案是并存的。我們以往在主機(jī)平臺(tái)和容器化平臺(tái)看指標(biāo)監(jiān)控的時(shí)候，或者看日志的時(shí)候，是要切換到不同平臺(tái)看的，目前我們以應(yīng)用為中心，相當(dāng)于把這兩個(gè)平臺(tái)的細(xì)節(jié)對(duì)用戶屏蔽了，用戶現(xiàn)在就直接在我們應(yīng)用中心去看監(jiān)控?cái)?shù)據(jù)，以應(yīng)用為維度去觀測(cè)我們服務(wù)的可靠性。 這邊功能展開有應(yīng)用狀態(tài)、調(diào)用異常慢查詢、服務(wù)大盤，最后還有告警。應(yīng)用狀態(tài)，（簡(jiǎn)單講就是）應(yīng)用有時(shí)候會(huì)存在一些大量的 （HTTP）5XX 或者慢請(qǐng)求，應(yīng)用會(huì)進(jìn)入異常狀態(tài)，我們的業(yè)務(wù)方會(huì)收到報(bào)警。然后調(diào)用異常是基于 Request Scope （來區(qū)分）的，也就是 OTel 的那一套，（以及）火焰圖（這一套邏輯）。業(yè)務(wù)可以根據(jù) trace 單個(gè)的請(qǐng)求，比說單次的慢查詢或者慢請(qǐng)求，假設(shè)超過兩秒鐘，我們會(huì)進(jìn)行尾采樣，然后把它放到調(diào)用異常里面去，以事件的形式提供給用戶，然后用戶可以通過 Request ID 把整個(gè)鏈路完整地串聯(lián)起來。 慢查詢主要是以 DB 為維度的，我們可以看到那種請(qǐng)求比較慢的 SQL，比如說運(yùn)行超過十幾秒甚至更多的SQL，這個(gè)慢查詢掃描到的話會(huì)結(jié)合 DBA 的平臺(tái)給出慢查詢優(yōu)化的建議。然后服務(wù)大盤是自動(dòng)生成的，主要是一些七層協(xié)議，像 HTTP，像我們內(nèi)部的 RPC 框架 R.E.D.指標(biāo)，也就是黃金指標(biāo)的監(jiān)控。服務(wù)大盤雖然我們會(huì)自動(dòng)給它生成一個(gè)，但是有的用戶對(duì) SLA 的定義是不一樣的，所以這會(huì)是一個(gè)自定義大盤，我們的可觀測(cè)性平臺(tái)目前功能是這些，重點(diǎn)就以應(yīng)用為中心，目前是在向外推廣的階段，也是我們現(xiàn)在的工作重心。 有一個(gè)比較簡(jiǎn)單的使用案例，我們的用戶收到服務(wù)異常的告警，比如說 SLA 下降，他會(huì)打開并查看監(jiān)控，然后可以看到下降的到底是哪幾個(gè)接口，同時(shí)我們?cè)谌罩竞玩溌返淖粉櫪锩?，可以關(guān)聯(lián)到我們的異常事件，這下面有一個(gè) Trace ID，我們點(diǎn)開后就展開看火焰圖的 Span，就可以定位到那種耗時(shí)比較大的 Span。比如在這個(gè)場(chǎng)景下，我們發(fā)現(xiàn)一個(gè) MySQL 的請(qǐng)求執(zhí)行超過了 2 秒，就結(jié)合 DBA 系統(tǒng)得出故障分析，從我們的定位到發(fā)現(xiàn)問題到解決問題，最后到我們寫出報(bào)告，整個(gè)時(shí)間周期是 20 分鐘。 而且這個(gè)系統(tǒng)上手成本也很低，因?yàn)樗容^簡(jiǎn)單，我們的核心目標(biāo)就是幫助業(yè)務(wù)方可以快速地、簡(jiǎn)單地定位到問題并且快速解決，保證業(yè)務(wù)方的服務(wù)穩(wěn)定性好。

然后說一下我們團(tuán)隊(duì)目前的規(guī)劃，前面總結(jié)一下，首先是定義了 L1、L2、L3、L4 這四個(gè)工作階段，我們這個(gè)跟行業(yè)界內(nèi)的定義有一點(diǎn)小小區(qū)別，但是目前從上到下的規(guī)劃是越來越自動(dòng)化、接入成本越來越低，現(xiàn)在我們重點(diǎn)就是在 L3 這個(gè) DevOps 上面。

為什么要引入 DeepFlow？

前面我們就說了，現(xiàn)在工作重點(diǎn)是推 Hera，然后實(shí)現(xiàn) DevOps。那現(xiàn)在就說為什么我們要引入 DeepFlow？

在推 Hera 的過程中，我們會(huì)發(fā)現(xiàn)有幾個(gè)問題，首先最大的痛點(diǎn)是 Hera 探針接入成本比較高，覆蓋的應(yīng)用不全，如果我們要向全集團(tuán)全部的業(yè)務(wù)去推進(jìn) Hera 的話，那它必須要形成完整的覆蓋度。但我們?cè)谕频臅r(shí)候有一些很難推，有些業(yè)務(wù)可能有需求排期或者需求倒排之類的（編者按：探針的插碼可能被業(yè)務(wù)團(tuán)隊(duì)放到業(yè)務(wù)需求之后），接入成本高。那如果在我們的 Hera 探針接入后，我們是不是就不需要 DeepFlow 的自動(dòng)化采集？其實(shí)并不是，我們?cè)诮尤?Hera 探針后， DeepFlow 還是可以對(duì)我們 Hera 的探針進(jìn)行功能上的補(bǔ)全的。后面我也會(huì)詳細(xì)說一下，目前主要是這兩個(gè)痛點(diǎn)。

首先是 Hera，我們采取的是 OTel 探針，OTel 探針做可觀測(cè)性的話會(huì)比較了解，我們是基于社區(qū)版本做了一個(gè)簡(jiǎn)單的改造，對(duì)小米內(nèi)部的一些功能做了適配。我們可以看到有兩種接入方式，一個(gè)是 Golang 的應(yīng)用，一個(gè)是 Java 的應(yīng)用，其實(shí)它們兩個(gè)接入方式是不一樣的。 如果是 Go 應(yīng)用的話，我們內(nèi)部的話可能會(huì)有一個(gè)微服務(wù)框架，可以通過中間件的方式，把 OTel SDK 給加進(jìn)去，這樣它會(huì)在一些核心的地方，比如說網(wǎng)絡(luò)請(qǐng)求加入一些自動(dòng)上報(bào)的邏輯。但有的沒有用框架，那就得手動(dòng)地寫代碼了，你得在網(wǎng)絡(luò)調(diào)用地方手動(dòng)地去寫上報(bào)邏輯。 然后下面是 Java 應(yīng)用， Java 應(yīng)用比較簡(jiǎn)單點(diǎn)，它可以通過 Agent 的字節(jié)碼注入技術(shù)，自動(dòng)地把 OTel 探針注入到 Java 應(yīng)用中去。然后接入成本就是可能要改啟動(dòng)命令，雖然成本比較低，但也涉及到業(yè)務(wù)的發(fā)版。

這邊大致是 Hera 如果不用 DeepFlow，而用探針的接入方式來做接入。Java 的我們加一個(gè)命令行加入 Agent，這樣啟動(dòng)的時(shí)候就可以自動(dòng)地實(shí)現(xiàn)探針的功能了。

然后這是 Go，你可以看到它的整個(gè)流程是比較復(fù)雜的，首先要代碼改造，業(yè)務(wù)方代碼改造后他們一定不會(huì)全量上線的，可能要灰度驗(yàn)證一段時(shí)間，最后到上線需要至少一周。第二就是改造成本過高，業(yè)務(wù)方研發(fā)會(huì)降低優(yōu)先級(jí)，前面也說了，小米內(nèi)部有一些盈利的業(yè)務(wù)，他們可能不會(huì)優(yōu)先考慮到接探針，他們先要完成他們的活動(dòng)任務(wù)，這就會(huì)降低優(yōu)先級(jí)，我們推得就比較困難。第三就是很多業(yè)務(wù)研發(fā)對(duì)指標(biāo)鏈路上報(bào)的原理不太熟悉，特別 Golang 需要手動(dòng)去加探針，需要拉群溝通協(xié)作，然后可能我們需要安排一個(gè)人力，專門協(xié)助他們?nèi)ソ尤?Hera，對(duì)團(tuán)隊(duì)的整體的負(fù)擔(dān)比較大。 （右邊的扇形圖）最后給一個(gè)結(jié)論，我們現(xiàn)在大概接入 Java 的應(yīng)用大概有 5000 個(gè)，接入 Golang 的應(yīng)用只有 300 個(gè)，這個(gè)之間的比例關(guān)系就可以看出來，它接入的數(shù)量肯定是跟接入成本是相關(guān)的。

前面說接入的痛點(diǎn)后，我再說一下，其實(shí)我們已經(jīng)接入了 OTel 探針，實(shí)現(xiàn)了全鏈路追蹤的能力，那 Hera 全鏈路追蹤能力的應(yīng)用還存在什么問題？首先進(jìn)程內(nèi)的探針只能獲取一頭一尾，無法獲取 trace 到網(wǎng)絡(luò)的鏈路，這邊有個(gè)例子，請(qǐng)求從 Client 出去，跨專線、跨機(jī)房的業(yè)務(wù)，它會(huì)走專線，先到域名解析，然后要進(jìn)入容器網(wǎng)絡(luò)，進(jìn)容器網(wǎng)絡(luò)、出容器網(wǎng)絡(luò)，然后可能走專線的話要經(jīng)過網(wǎng)關(guān)，然后到專線，到另一個(gè)機(jī)房的網(wǎng)關(guān)，然后再進(jìn)七層代理，七層代理前面可能還有個(gè) LB，最后到 Server 的容器網(wǎng)絡(luò)，最后進(jìn)入 Server。 整個(gè)過程中有很多中間環(huán)節(jié)，但是目前我們加 OTel 探針的形式，只能獲取客戶端發(fā)送 Request 到 Server 收到 Response 中間的 Span，所以我們看到有個(gè)2秒的時(shí)延，但是我們并不知道這個(gè)2秒到底是因?yàn)?Server 的不穩(wěn)定，還是 Client 不穩(wěn)定，還是因?yàn)橹虚g網(wǎng)絡(luò)鏈路的不穩(wěn)定而導(dǎo)致的，這是我們現(xiàn)在的問題。 這邊有個(gè)圖，可以看到有個(gè)2秒鐘的一個(gè) Span，但它下面沒有細(xì)節(jié)，你只能告訴用戶就這個(gè)請(qǐng)求不穩(wěn)、很慢，但你不能告訴他哪里慢，這個(gè)就容易造成兩方的拉扯，服務(wù)端和服務(wù)依賴方（編者按：基礎(chǔ)設(shè)施）兩方拉扯，（最后發(fā)現(xiàn)）其實(shí)兩邊都沒有問題，而是網(wǎng)絡(luò)的問題。

網(wǎng)絡(luò)問題其實(shí)在業(yè)界中也是會(huì)頻繁發(fā)生的，我們?cè)?Hera 業(yè)務(wù)使用的時(shí)候也發(fā)生過。首先是海外專線因?yàn)槭┕け煌跀?，?dǎo)致業(yè)務(wù)出現(xiàn)大量的超時(shí)。還有機(jī)房的網(wǎng)絡(luò)割接，小米經(jīng)常在凌晨的時(shí)候會(huì)做一些網(wǎng)絡(luò)割接，這個(gè)過程雖然很快，但中間可能會(huì)出現(xiàn)一些臨時(shí)性的網(wǎng)絡(luò)抖動(dòng)，可用性就會(huì)造成波動(dòng)，凌晨的時(shí)候有很多業(yè)務(wù)方收到告警了，說服務(wù)的穩(wěn)定性、可用性下降。第三個(gè)就是交換機(jī)故障，導(dǎo)致后面的服務(wù)全部訪問超時(shí)全掛了。第四個(gè)就是域名解析負(fù)載高，響應(yīng)慢導(dǎo)致業(yè)務(wù)超時(shí)，這都是我們遇到過的一些問題，但這些 Hera 并不能回答到底是什么原因引起的。

我們說重點(diǎn)，為什么要選擇 DeepFlow。首先 DeepFlow 是真正的零侵?jǐn)_的自動(dòng)化采集，用戶不需要修改任何代碼發(fā)布版本，整個(gè)接入過程中是完全無感的。 我們之前要推業(yè)務(wù)方，一個(gè)模式就是我們會(huì)跟對(duì)方拉群溝通，然后跟對(duì)方說怎么排期，或者幫助他們?nèi)ソ鉀Q問題，甚至拉很多會(huì)去溝通接入的收益。但現(xiàn)在不需要了，現(xiàn)在我們?nèi)绻肴ジ麄兏采w Hera 的能力的話，我會(huì)直接地拉他們的產(chǎn)品運(yùn)維、一線運(yùn)維或者他們的 leader，我們就告訴他們說要在你們這個(gè)試點(diǎn)用 DeepFlow 了，他們?nèi)绻麑?duì)性能不滿意的話，我們會(huì)甩一個(gè)壓測(cè)文檔，我告訴他們整個(gè)接入過程是無感的，不需要他們投入任何人力，只需要運(yùn)維看一下有沒有問題就行了。這個(gè)接入過程非常順暢，接入也很快，可以一下接入大量的業(yè)務(wù)。 第二點(diǎn)就是我們當(dāng)時(shí)調(diào)研的時(shí)候，其實(shí) DeepFlow 是有競(jìng)品的，像 Pixie 或者是其他的，我們都當(dāng)時(shí)都調(diào)研了一遍，我們?yōu)槭裁催x擇 DeepFlow 去適配 Hera 作為基礎(chǔ)采集功能，是因?yàn)?Hera 的 L7 的看板，跟 DeepFlow 提供的官網(wǎng)的看板是一模一樣的，沒有任何區(qū)別，包括我們協(xié)議的解析?？梢赃@樣說，DeepFlow 向下兼容了 Hera 的看板，里面包括 Dubbo、HTTP、Redis、MySQL 的黃金指標(biāo)，我們?cè)?DeepFlow 中都可以找到，是和 Hera 完全一樣，就不用做任何改造了。 第三點(diǎn)，這個(gè)是一個(gè)比較偏小米集團(tuán)的功能訴求，我們對(duì)比其他的幾個(gè)競(jìng)品 cBPF 這方面做得不是特別好，我們對(duì)比了一下 eBPF 能力，固然很多產(chǎn)品都做得很強(qiáng)，但 cBPF 的能力能做到 eBPF 80% 的能力的產(chǎn)品其實(shí)很少。 所以說我們當(dāng)時(shí)選擇 cBPF 能力比較強(qiáng)的 DeepFlow，因?yàn)檫m配內(nèi)核和兼容小米當(dāng)前的主機(jī)環(huán)境，這個(gè)我們后面也會(huì)說的。小米有一些比較偏傳統(tǒng)的業(yè)務(wù)，它的主機(jī)內(nèi)核版本很老，有 3.0 以下版本的內(nèi)核。

然后是剛剛解釋的無法回答用戶是否因?yàn)榫W(wǎng)絡(luò)問題引起的故障的案例，我們現(xiàn)在可以回答了。首先 DeepFlow 是原生支持網(wǎng)絡(luò) Span 的，這是 DeepFlow 的核心特性，它可以零侵?jǐn)_地生成網(wǎng)絡(luò) Span，采集的點(diǎn)非常細(xì)。我們當(dāng)時(shí)也調(diào)研了，從容器網(wǎng)卡出來到交換機(jī)，到路由到 NAT，每一層的網(wǎng)絡(luò) Span 都可以生成。不過對(duì)于小米內(nèi)部其實(shí)我們不需要這么精細(xì)，這個(gè)功能已經(jīng)超出了我們預(yù)期很多了。其實(shí)我們只需要知道客戶端網(wǎng)卡到服務(wù)端網(wǎng)卡之間的網(wǎng)絡(luò) Span，然后這個(gè) Span 我們的業(yè)務(wù)研發(fā)同學(xué)看不懂，你只要告訴他是網(wǎng)絡(luò)問題，然后去找網(wǎng)絡(luò)組就可以了。所以結(jié)論就是，我們只需要一個(gè)客戶端網(wǎng)卡到服務(wù)端網(wǎng)卡中間的一個(gè)網(wǎng)絡(luò) Span 就可以解答我們用戶的問題了。 第二點(diǎn)也是非常重要的，也是當(dāng)時(shí)我們選型的目的，Hera 當(dāng)前的數(shù)據(jù)源，也就是我們的 ES，還有和我們的鏈路追蹤的 OTel 的 ES 數(shù)據(jù)源，和 DeepFlow 的 Clickhouse 里面 Span 是天然打通的。在我們調(diào)研之前，社區(qū)都已經(jīng)給出方案了，開發(fā)成本是很低的，之前也咨詢過 DeepFlow 團(tuán)隊(duì)提供了兩套方案，第一套方案是直接把 ES 數(shù)據(jù)導(dǎo)到 Clickhouse 里去，但這個(gè)方案對(duì)我們的侵?jǐn)_太大了，本身我們的內(nèi)部的 ES 也有很多同學(xué)在維護(hù)，所以我們選取了第二套方案，我們通過 DeepFlow 提供的 API 的能力，把 DeepFlow 的 Span 以 W3C 那種標(biāo)準(zhǔn)的協(xié)議格式導(dǎo)到我們 Hera 的當(dāng)前鏈路的數(shù)據(jù)中去，然后我們通過 Trace ID 以及 Parent Span ID 關(guān)聯(lián)。由于 OTel 是一個(gè)標(biāo)準(zhǔn)的協(xié)議，所以是天然打通的，開發(fā)成本很低，我們當(dāng)時(shí)試了一下，這個(gè)功能還沒有正式地去推，但是我們已經(jīng)在調(diào)研中了，目前我們調(diào)研發(fā)現(xiàn)整個(gè)接入過程應(yīng)該是很快的，開發(fā)成本很低。

還要感謝的就是 DeepFlow 社區(qū)支持力度很大，團(tuán)隊(duì)也非常專業(yè)。我們提的一些 FR 都是以雙周為一個(gè)節(jié)點(diǎn)進(jìn)行推進(jìn)的，這是我們?nèi)〉玫囊恍┏删?。后面也?huì)說一下，首先是加強(qiáng) cBPF 能力，滿足業(yè)務(wù)需求的前提下，我們的理論覆蓋率，意思就是到底有多少個(gè)主機(jī)能夠覆蓋到我們 Hera 的特性，通過 DeepFlow 的覆蓋能力實(shí)現(xiàn) Hera 的功能，最開始 30% 是因?yàn)槲覀冎挥?30% 支持 eBPF，然后我們有 cBPF 能力加強(qiáng)后，60% 的機(jī)器就可以實(shí)現(xiàn) Hera 的無侵?jǐn)_的部署能力了。但它仍然不是100%，后面還有一些更老的內(nèi)核的主機(jī)，比如說像 3.x 老內(nèi)核主機(jī)，可能在 cBPF 的能力上面也有缺陷。我后來又經(jīng)過跟社區(qū)一起努力，從 60% 又提到 80%，這個(gè)時(shí)候其實(shí)離全量覆蓋很近了。 最后還有 20% 是最老的 2.6 版本內(nèi)核。其實(shí)我們也適配了，但它是存在一些技術(shù)問題的，比如像 Cgroups 的隔離性，它做得不是特別好。后來我們出于安全的考慮就沒有去推這20%，當(dāng)然社區(qū)也在出方案，我們最后還是會(huì)全量覆蓋。最后優(yōu)化應(yīng)用的拓?fù)鋱D的展示，為用戶提供更清晰的拓?fù)?a target="_blank">信息。

DeepFlow 在小米的部署模式

接下來講一下我們大致在小米中的部署框架，大家使用 DeepFlow 產(chǎn)品的時(shí)候知道， DeepFlow 的 Agent 采集器部署是分兩種方式去部署的，一個(gè)是云原生部署，一個(gè)是傳統(tǒng)主機(jī)部署，就是云主機(jī)或者物理主機(jī)的方式。小米內(nèi)部我們前面也說了，有兩套平臺(tái)，一個(gè)是主機(jī)應(yīng)用平臺(tái)，一個(gè)是容器應(yīng)用平臺(tái)。所以說我們部署方式也分了兩套。

首先是傳統(tǒng)主機(jī)的部署架構(gòu)，我們做了一個(gè)比較巧妙的設(shè)計(jì)，我們之前也說到有個(gè) Falcon，即 SREOps 的產(chǎn)品，我們的采集器其實(shí)已經(jīng)覆蓋集團(tuán)所有主機(jī)了。這個(gè)時(shí)候我們要推 DeepFlow，如何把它也向全集團(tuán)去推呢？其實(shí)我們可以搭我們的 Falcon Agent 的順風(fēng)車，我們把 Falcon 的 Agent 進(jìn)行了改造，把 DeepFlow 的功能融合進(jìn)去了。這邊可以看到綠色的方框內(nèi)是我們采集對(duì)象的主機(jī)，上面有 DeepFlow Agent，它對(duì)接的是 cBPF 和 eBPF 的探針，然后 Falcon Agent 采集的是主機(jī)的基礎(chǔ)指標(biāo)，包括 CPU、內(nèi)存。最下面我們還有個(gè)插件，就是之前 DeepFlow 采集的 Flow Metrics 和 Flow Log 這些信息，它是沒有應(yīng)用信息的，我們通過這個(gè)插件跟我們的應(yīng)用發(fā)布系統(tǒng)聯(lián)動(dòng)，用戶發(fā)應(yīng)用的時(shí)候會(huì)在主機(jī)上留應(yīng)用元信息，包括應(yīng)用的細(xì)節(jié)，比如進(jìn)程也即 PID 的映射，然后這個(gè)插件就是把這個(gè)映射同步給 DeepFlow 的集群，這樣就可以給 DeepFlow 的流打上我們的應(yīng)用信息，也滿足了 Hera 的以應(yīng)用為核心的需求，最下面有一個(gè) Super Agent，其實(shí)就是把三個(gè) Agent 進(jìn)行融合，進(jìn)行統(tǒng)一化的部署。然后右邊做一個(gè)簡(jiǎn)單的管控面，這個(gè)管控面是我們內(nèi)部用的，我們可以看到有多少個(gè)機(jī)器覆蓋了 DeepFlow 的 Agent，有多少個(gè)開啟采集配置，采集配置下發(fā)分兩部分，一個(gè)是靜態(tài)配置的下發(fā)，需要重啟 Agent，還有一個(gè)是 DeepFlow 本身的動(dòng)態(tài)配置下發(fā)，比如說它采集規(guī)則還有其他比較靈活的配置，也集成到配置下發(fā)這個(gè)功能模塊里面了。 最后是我們的 Agent 編譯部署平臺(tái)，我們有一個(gè)全量更新的過程，通過發(fā)布工單，比如發(fā)布到全集團(tuán)的機(jī)器，然后一個(gè)一個(gè)地去更新，比如 DeepFlow 有功能要更新或者有 bug 要解決，我們就通過工單系統(tǒng)一次性把它全量升級(jí)。另外還有自動(dòng)化的發(fā)布腳本，小米集團(tuán)所有新采購機(jī)器預(yù)裝的時(shí)候，我們會(huì)執(zhí)行這個(gè)腳本，它從 FDS 里面拉 Super Agent 的二進(jìn)制包，然后把 Super Agent 部署到新機(jī)器上面去。 最下面（紅色箭頭）是一個(gè)數(shù)據(jù)鏈路，這個(gè)數(shù)據(jù)面相當(dāng)于 DeepFlow 通過 Super Agent 傳到 DeepFlow 集群里面去，這是傳統(tǒng)主機(jī)部署。后面有容器平臺(tái)與部署，這個(gè)就是開箱即用了，就是社區(qū)的 Helm 部署，我們直接執(zhí)行一下 10 分鐘就可以搞定。

這個(gè)服務(wù)端的架構(gòu)中間綠色部分就是開源社區(qū)提供的能力，我們提供了幾個(gè)用戶的終端，也就是 Hera 的界面。首先就是我們剛才說的 L7 協(xié)議的，比如 Dubbo 或者 HTTP 的一個(gè) R.E.D. 的黃金指標(biāo)，我們是通過 Grafana， 再通過 DeepFlow 的插件，直接以看板的形式暴露給用戶的。 然后下面是鏈路，其實(shí)我們前面也說到了，首先我們的鏈路是基于 OTel 探針的，不是替換，我們是加強(qiáng) OTel 探針采集的 Span，OTel 探針會(huì)通過 MQ 把我們的 Span 數(shù)據(jù)傳到 ES 里面去，同時(shí)我們會(huì)有個(gè)服務(wù)，在給用戶鏈路火焰圖的時(shí)候，會(huì)同時(shí)從 ES 里面去查 Span，包括業(yè)務(wù)自己上報(bào)的 Span 和 DeepFlow 生成的網(wǎng)絡(luò) Span 和系統(tǒng) Span，我們會(huì)把它融合在一起形成融合視圖，最后展現(xiàn)給用戶。 然后這邊有一個(gè)比較有意思的功能，有一個(gè) DeepFlow 同步模塊，因?yàn)?DeepFlow 的數(shù)據(jù)都存在 Clickhouse 里，它會(huì)定期同步應(yīng)用到應(yīng)用的拓?fù)潢P(guān)系，并導(dǎo)到隊(duì)列的一個(gè) T+1 作業(yè)里面去，會(huì)生成一個(gè)靜態(tài)拓?fù)鋱D。 靜態(tài)拓?fù)鋱D這個(gè)功能，大致用于觀察應(yīng)用到應(yīng)用之間實(shí)時(shí)的狀態(tài)，它的主要作用是解答一下應(yīng)用在系統(tǒng)架構(gòu)層面上有什么樣的拓?fù)潢P(guān)系。這個(gè)時(shí)候我們會(huì)導(dǎo)到 T+1 的作業(yè)，導(dǎo)入到 Doris 里面去暴露給用戶，這樣用戶就可以看到自己應(yīng)用上下連著哪些應(yīng)用，或者是整個(gè)集團(tuán)下面有哪些應(yīng)用，以一個(gè)全局的視角。這個(gè)前面可能也還有個(gè) Redis 緩存，對(duì)我們經(jīng)常查的一些應(yīng)用進(jìn)行加速，然后下面有一個(gè)應(yīng)用隊(duì)列，我們之前也說了 Hera 是以應(yīng)用為核心，所以它會(huì)定期從 Clickhouse 里把我們打標(biāo)應(yīng)用的元信息同步到 ES 里面去，這樣在我們 Hera 平臺(tái)里面搜索的時(shí)候，用戶就可以看到，即使沒有接入探針的應(yīng)用，它也可以在 Hera 平臺(tái)里面搜索出來。當(dāng)然我們可以通過過濾器把它過濾掉。

DeepFlow 在小米的落地

后說說我們遇到的挑戰(zhàn)和解法。首先這個(gè)是我們核心的目標(biāo)，盡可能在不插碼的前提下，讓更多的用戶體驗(yàn)到 Hera 的完整功能?？赡懿皇?100%，但是 80% 到 90% 是一個(gè)目標(biāo)，這個(gè)目標(biāo)的實(shí)現(xiàn)過程中我們遇到很多挑戰(zhàn)，DeepFlow 社區(qū)的專業(yè)團(tuán)隊(duì)的支持很多，都高效解決了，這邊主要是兩個(gè)挑戰(zhàn)，一個(gè)是小米重度依賴 cBPF 能力，另一個(gè)就是拓?fù)鋱D隱藏 LVS。 首先就是依賴于 cBPF 能力，因?yàn)樾∶椎膬?nèi)核版本比較老，很多機(jī)器裝不了 eBPF 的探針，所以我們使用了 cBPF 采集，但 cPPF 采集在社區(qū)最開始的一個(gè)版本里不支持進(jìn)程粒度的拓?fù)潢P(guān)系。我舉個(gè)例子，左邊和右邊各一個(gè)主機(jī)A、B，小米內(nèi)部的應(yīng)用是要混部的，因?yàn)橐岣咧鳈C(jī)的資源利用率，我們?cè)谧筮呏鳈C(jī) A 里面混部 A 和 B 兩個(gè)應(yīng)用，右邊主機(jī) B 混部 C 和 D 兩個(gè)應(yīng)用，這時(shí)候我們通過 DeepFlow 的 cBPF 能力檢測(cè)到 HTTP 5XX 的 status code ，那應(yīng)用肯定是有問題的，但這個(gè)時(shí)候我們定位不到是哪個(gè)應(yīng)用到哪個(gè)應(yīng)用的問題，比如實(shí)際上是應(yīng)用 A 到應(yīng)用 D 有異常，應(yīng)用 B 到應(yīng)用 C 沒有異常。業(yè)務(wù)去排查問題就會(huì)一臉懵，到底是哪個(gè)有問題？這也不能滿足我們以應(yīng)用為中心的訴求，這些問題在 eBPF 里面沒有遇到，但在 cBPF 里面遇到過。

我們做了一個(gè)解法，當(dāng)時(shí)跟社區(qū)提了一個(gè) FR，這個(gè)應(yīng)該是社區(qū)的第一個(gè) FR，跟 DeepFlow 共同制定了一個(gè)方案，我們會(huì)定期同步 Socket 與 Process 的關(guān)聯(lián)關(guān)系，DeepFlow 給的數(shù)據(jù)是一個(gè) Flow，F(xiàn)low 其實(shí)是個(gè)五元組，包含目的端的 Port IP 和我們的源端的 Port IP，我們通過流的五元組定義一個(gè) Socket，然后 Socket 在 Linux 下可以跟 Process 進(jìn)行關(guān)聯(lián)，把流和應(yīng)用 ID 關(guān)聯(lián)在一起，后面我們根據(jù)流量的五元組信息鎖定 Socket，從而鎖定應(yīng)用進(jìn)程。 最后是我們前面提到的 DeepFlow 插件，我們會(huì)從發(fā)布系統(tǒng)中獲取進(jìn)程與應(yīng)用關(guān)聯(lián)，這樣我們就可以把五元組，也就是 Flow 信息跟我們的應(yīng)用進(jìn)行關(guān)聯(lián)，從而推算出比較有用的應(yīng)用信息。表格里的是我們后來通過 FR 加入的功能，左邊是我們的源應(yīng)用，右邊是我們的目的應(yīng)用，取代了之前 host IP 到 host IP 這樣的一個(gè)拓?fù)潢P(guān)系圖，這樣就可以回答用戶應(yīng)用到應(yīng)用的關(guān)聯(lián)了。

然后其他的優(yōu)化做了哪些？首先是 Process 過濾，在 Linux 里面進(jìn)程還是比較多的，有一些無效的噪音（編者按：非業(yè)務(wù)應(yīng)用進(jìn)程），比如說腳本或者內(nèi)核進(jìn)程，這些就是無效的 Process。我們通過正則對(duì)一些無效的噪音進(jìn)行過濾，降低了我們的上報(bào)頻率，減少開銷。后面是子進(jìn)程打標(biāo)簽，之前說過我們是通過流關(guān)聯(lián)到進(jìn)程，從而關(guān)聯(lián)到應(yīng)用。但很多架構(gòu)，比如說 python 多進(jìn)程架構(gòu)，或者像 nginx，它不是單進(jìn)程架構(gòu)，它是個(gè)多進(jìn)程架構(gòu)，有父進(jìn)程還有子進(jìn)程，所以有時(shí)候關(guān)聯(lián)的是子進(jìn)程，但并不是真正要關(guān)聯(lián)的應(yīng)用。因?yàn)閼?yīng)用的標(biāo)簽是給父進(jìn)程打元數(shù)據(jù)，記錄的是應(yīng)用元數(shù)據(jù)到父進(jìn)程的 PID，這個(gè)時(shí)候流的子進(jìn)程信息是沒有用的。所以我們也做了樹狀分析，我們通過父進(jìn)程不斷 fork 子進(jìn)程，然后我們給子進(jìn)程打上和父進(jìn)程同樣的應(yīng)用標(biāo)簽，這樣就不會(huì)讓用戶產(chǎn)生疑問。 后面還有一個(gè)問題，經(jīng)常創(chuàng)建短連接的應(yīng)用，Socket 的創(chuàng)建數(shù)量會(huì)比較多，會(huì)導(dǎo)致我們?cè)趦?nèi)存中的 Process 到 Socket 的映射表基數(shù)膨脹，最后導(dǎo)致了 OOM，這里面我們做了一些優(yōu)化，通過過濾小于 10 秒的短連接，我們把基數(shù)進(jìn)行控制，因?yàn)榇蟛糠衷谖覀兗瘓F(tuán)內(nèi)部的一些框架，比如說 GRPC ，或者是 Dubbo 也好，或者是 HTTP 也好，它和 MySQL 和 Redis 都是基于連接池的，所以一般來說大部分都是長(zhǎng)連接，只有極少數(shù)是短連接。所以過濾掉短連接其實(shí)對(duì)黃金指標(biāo)的監(jiān)控影響也不是特別大。 最后一個(gè)是比較難理解的，在 DeepFlow 的 Flow 中，有客戶端到服務(wù)端的概念，到底哪個(gè) IP 是客戶端，或者哪個(gè)應(yīng)用是客戶端？這個(gè)方向比較難判，之前出現(xiàn)過亂序的現(xiàn)象，因?yàn)樵诰W(wǎng)絡(luò)層其實(shí)沒有客戶端、服務(wù)端這個(gè)概念，DeepFlow 解法是通過抓 SYN 報(bào)文，判斷是誰先發(fā)起握手的，先發(fā)起握手的就更像是客戶端。但是在我們部署 Agent 的時(shí)候，可能這個(gè)連接它已經(jīng)建立很久，它可能是個(gè)長(zhǎng)連接，所以我們會(huì)捕獲不到 SYN 報(bào)文。這個(gè)時(shí)候我們通過一些動(dòng)態(tài)的算法，分析 TCP 里面流量的一些行為，然后不斷地給這個(gè)方向進(jìn)行投票，如果它得分比較低的時(shí)候，我們就把這個(gè)錯(cuò)誤的方向給過濾掉了，我們只過濾那種得分比較高的，比如滿分是 255 分，我們只過濾 200 分以上的流量。這樣的話它在概率上就是接近 100% 的正確率。

挑戰(zhàn)二是這個(gè)是拓?fù)鋱D如何隱藏 LVS 。我們還是從應(yīng)用到應(yīng)用的監(jiān)控來分析，不同的應(yīng)用之間可能存在 LB，就是 LVS，然后 LVS 大家也知道它有個(gè)特點(diǎn)，它有個(gè) VIP。我們這邊看的就是 Client 連接中間 LVS 的時(shí)候，連接的是個(gè)VIP，然后 LVS 出來的時(shí)候又有一個(gè) VIP'，甚至可能還有多個(gè)不同的 VIP'，因?yàn)樗赡苡卸嗑W(wǎng)卡，最后到我們的 Server 端。如果是正常的情況下，我們用戶是其實(shí)是想知道 Client 到 Server，也就是應(yīng)用 A 到應(yīng)用 B 的調(diào)用關(guān)系的，但是因?yàn)橛羞@個(gè) LVS 的情況，導(dǎo)致我們整個(gè)的鏈路中斷了，形成這樣的效應(yīng)，拓?fù)鋱D上面全都是我們的客戶端，然后下面全都是 VIP，我們的服務(wù)端就看不到了，因?yàn)橹虚g鏈路斷開了。因?yàn)槭菑目蛻舳藶橐暯情_始做遍歷的，怎么看不到客戶端 —— 服務(wù)端的拓?fù)鋱D了，這個(gè)對(duì)用戶造成非常大的干擾，生成大量無意義的無效的拓?fù)湫畔ⅰ?/p>

而解法的話，我們通過兩個(gè)方法解決，首先我們通過 TOA 獲取真實(shí)的客戶端 IP，中間這種服務(wù)端通過流量分析，抓的就是 VIP'，也就是 LVS 出網(wǎng)卡的 IP 到 RS 的流信息。但是我們?nèi)绾未┩?LVS？其實(shí)我們可以通過這個(gè)技術(shù)，在我們集團(tuán)內(nèi)部的 LVS 模塊，當(dāng)然也不僅是我們集團(tuán)內(nèi)部，很多公有云也是一樣的，它會(huì)在發(fā)送 SYN package 的時(shí)候，或者第一次推 PSH 包的時(shí)候，把客戶端的真實(shí)的 IP 和 Port 放到 TCP Option 里面去，可以從 TCP Option 里面解析它，來獲取真實(shí)的客戶端 IP 和真實(shí)客戶端的 Port，這個(gè)就解了如何穿透 LVS 獲取真實(shí)客戶端 IP 的技術(shù)難題。還有一個(gè)技術(shù)難題，就是我們知道客戶端的真實(shí) IP，但是我們存在混部的現(xiàn)象，得到的是主機(jī)的 IP，不知道到底是哪個(gè)應(yīng)用。

所以下面我們還做了另一個(gè)優(yōu)化，我們通過 Server 獲取 PID，同時(shí)通過這個(gè)方法推導(dǎo)出客戶端上的 PID。我們知道客戶端上的 PID 后，就自然知道客戶端上的應(yīng)用了。具體我們可以看最上面一條鏈路，我們?nèi)绾捂i定一個(gè)PID？比如在我們的服務(wù)端安裝了一個(gè) DeepFlow Agent，抓了一個(gè)流，這個(gè)流的 PID 其實(shí)是可以知道的，因?yàn)橛形逶M信息，我們可以鎖定 Socket，然后同時(shí)鎖定到 PID。但是我們順著鏈路往回溯我們客戶端的 PID 的時(shí)候，中間斷開了，因?yàn)槲覀儾恢?VIP 到 VIP' 的映射關(guān)系，在主機(jī) A 有兩個(gè) Socket，所以我們不知道是哪個(gè) Socket 發(fā)起這個(gè)連接，所以也不知道是哪個(gè) PID。這個(gè)時(shí)候我們跟 DeepFlow 合作，做 LVS 平臺(tái)注入的功能，把 LVS 中間拓?fù)湫畔⒆⑷氲?DeepFlow 中間去，這樣整個(gè)過程就可以串聯(lián)在一起， DeepFlow 會(huì)自動(dòng)地把這兩個(gè)完全不相干的 Socket 通過拓?fù)潢P(guān)系把它關(guān)聯(lián)在一起。

我們遇到很多挑戰(zhàn)，通過技術(shù)的方式已經(jīng)攻破了，但中間還遇到一些其他的挑戰(zhàn)，目前還在解決的過程中。首先是 Dubbo 的線程池監(jiān)控，我們做的 cBPF 是不侵入用戶的進(jìn)程的，它沒辦法通過 Uprobe 侵入到用戶的進(jìn)程中去。所以我們無法知道 Dubbo 線程池的監(jiān)控，而 Dubbo 有一些線程池相關(guān)的都是應(yīng)用級(jí)別的，所以我們不能到應(yīng)用中去獲取這些信息。后面第二個(gè)就是 OTel 探針， Span 的程序運(yùn)行上下文缺失，OTel 探針在異常的時(shí)候，會(huì)把調(diào)用堆棧給打印出來，這個(gè)東西是要基于進(jìn)程內(nèi)部的方式，你得通過 eBPF 侵入到進(jìn)程中去做，我們 cBPF 沒有這個(gè)能力。 然后第三個(gè)就是業(yè)務(wù)日志，業(yè)務(wù)日志打印的東西都是高度自定義化的，這也需要我們侵入到業(yè)務(wù)進(jìn)程中去做的，目前我們也沒有辦法去做。還有就是只對(duì)長(zhǎng)連接進(jìn)行標(biāo)注，Socket 太多無法全部上報(bào)，我們前面也說了 Socket 如果全上報(bào)的話，那就太大了，內(nèi)存就會(huì)爆掉，我們就只對(duì)長(zhǎng)連接進(jìn)行標(biāo)注，這個(gè)也導(dǎo)致一部分的連接無法在系統(tǒng)中監(jiān)控到，這個(gè)問題不大。我剛才也說了，大部分就是 95% 的應(yīng)該都是長(zhǎng)連接。最后還存在一個(gè)問題，對(duì)于部分大數(shù)據(jù)業(yè)務(wù)場(chǎng)景吞吐高的，會(huì)達(dá)到 Agent 的抓包上限，因?yàn)楸旧?cBPF 探針的原理其實(shí)和抓包原理是一樣的，有個(gè) buffer ，如果吞吐量比較高的話，抓包達(dá)到上限它就會(huì)丟包，這樣就會(huì)導(dǎo)致結(jié)果不是特別準(zhǔn)。

最后說一下當(dāng)前的一個(gè)落地場(chǎng)景，我們第一個(gè)落地的產(chǎn)品是 Hera 的靜態(tài)拓?fù)鋱D，前面是我們說的是系統(tǒng)架構(gòu)層面上，不是實(shí)時(shí)的，而是一個(gè) T+1 的延時(shí)作業(yè)。我們主要是干什么用的？首先是回答各個(gè)部門之間有多少個(gè)應(yīng)用。比如一級(jí)部門下面有二級(jí)部門，二級(jí)部門下面可能還有不同的業(yè)務(wù)線，業(yè)務(wù)線各個(gè)應(yīng)用有多少個(gè)？我們要提供一個(gè)全景的視圖，第二個(gè)是回答部門和部門之間存在多少個(gè)調(diào)用關(guān)系，這個(gè)調(diào)用關(guān)系的話，看部門之間，比如說不同業(yè)務(wù)線之間是不是有耦合現(xiàn)象。第三個(gè)就是回答應(yīng)用之間的相互依賴關(guān)系，這個(gè)就是精確到之前說的部門維度，這時(shí)候就到服務(wù)應(yīng)用的維度了，服務(wù)之間是不是存在依賴關(guān)系？然后第四個(gè)就是回答各個(gè)應(yīng)用之間是否存在流量？這個(gè)是服務(wù)下線用的，經(jīng)常會(huì)有人問我們這個(gè)服務(wù)能不能下了，我們把這個(gè)靜態(tài)拓?fù)浣o他一看，說這個(gè)已經(jīng)有三天沒有流量了，然后他們就可以把這個(gè)服務(wù)給下掉了。 這邊分兩個(gè)（視圖），一個(gè)是部門視圖，一個(gè)是應(yīng)用視圖。如果你不斷放大 scope，就是你想看的應(yīng)用遍歷層級(jí)，會(huì)發(fā)現(xiàn)應(yīng)用越來越多，所以我們把它聚合成一個(gè)部門視圖，這中間這幾個(gè)圓，可以點(diǎn)擊它展開成我們的應(yīng)用視圖，上面都是我們的二級(jí)部門，然后是我們不同的業(yè)務(wù)線，業(yè)務(wù)線就是最上面的藍(lán)色和紅色之間是有調(diào)用關(guān)系的，中間有一個(gè)是未接入 Hera 的應(yīng)用，這個(gè)就是我們通過 ePPF 要通過 DeepFlow 探針自動(dòng)采集到的，這時(shí)候我們就知道有多少個(gè)應(yīng)用沒有接入到 Hera ，可以推我們的業(yè)務(wù)方去把這些東西接探針。 右邊是我們應(yīng)用視角的鏈路拓?fù)?，這個(gè)本身其實(shí)沒有接 DeepFlow，之前我們是看了兩個(gè)服務(wù)之間調(diào)用關(guān)系，接入 DeepFlow 后就我們會(huì)發(fā)現(xiàn)這幾個(gè)服務(wù)他們還不是這么簡(jiǎn)單。它下面還會(huì)依賴 Redis，依賴 nacos，還有 ES 的能力，這樣相當(dāng)于把那些沒有接入探針的應(yīng)用，我們都把它給掃描出來了，就形成了一個(gè)全景圖。

最后我們深知在這個(gè) DeepFlow 的能力耕耘上面還是做得不夠，我們還是希望它能做更多的事，這是我們大致的規(guī)劃。首先是平臺(tái)層面上，我們的目標(biāo)目前是 80%（的可觀測(cè)覆蓋率），這個(gè)目標(biāo)其實(shí)已經(jīng)快達(dá)成了。然后容器平臺(tái)是我們下個(gè)季度要去推的，這個(gè)應(yīng)該推得很快，估計(jì)下個(gè)季度就可以把它全部覆蓋了。然后三個(gè)核心維度的話我們主要去加強(qiáng)使用鏈路的功能，前提是一定要先接入 OTel 探針，然后我們通過加強(qiáng)網(wǎng)絡(luò) Span 的形式，把這個(gè)功能加強(qiáng)。 然后指標(biāo)看板其實(shí)是可以完全覆蓋的，用戶在不接入 OTel 探針情況下，我們會(huì)給他一個(gè)體驗(yàn)版，最初的一個(gè)版本原型，可以看到大致的監(jiān)控大盤，服務(wù)的接口的 SLA，都可以通過 Grafana 暴露出來。然后中間日志的話我們就先不去 touch 了，暫時(shí)搞不了。左邊是我們的暴露給用戶的核心能力，上面就是應(yīng)用狀態(tài)。 然后在這邊有一個(gè)調(diào)用異常，也是我們加強(qiáng)的能力，這個(gè)不是覆蓋，也是加強(qiáng)的，之前可以看到應(yīng)用的調(diào)用異常，現(xiàn)在我們可以看到網(wǎng)絡(luò)的調(diào)用異常。慢查詢是可以完全覆蓋的，因?yàn)?DeepFlow 天然支持 MySQL 的協(xié)議解析，你不需要接探針就可以看到慢查詢。后面是一個(gè)服務(wù)大盤，我們說的 SLA 的一些黃金指標(biāo)，就是 HTTP Dubbo 接口的 R.E.D.指標(biāo)，我們也可以完全地展示給我們用戶，然后報(bào)警這一塊我們目前在調(diào)研，因?yàn)橹?DeepFlow 沒有 Prometheus 的能力，我們整個(gè)報(bào)警是基于 Prometheus 去做的。所以我們?cè)谡{(diào)研，可能這一塊也可以做了。整個(gè)目標(biāo)就是 Hera 不接入探針和接入探針，能覆蓋到 90%。通過 DeepFlow 的 Agent，然后加 OTel 探針的能力覆蓋到 90%，這是我們最終的目標(biāo)。

這邊有一個(gè) Roadmap，這個(gè) Roadmap 其實(shí)我們和 DeepFlow 團(tuán)隊(duì)合作應(yīng)該是從今年年初或者去年年底開始的，我們前期有個(gè)預(yù)研和體驗(yàn)階段，還存在兩個(gè)團(tuán)隊(duì)之間溝通的階段。這個(gè)我們從一、二、三月份，從最開始的預(yù)研到我們剛才說的遇到一些挑戰(zhàn)，都把它解決了。 同時(shí)我們也推出一個(gè)靜態(tài)拓?fù)鋱D的產(chǎn)品功能，這個(gè)是我們到 3 月份為止實(shí)際上的功能試點(diǎn)，我們剩下的重心就要把它全量鋪開，然后開始在全集團(tuán)的主機(jī)上進(jìn)行覆蓋，我們會(huì)在容器平臺(tái)上進(jìn)行覆蓋，所謂覆蓋就是去部署探針，中間可能會(huì)涉及到機(jī)房的建設(shè)，集群的建設(shè)，資源的問題。這是我現(xiàn)在在做的事情，下周回去就開始做了。到8月中旬為止。我們把功能全部給鋪開，最后我們產(chǎn)出一個(gè)完整的產(chǎn)品，給用戶創(chuàng)造一個(gè)價(jià)值，給他一個(gè)真正的、DeepFlow 完整能力，我們暴露給用戶這個(gè)完整產(chǎn)品的話，可能在 10 月份和 12 月份進(jìn)行一次密集的迭代，把我們剛才要做的功能全都給迭代上去。