編者按：本文整理自小米集團(tuán)高級工程師譚槊在《藍(lán)鯨 X DeepFlow 可觀測性 Meetup》 中的分享實(shí)錄，詳細(xì)闡述了將DeepFlow 融入小米現(xiàn)有的可觀測體系中的一線落地經(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)建小米全新的可觀測體系新階段。

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

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

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

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

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

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

除了我們自己做的 Falcon 之外，還有一些基于開源的知名項(xiàng)目（作為）我們的核心項(xiàng)目，我們做了一些日志鏈路和指標(biāo)的一些單品，所謂單品即它們是各自為一個平臺，沒有一個統(tǒng)一的平臺，相當(dāng)于我們給業(yè)務(wù)方提供的散點(diǎn)指標(biāo)數(shù)據(jù)，但是并沒有提供一套完整的平臺幫業(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 在云原生上的短板。

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

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

為什么要引入 DeepFlow？

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

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

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

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

然后這是 Go，你可以看到它的整個流程是比較復(fù)雜的，首先要代碼改造，業(yè)務(wù)方代碼改造后他們一定不會全量上線的，可能要灰度驗(yàn)證一段時間，最后到上線需要至少一周。第二就是改造成本過高，業(yè)務(wù)方研發(fā)會降低優(yōu)先級，前面也說了，小米內(nèi)部有一些盈利的業(yè)務(wù)，他們可能不會優(yōu)先考慮到接探針，他們先要完成他們的活動任務(wù)，這就會降低優(yōu)先級，我們推得就比較困難。第三就是很多業(yè)務(wù)研發(fā)對指標(biāo)鏈路上報的原理不太熟悉，特別 Golang 需要手動去加探針，需要拉群溝通協(xié)作，然后可能我們需要安排一個人力，專門協(xié)助他們?nèi)ソ尤?Hera，對團(tuán)隊(duì)的整體的負(fù)擔(dān)比較大。 （右邊的扇形圖）最后給一個結(jié)論，我們現(xiàn)在大概接入 Java 的應(yīng)用大概有 5000 個，接入 Golang 的應(yīng)用只有 300 個，這個之間的比例關(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ò)的鏈路，這邊有個例子，請求從 Client 出去，跨專線、跨機(jī)房的業(yè)務(wù)，它會走專線，先到域名解析，然后要進(jìn)入容器網(wǎng)絡(luò)，進(jìn)容器網(wǎng)絡(luò)、出容器網(wǎng)絡(luò)，然后可能走專線的話要經(jīng)過網(wǎng)關(guān)，然后到專線，到另一個機(jī)房的網(wǎng)關(guān)，然后再進(jìn)七層代理，七層代理前面可能還有個 LB，最后到 Server 的容器網(wǎng)絡(luò)，最后進(jìn)入 Server。 整個過程中有很多中間環(huán)節(jié)，但是目前我們加 OTel 探針的形式，只能獲取客戶端發(fā)送 Request 到 Server 收到 Response 中間的 Span，所以我們看到有個2秒的時延，但是我們并不知道這個2秒到底是因?yàn)?Server 的不穩(wěn)定，還是 Client 不穩(wěn)定，還是因?yàn)橹虚g網(wǎng)絡(luò)鏈路的不穩(wěn)定而導(dǎo)致的，這是我們現(xiàn)在的問題。 這邊有個圖，可以看到有個2秒鐘的一個 Span，但它下面沒有細(xì)節(jié)，你只能告訴用戶就這個請求不穩(wěn)、很慢，但你不能告訴他哪里慢，這個就容易造成兩方的拉扯，服務(wù)端和服務(wù)依賴方（編者按：基礎(chǔ)設(shè)施）兩方拉扯，（最后發(fā)現(xiàn)）其實(shí)兩邊都沒有問題，而是網(wǎng)絡(luò)的問題。

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

我們說重點(diǎn)，為什么要選擇 DeepFlow。首先 DeepFlow 是真正的零侵?jǐn)_的自動化采集，用戶不需要修改任何代碼發(fā)布版本，整個接入過程中是完全無感的。 我們之前要推業(yè)務(wù)方，一個模式就是我們會跟對方拉群溝通，然后跟對方說怎么排期，或者幫助他們?nèi)ソ鉀Q問題，甚至拉很多會去溝通接入的收益。但現(xiàn)在不需要了，現(xiàn)在我們?nèi)绻肴ジ麄兏采w Hera 的能力的話，我會直接地拉他們的產(chǎn)品運(yùn)維、一線運(yùn)維或者他們的 leader，我們就告訴他們說要在你們這個試點(diǎn)用 DeepFlow 了，他們?nèi)绻麑π阅懿粷M意的話，我們會甩一個壓測文檔，我告訴他們整個接入過程是無感的，不需要他們投入任何人力，只需要運(yùn)維看一下有沒有問題就行了。這個接入過程非常順暢，接入也很快，可以一下接入大量的業(yè)務(wù)。 第二點(diǎn)就是我們當(dāng)時調(diào)研的時候，其實(shí) DeepFlow 是有競品的，像 Pixie 或者是其他的，我們都當(dāng)時都調(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)，我們在 DeepFlow 中都可以找到，是和 Hera 完全一樣，就不用做任何改造了。 第三點(diǎn)，這個是一個比較偏小米集團(tuán)的功能訴求，我們對比其他的幾個競品 cBPF 這方面做得不是特別好，我們對比了一下 eBPF 能力，固然很多產(chǎn)品都做得很強(qiáng)，但 cBPF 的能力能做到 eBPF 80% 的能力的產(chǎn)品其實(shí)很少。 所以說我們當(dāng)時選擇 cBPF 能力比較強(qiáng)的 DeepFlow，因?yàn)檫m配內(nèi)核和兼容小米當(dāng)前的主機(jī)環(huán)境，這個我們后面也會說的。小米有一些比較偏傳統(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)時也調(diào)研了，從容器網(wǎng)卡出來到交換機(jī)，到路由到 NAT，每一層的網(wǎng)絡(luò) Span 都可以生成。不過對于小米內(nèi)部其實(shí)我們不需要這么精細(xì)，這個功能已經(jīng)超出了我們預(yù)期很多了。其實(shí)我們只需要知道客戶端網(wǎng)卡到服務(wù)端網(wǎng)卡之間的網(wǎng)絡(luò) Span，然后這個 Span 我們的業(yè)務(wù)研發(fā)同學(xué)看不懂，你只要告訴他是網(wǎng)絡(luò)問題，然后去找網(wǎng)絡(luò)組就可以了。所以結(jié)論就是，我們只需要一個客戶端網(wǎng)卡到服務(wù)端網(wǎng)卡中間的一個網(wǎng)絡(luò) Span 就可以解答我們用戶的問題了。 第二點(diǎn)也是非常重要的，也是當(dāng)時我們選型的目的，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 里去，但這個方案對我們的侵?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 是一個標(biāo)準(zhǔn)的協(xié)議，所以是天然打通的，開發(fā)成本很低，我們當(dāng)時試了一下，這個功能還沒有正式地去推，但是我們已經(jīng)在調(diào)研中了，目前我們調(diào)研發(fā)現(xiàn)整個接入過程應(yīng)該是很快的，開發(fā)成本很低。

還要感謝的就是 DeepFlow 社區(qū)支持力度很大，團(tuán)隊(duì)也非常專業(yè)。我們提的一些 FR 都是以雙周為一個節(jié)點(diǎn)進(jìn)行推進(jìn)的，這是我們?nèi)〉玫囊恍┏删汀：竺嬉矔f一下，首先是加強(qiáng) cBPF 能力，滿足業(yè)務(wù)需求的前提下，我們的理論覆蓋率，意思就是到底有多少個主機(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%，這個時候其實(shí)離全量覆蓋很近了。 最后還有 20% 是最老的 2.6 版本內(nèi)核。其實(shí)我們也適配了，但它是存在一些技術(shù)問題的，比如像 Cgroups 的隔離性，它做得不是特別好。后來我們出于安全的考慮就沒有去推這20%，當(dāng)然社區(qū)也在出方案，我們最后還是會全量覆蓋。最后優(yōu)化應(yīng)用的拓?fù)鋱D的展示，為用戶提供更清晰的拓?fù)?a target="_blank">信息。

DeepFlow 在小米的部署模式

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

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

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

DeepFlow 在小米的落地

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

我們做了一個解法，當(dāng)時跟社區(qū)提了一個 FR，這個應(yīng)該是社區(qū)的第一個 FR，跟 DeepFlow 共同制定了一個方案，我們會定期同步 Socket 與 Process 的關(guān)聯(lián)關(guān)系，DeepFlow 給的數(shù)據(jù)是一個 Flow，F(xiàn)low 其實(shí)是個五元組，包含目的端的 Port IP 和我們的源端的 Port IP，我們通過流的五元組定義一個 Socket，然后 Socket 在 Linux 下可以跟 Process 進(jìn)行關(guān)聯(lián)，把流和應(yīng)用 ID 關(guān)聯(lián)在一起，后面我們根據(jù)流量的五元組信息鎖定 Socket，從而鎖定應(yīng)用進(jìn)程。 最后是我們前面提到的 DeepFlow 插件，我們會從發(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 這樣的一個拓?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。我們通過正則對一些無效的噪音進(jìn)行過濾，降低了我們的上報頻率，減少開銷。后面是子進(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)，它是個多進(jìn)程架構(gòu)，有父進(jìn)程還有子進(jìn)程，所以有時候關(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，這個時候流的子進(jìn)程信息是沒有用的。所以我們也做了樹狀分析，我們通過父進(jìn)程不斷 fork 子進(jìn)程，然后我們給子進(jìn)程打上和父進(jìn)程同樣的應(yīng)用標(biāo)簽，這樣就不會讓用戶產(chǎn)生疑問。 后面還有一個問題，經(jīng)常創(chuàng)建短連接的應(yīng)用，Socket 的創(chuàng)建數(shù)量會比較多，會導(dǎo)致我們在內(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 都是基于連接池的，所以一般來說大部分都是長連接，只有極少數(shù)是短連接。所以過濾掉短連接其實(shí)對黃金指標(biāo)的監(jiān)控影響也不是特別大。 最后一個是比較難理解的，在 DeepFlow 的 Flow 中，有客戶端到服務(wù)端的概念，到底哪個 IP 是客戶端，或者哪個應(yīng)用是客戶端？這個方向比較難判，之前出現(xiàn)過亂序的現(xiàn)象，因?yàn)樵诰W(wǎng)絡(luò)層其實(shí)沒有客戶端、服務(wù)端這個概念，DeepFlow 解法是通過抓 SYN 報文，判斷是誰先發(fā)起握手的，先發(fā)起握手的就更像是客戶端。但是在我們部署 Agent 的時候，可能這個連接它已經(jīng)建立很久，它可能是個長連接，所以我們會捕獲不到 SYN 報文。這個時候我們通過一些動態(tài)的算法，分析 TCP 里面流量的一些行為，然后不斷地給這個方向進(jìn)行投票，如果它得分比較低的時候，我們就把這個錯誤的方向給過濾掉了，我們只過濾那種得分比較高的，比如滿分是 255 分，我們只過濾 200 分以上的流量。這樣的話它在概率上就是接近 100% 的正確率。

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

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

所以下面我們還做了另一個優(yōu)化，我們通過 Server 獲取 PID，同時通過這個方法推導(dǎo)出客戶端上的 PID。我們知道客戶端上的 PID 后，就自然知道客戶端上的應(yīng)用了。具體我們可以看最上面一條鏈路，我們?nèi)绾捂i定一個PID？比如在我們的服務(wù)端安裝了一個 DeepFlow Agent，抓了一個流，這個流的 PID 其實(shí)是可以知道的，因?yàn)橛形逶M信息，我們可以鎖定 Socket，然后同時鎖定到 PID。但是我們順著鏈路往回溯我們客戶端的 PID 的時候，中間斷開了，因?yàn)槲覀儾恢?VIP 到 VIP' 的映射關(guān)系，在主機(jī) A 有兩個 Socket，所以我們不知道是哪個 Socket 發(fā)起這個連接，所以也不知道是哪個 PID。這個時候我們跟 DeepFlow 合作，做 LVS 平臺注入的功能，把 LVS 中間拓?fù)湫畔⒆⑷氲?DeepFlow 中間去，這樣整個過程就可以串聯(lián)在一起， DeepFlow 會自動地把這兩個完全不相干的 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)用級別的，所以我們不能到應(yīng)用中去獲取這些信息。后面第二個就是 OTel 探針， Span 的程序運(yùn)行上下文缺失，OTel 探針在異常的時候，會把調(diào)用堆棧給打印出來，這個東西是要基于進(jìn)程內(nèi)部的方式，你得通過 eBPF 侵入到進(jìn)程中去做，我們 cBPF 沒有這個能力。 然后第三個就是業(yè)務(wù)日志，業(yè)務(wù)日志打印的東西都是高度自定義化的，這也需要我們侵入到業(yè)務(wù)進(jìn)程中去做的，目前我們也沒有辦法去做。還有就是只對長連接進(jìn)行標(biāo)注，Socket 太多無法全部上報，我們前面也說了 Socket 如果全上報的話，那就太大了，內(nèi)存就會爆掉，我們就只對長連接進(jìn)行標(biāo)注，這個也導(dǎo)致一部分的連接無法在系統(tǒng)中監(jiān)控到，這個問題不大。我剛才也說了，大部分就是 95% 的應(yīng)該都是長連接。最后還存在一個問題，對于部分大數(shù)據(jù)業(yè)務(wù)場景吞吐高的，會達(dá)到 Agent 的抓包上限，因?yàn)楸旧?cBPF 探針的原理其實(shí)和抓包原理是一樣的，有個 buffer ，如果吞吐量比較高的話，抓包達(dá)到上限它就會丟包，這樣就會導(dǎo)致結(jié)果不是特別準(zhǔn)。

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

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

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