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

編者按：本文整理自小米集團高級工程師譚槊在《藍鯨 X DeepFlow 可觀測性 Meetup》 中的分享實錄，詳細闡述了將DeepFlow 融入小米現有的可觀測體系中的一線落地經驗，用 DeepFlow 零插樁、全覆蓋的能力解決了現有痛點，還解決了傳統(tǒng)主機下 cBPF 如何關聯流與進程、 LVS NAT 造成的服務拓撲斷鏈等難題，并展望了與 DeepFlow 合作共建的未來，構建小米全新的可觀測體系新階段。

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

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

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

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

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

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

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

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

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

為什么要引入 DeepFlow？

前面我們就說了，現在工作重點是推 Hera，然后實現 DevOps。那現在就說為什么我們要引入 DeepFlow？

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

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

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

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

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

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

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

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

還要感謝的就是 DeepFlow 社區(qū)支持力度很大，團隊也非常專業(yè)。我們提的一些 FR 都是以雙周為一個節(jié)點進行推進的，這是我們取得的一些成就。后面也會說一下，首先是加強 cBPF 能力，滿足業(yè)務需求的前提下，我們的理論覆蓋率，意思就是到底有多少個主機能夠覆蓋到我們 Hera 的特性，通過 DeepFlow 的覆蓋能力實現 Hera 的功能，最開始 30% 是因為我們只有 30% 支持 eBPF，然后我們有 cBPF 能力加強后，60% 的機器就可以實現 Hera 的無侵擾的部署能力了。但它仍然不是100%，后面還有一些更老的內核的主機，比如說像 3.x 老內核主機，可能在 cBPF 的能力上面也有缺陷。我后來又經過跟社區(qū)一起努力，從 60% 又提到 80%，這個時候其實離全量覆蓋很近了。 最后還有 20% 是最老的 2.6 版本內核。其實我們也適配了，但它是存在一些技術問題的，比如像 Cgroups 的隔離性，它做得不是特別好。后來我們出于安全的考慮就沒有去推這20%，當然社區(qū)也在出方案，我們最后還是會全量覆蓋。最后優(yōu)化應用的拓撲圖的展示，為用戶提供更清晰的拓撲信息。

DeepFlow 在小米的部署模式

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

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

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

DeepFlow 在小米的落地

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

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

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

挑戰(zhàn)二是這個是拓撲圖如何隱藏 LVS 。我們還是從應用到應用的監(jiān)控來分析，不同的應用之間可能存在 LB，就是 LVS，然后 LVS 大家也知道它有個特點，它有個 VIP。我們這邊看的就是 Client 連接中間 LVS 的時候，連接的是個VIP，然后 LVS 出來的時候又有一個 VIP'，甚至可能還有多個不同的 VIP'，因為它可能有多網卡，最后到我們的 Server 端。如果是正常的情況下，我們用戶是其實是想知道 Client 到 Server，也就是應用 A 到應用 B 的調用關系的，但是因為有這個 LVS 的情況，導致我們整個的鏈路中斷了，形成這樣的效應，拓撲圖上面全都是我們的客戶端，然后下面全都是 VIP，我們的服務端就看不到了，因為中間鏈路斷開了。因為是從客戶端為視角開始做遍歷的，怎么看不到客戶端 —— 服務端的拓撲圖了，這個對用戶造成非常大的干擾，生成大量無意義的無效的拓撲信息。

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

所以下面我們還做了另一個優(yōu)化，我們通過 Server 獲取 PID，同時通過這個方法推導出客戶端上的 PID。我們知道客戶端上的 PID 后，就自然知道客戶端上的應用了。具體我們可以看最上面一條鏈路，我們如何鎖定一個PID？比如在我們的服務端安裝了一個 DeepFlow Agent，抓了一個流，這個流的 PID 其實是可以知道的，因為有五元組信息，我們可以鎖定 Socket，然后同時鎖定到 PID。但是我們順著鏈路往回溯我們客戶端的 PID 的時候，中間斷開了，因為我們不知道 VIP 到 VIP' 的映射關系，在主機 A 有兩個 Socket，所以我們不知道是哪個 Socket 發(fā)起這個連接，所以也不知道是哪個 PID。這個時候我們跟 DeepFlow 合作，做 LVS 平臺注入的功能，把 LVS 中間拓撲信息注入到 DeepFlow 中間去，這樣整個過程就可以串聯在一起， DeepFlow 會自動地把這兩個完全不相干的 Socket 通過拓撲關系把它關聯在一起。

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

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

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

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