為了探究云原生應(yīng)用系統(tǒng)的內(nèi)部狀態(tài)，我們希望向觀測(cè)數(shù)據(jù)中注入盡量豐富的標(biāo)簽，這些標(biāo)簽以往通過(guò)開發(fā)人員手動(dòng)在代碼中注入，或通過(guò)配置 Promtheus、OpenTelemetry 實(shí)現(xiàn)，一方面造成了很大的工作量和資源開銷，另一方面也導(dǎo)致不同信號(hào)源的數(shù)據(jù)標(biāo)簽不一致形成數(shù)據(jù)孤島。DeepFlow 依靠 AutoTagging 機(jī)制可以為所有觀測(cè)信號(hào)統(tǒng)一注入標(biāo)準(zhǔn)的、豐富的標(biāo)簽，很好的解決了這些問(wèn)題。SmartEncoding 的高性能編碼機(jī)制通過(guò)對(duì)標(biāo)簽數(shù)據(jù)的分離編碼和查詢時(shí)關(guān)聯(lián)，我們將存儲(chǔ)開銷降低了 10~50 倍，并且能支持無(wú)限量的 K8s label/annotation 等信息作為業(yè)務(wù)自定義標(biāo)簽。朋友們大家好，我是云杉網(wǎng)絡(luò)的宋貞，很高興今天能和大家一起分享 DeepFlow 的 AutoTagging 和 SmartEncoding 技術(shù)。這是 DeepFlow 的兩項(xiàng)關(guān)鍵核心技術(shù)，希望通過(guò)今天的介紹，可以讓大家詳細(xì)了解 AutoTagging 和 SmartEncoding 的實(shí)現(xiàn)方法，并為各位在可觀測(cè)性平臺(tái)的性能提升或者說(shuō)是資源優(yōu)化方向提供一個(gè)思路。內(nèi)容下載：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)今天的分享將會(huì)從五個(gè)方面展開：

從可觀測(cè)性建設(shè)角度出發(fā)，總結(jié)大家在日常工作中遇到的痛點(diǎn)；
介紹 DeepFlow 的軟件架構(gòu)、系統(tǒng)組成；
講解 DeepFlow 的關(guān)鍵特性 AutoTagging 技術(shù)；
講解支撐 AutoTagging 10x 性能提升的 SmartEncoding 技術(shù)；
總結(jié)并分享后續(xù)的迭代和演進(jìn)計(jì)劃。

01觀測(cè)數(shù)據(jù)存儲(chǔ)的挑戰(zhàn)

可觀測(cè)性建設(shè)從去年開始在國(guó)內(nèi)非常的火熱，大家談的越來(lái)越多。隨著云原生、微服務(wù)的發(fā)展落地，可觀測(cè)性建設(shè)逐漸成為了一個(gè)必不可少的工程手段。

可觀測(cè)性建設(shè)耗時(shí)長(zhǎng)我們認(rèn)為應(yīng)用開發(fā)團(tuán)隊(duì)花了一半的時(shí)間用于可觀測(cè)性的建設(shè)。這張圖里面可以看到，開發(fā)者通常需要考慮在不同的 Dev Stack 和 Infra Stack 中如何埋點(diǎn)、如何插碼、如何傳遞追蹤上下文、如何生成指標(biāo)/追蹤/日志數(shù)據(jù)并進(jìn)行關(guān)聯(lián)，需要考慮的問(wèn)題太多太雜。除此之外開發(fā)者還有很多時(shí)間在做 Debug，而這些 Debug 之所以耗費(fèi)了這么多時(shí)間，通常大部分是因?yàn)榭捎^測(cè)性建設(shè)的欠缺導(dǎo)致。

可觀測(cè)性建設(shè)數(shù)據(jù)關(guān)聯(lián)難可觀測(cè)性指標(biāo)數(shù)據(jù)一般分為Tracing、Metric和Logging三類。

Tracing關(guān)注的元數(shù)據(jù)是traceID/spanID/service/...；
Metric關(guān)注的元數(shù)據(jù)是vpc/instance/node/kvm/...；
Logging關(guān)注的元數(shù)據(jù)是type/level/time/message/...。

每類指標(biāo)關(guān)注的元數(shù)據(jù)/標(biāo)簽各不相同，所以經(jīng)常會(huì)出現(xiàn)由于缺少數(shù)據(jù)標(biāo)簽，導(dǎo)致無(wú)法下鉆定位具體的主機(jī)、微服務(wù)、Pod、實(shí)例、API Endpoint；又或者無(wú)法關(guān)聯(lián)具體的 git commit id、service owner。同時(shí)數(shù)據(jù)標(biāo)簽的概念和定義繁多，比如有的用 service 表示服務(wù)，有的用 app 表示，進(jìn)一步導(dǎo)致了可觀測(cè)性數(shù)據(jù)的關(guān)聯(lián)困難。Prometheus應(yīng)該是大家都非常熟悉的一款軟件，它的 relabeling 機(jī)制能夠?qū)?Metrics 的標(biāo)簽進(jìn)行靈活的管理，Metrics 的所有標(biāo)簽都是在這個(gè)階段統(tǒng)一注入或轉(zhuǎn)換的，特別是 K8s 資源相關(guān)的信息。但是用過(guò)的各位應(yīng)該知道 relabeling 的配置非常復(fù)雜，可參見具體配置^[3]。可觀測(cè)性業(yè)界很火的 OpenTelemetry 也需要做復(fù)雜的 opentelemetry processor 配置去注入/丟棄/改寫標(biāo)簽。讓人崩潰的是，當(dāng)你歷盡千辛萬(wàn)苦做到了各類指標(biāo)數(shù)據(jù)的無(wú)縫關(guān)聯(lián)，你會(huì)發(fā)現(xiàn)一個(gè)指標(biāo)需要攜帶上百個(gè)標(biāo)簽，消耗巨大的存儲(chǔ)資源，“可觀測(cè)性系統(tǒng)的資源消耗甚至超過(guò)了業(yè)務(wù)系統(tǒng)”。但幸運(yùn)的是，目前就有一款軟件可以很好的解決上面這些問(wèn)題，而又不會(huì)耗費(fèi)過(guò)多資源，那就是DeepFlow可觀測(cè)性數(shù)據(jù)平臺(tái)。

02、DeepFlow 軟件架構(gòu)

DeepFlow軟件架構(gòu)DeepFlow的架構(gòu)其實(shí)非常簡(jiǎn)單，它簡(jiǎn)單到只有一個(gè)Agent和一個(gè)Server，分別是數(shù)據(jù)采集組件和數(shù)據(jù)存儲(chǔ)查詢組件。Agent是使用Rust來(lái)實(shí)現(xiàn)的，高性能且內(nèi)存安全，它通過(guò)eBPF技術(shù)實(shí)現(xiàn)了對(duì)任意開發(fā)技術(shù)棧、任意基礎(chǔ)設(shè)施的全自動(dòng)應(yīng)用性能指標(biāo)數(shù)據(jù)采集（AutoMetrics），以及自動(dòng)化的分布式鏈路追蹤（AutoTracing），這兩項(xiàng)是DeepFlow Agent獨(dú)有的能力，能極大降低開發(fā)者建設(shè)可觀測(cè)性的工作量。Server包含了4個(gè)內(nèi)部模塊：Controller面向采集器Agent的管理，能納管多資源池的10萬(wàn)量級(jí)的Agent；Labeler面向標(biāo)簽數(shù)據(jù)的自動(dòng)注入，提供AutoTagging的能力；Querier面向數(shù)據(jù)查詢，提供統(tǒng)一的SQL接口；Ingester面向數(shù)據(jù)存儲(chǔ)，提供插件化的、可替換可組合的數(shù)據(jù)庫(kù)接口。它支持水平擴(kuò)展，而且完全不依賴外部的消息隊(duì)列或負(fù)載均衡，就能夠去實(shí)現(xiàn)對(duì)多個(gè)Region、多個(gè)資源池中Agent的負(fù)載均攤。Server也有兩個(gè)非常核心的技術(shù)，AutoTagging和SmartEncoding。通過(guò)AutoTagging我們能為Agent采集到的所有觀測(cè)數(shù)據(jù)自動(dòng)注入統(tǒng)一的資源、實(shí)例和API標(biāo)簽，使得我們能夠消除不同數(shù)據(jù)類型之間的隔閡，增強(qiáng)所有數(shù)據(jù)的關(guān)聯(lián)、切分、下鉆能力。SmartEncoding是我們非常創(chuàng)新的一個(gè)高性能的標(biāo)簽編碼機(jī)制，通過(guò)這個(gè)機(jī)制，我們既能方便的進(jìn)行數(shù)據(jù)關(guān)聯(lián)，又能將標(biāo)簽注入的存儲(chǔ)性能提升10倍，這在我們的實(shí)際生產(chǎn)環(huán)境中已經(jīng)進(jìn)行了廣泛的驗(yàn)證。

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

AutoTagging通過(guò)云API、K8s apiserver自動(dòng)同步30多種資源標(biāo)簽、100多種自定義微服務(wù)標(biāo)簽，來(lái)構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系。

DeepFlow資源同步DeepFlow的標(biāo)簽體系：

自定義標(biāo)簽
- k8s.label/k8s.env/k8s.annotation/..
- os.app/os.proc/...
- cloud.tag
進(jìn)程
- 進(jìn)程名
云資源
- 資源池：區(qū)域/可用區(qū)
- 計(jì)算資源：云服務(wù)器/宿主機(jī)
- 網(wǎng)絡(luò)資源：VPC/子網(wǎng)/路由器/IP地址
- 網(wǎng)絡(luò)服務(wù)：安全組/負(fù)載均衡器/NAT網(wǎng)關(guān)/對(duì)等連接/云企業(yè)網(wǎng)
- 存儲(chǔ)資源：云數(shù)據(jù)庫(kù)RDS/Redis
容器資源
- 容器集群/容器節(jié)點(diǎn)/命名空間/Ingress/容器服務(wù)/工作負(fù)載/POD

下面，我們依次介紹一下對(duì)各類資源信息的同步機(jī)制，以實(shí)現(xiàn)標(biāo)簽庫(kù)的構(gòu)建。同步 K8s 資源:

為什么是 Agent watch 并上報(bào) K8s資源？一個(gè) Server 可以管理多個(gè)集群中的 Agent，Agent在所屬集群中watch K8s，避免了集群外部用 server watch 時(shí)涉及到的權(quán)限和配置問(wèn)題。
如何控制 Agent 對(duì) K8s 資源的 watch？避免 K8s 的 API 壓力過(guò)大，不能讓所有的 Agent 都去 watch K8s，Server 在每個(gè)集群中選舉一個(gè) Agent；僅讓被選中的 Agent watch K8s 資源。

除此之外，我們還需要考慮資源規(guī)模的問(wèn)題，我們通過(guò)如下兩個(gè)措施降低 deepflow-agent 的資源消耗：

內(nèi)存優(yōu)化：Agent 僅抓取同步必須的字段，同時(shí)會(huì)第一時(shí)間進(jìn)行壓縮。
帶寬優(yōu)化：僅當(dāng) K8s 資源有變化時(shí)，Agent 才會(huì)向 Server 發(fā)送具體的資源信息

同步K8s資源的數(shù)據(jù)流同步云資源

同步云資源信息：通過(guò)調(diào)用云平臺(tái) API 進(jìn)行資源抽象和轉(zhuǎn)換，然后將相關(guān)標(biāo)簽信息保存至 MySQL 中，并定期更新 ClickHosue 中的字典。
同步 Legacy Host 信息：一些環(huán)境中，可能沒有真正意義的云平臺(tái)，或者存在一些傳統(tǒng)主機(jī)需要監(jiān)控，這就需要用Legacy Host同步方案。由于沒有具體的云API，我們完全通過(guò)Agent抓取所在服務(wù)器的名稱等基本信息和網(wǎng)卡信息，上報(bào)給Server匯總并進(jìn)行資源抽象。
同步托管 K8s 信息：當(dāng) K8s 平臺(tái)部署在云資源上時(shí)，要做到真正的可觀測(cè)性，需要將K8s的資源和云資源關(guān)聯(lián)起來(lái)，才能真正做到無(wú)縫地關(guān)聯(lián)、切分和下鉆。我們一方面通過(guò)獲取 K8s 資源所在的 VPC，基于 VPC 內(nèi) IP 的唯一性，通過(guò) VPC + IP 將 K8s 的容器節(jié)點(diǎn)與云服務(wù)器關(guān)聯(lián)起來(lái)；另一方面通過(guò)將云平臺(tái)的 API 調(diào)用與 K8s 獨(dú)立，兩者使用不同的調(diào)用頻率，從而解決大規(guī)模場(chǎng)景下，云平臺(tái) API 慢與 K8s 資源更新快的矛盾。

同步云資源的數(shù)據(jù)流理想很豐滿，現(xiàn)實(shí)很骨感。我們努力想實(shí)現(xiàn)觀測(cè)數(shù)據(jù)無(wú)縫跳轉(zhuǎn)，但當(dāng)上百個(gè)標(biāo)簽呈現(xiàn)在眼前時(shí)，你會(huì)發(fā)現(xiàn)后端資源消耗飆升，性能急劇下降，整個(gè)平臺(tái)別說(shuō)無(wú)縫跳轉(zhuǎn)了，連使用都成了問(wèn)題。于是 SmartEncoding 技術(shù)誕生了。

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

SmartEncoding 將標(biāo)簽注入分為3個(gè)階段，通過(guò)采集時(shí)編碼、存儲(chǔ)時(shí)編碼、和查詢時(shí)編/解碼降低標(biāo)簽寫入的資源消耗，我們來(lái)詳細(xì)看看每個(gè)階段都如何實(shí)現(xiàn)：采集時(shí)編碼

采集時(shí)編碼Controller 根據(jù)云平臺(tái)和 K8s 資源抽象好標(biāo)簽信息進(jìn)行 Int 編碼后，并不會(huì)將所有的標(biāo)簽下發(fā)給 Agent。僅會(huì)下發(fā)最少量的標(biāo)簽。這樣 Agent 只需要為數(shù)據(jù)追加很少的Int標(biāo)簽即可。在混合云場(chǎng)景下，為了標(biāo)識(shí)資源我們可以用 VPC ID 作為基，它能和 IP 地址聯(lián)合決定客戶端、服務(wù)端對(duì)應(yīng)的實(shí)例和服務(wù)；可以通過(guò) gpid 解決遠(yuǎn)端進(jìn)程信息標(biāo)記的問(wèn)題。我們主要考慮 Agent 做的工作盡量少，這樣可以最大限度的降低采集器的 CPU、內(nèi)存消耗，以及傳輸數(shù)據(jù)的帶寬消耗。我們?cè)谏a(chǎn)環(huán)境中發(fā)現(xiàn)有些 K8s 的標(biāo)簽會(huì)非常長(zhǎng)，key 和 value 高達(dá)上百個(gè)字節(jié)?？梢韵胂笕绻覀儗⑸习賯€(gè)標(biāo)簽注入每個(gè)請(qǐng)求傳輸?shù)胶蠖?，消耗的帶寬?huì)非常可觀。存儲(chǔ)時(shí)編碼

存儲(chǔ)時(shí)編碼同樣 Controller 會(huì)向 Ingester 下發(fā) Int 標(biāo)簽，但僅下發(fā)持久化存儲(chǔ)的標(biāo)簽。Ingester 在收到 Agent 發(fā)過(guò)來(lái)的數(shù)據(jù)后，會(huì)進(jìn)行一輪標(biāo)簽的擴(kuò)充，將 Agent 注入的少量標(biāo)簽擴(kuò)展為更為豐富的標(biāo)簽集合。但這里注意的是，我們并不存儲(chǔ)自定義標(biāo)簽。標(biāo)簽的存儲(chǔ)是為了方便檢索和聚合，我們只需要保證每個(gè)切分粒度上都有標(biāo)簽存在即可。舉例來(lái)講我們存儲(chǔ) Region、AZ、VM、Node、Namespace、Service、POD 等固定的云或者 K8s 資源標(biāo)簽即可，而其他的自定義的標(biāo)簽一般是依附在這些標(biāo)簽之上的，存在一定的對(duì)應(yīng)的關(guān)系。另外，自定義標(biāo)簽動(dòng)態(tài)性高，也不適合全部存儲(chǔ)。根據(jù)我們的經(jīng)驗(yàn)，一般每一個(gè)請(qǐng)求涉及到的的固定標(biāo)簽在40個(gè)左右，自定義標(biāo)簽在60個(gè)左右。通過(guò)只存儲(chǔ)固定的資源標(biāo)簽，我們能將壓力進(jìn)一步降低。查詢時(shí)編/解碼

查詢時(shí)編解碼DeepFlow SQL支持通過(guò)字符串查詢和聚合，并且也支持自定義標(biāo)簽的查詢和聚合。這里我們依賴 ClickHouse 的字典能力。通過(guò)編碼自定義標(biāo)簽的 Filter 和 Group 查詢請(qǐng)求，利用 ClickHouse 的字典轉(zhuǎn)換為系統(tǒng)標(biāo)簽；同時(shí)對(duì)于 Select 請(qǐng)求也可以利用 ClickHouse 的字典將系統(tǒng)標(biāo)簽轉(zhuǎn)為字符串或者自定義標(biāo)簽返回。我們?cè)賮?lái)回顧一下這三級(jí)編解碼，可以發(fā)現(xiàn)它能為我們節(jié)省大量的資源消耗，性能提升應(yīng)該十分可觀。一方面采集器的CPU、內(nèi)存可以降低，傳輸帶寬可以降低，最主要的還是后端存儲(chǔ)開銷的降低。我們?cè)谡務(wù)摽捎^測(cè)性時(shí)經(jīng)常會(huì)談到采樣、避免高基數(shù)等。ClickHouse 采用稀疏索引，很好的避免了高基數(shù)問(wèn)題。我們?cè)诖酥系亩嗉?jí)編解碼又能將存儲(chǔ)開銷顯著降低，而且由于查詢階段掃描的數(shù)據(jù)量變小了，所以能獲得更好的查詢性能。這里有一些數(shù)據(jù)可以看一下，DeepFlow 默認(rèn)使用 ClickHouse 存儲(chǔ)數(shù)據(jù)，在 SmartEncoding 的加持下，標(biāo)準(zhǔn) Tag 的 CPU 和磁盤消耗相比 LowCard 存儲(chǔ)或直接存儲(chǔ)有一個(gè)數(shù)量級(jí)的優(yōu)化，而由于自定義 Tag 不會(huì)隨數(shù)據(jù)寫入，在通常的場(chǎng)景下整體寫入資源消耗可降低50倍。

做了這么復(fù)雜的編碼以后，如何讓查詢變得簡(jiǎn)單呢？下面我們來(lái)介紹 deepflow-server 的查詢抽象層，它向用戶隱藏了寫時(shí)編碼和讀時(shí)關(guān)聯(lián)的復(fù)雜邏輯，用戶對(duì)數(shù)據(jù)的查詢就像在一張大寬表上進(jìn)行，體驗(yàn)非常絲滑。例如，我們可以直接查詢所有表中的數(shù)據(jù)：

SELECTcol_1,col_2,col_3 FROMtbl_1 WHEREcol_4=y GROUPBYcol_1,col_2 HAVINGcol_5>100 ORDERBYcol_3 LIMIT100 ``` 我們可以查詢某個(gè) Tag 的所有候選項(xiàng)： ```sql SHOWtag${tag_name}valuesFROM${table_name}

SHOWtag${tag_name}values FROM${table_name} WHEREdisplay_nameLIKE'*abc*'

SELECTpod FROM`vtap_flow_port.1m` WHEREpod_cluster='cluster1' GROUPBYpod 更多詳細(xì)用法^[4]查詢 Universal Tag

ClickHouse 的觀測(cè)數(shù)據(jù)表中保存tag ID

CREATETABLEflow_metrics.`vtap_flow_port.1m` ( `time`DateTime('Asia/Shanghai')COMMENT'v6.1.8'CODEC(DoubleDelta), `ip4`IPv4COMMENT'IPv4地址', `ip6`IPv6COMMENT'IPV6地址', `is_ipv4`UInt8COMMENT'是否IPV4地址.0:否,ip6字段有效,1:是,ip4字段有效', `l3_device_id`UInt32COMMENT'ip對(duì)應(yīng)的資源ID', `l3_device_type`UInt8COMMENT'ip對(duì)應(yīng)的資源類型', `l3_epc_id`Int32COMMENT'ip對(duì)應(yīng)的EPCID', `pod_cluster_id`UInt16COMMENT'ip對(duì)應(yīng)的容器集群ID', `pod_group_id`UInt32COMMENT'ip對(duì)應(yīng)的容器工作負(fù)載ID', `pod_id`UInt32COMMENT'ip對(duì)應(yīng)的容器PODID', `pod_node_id`UInt32COMMENT'ip對(duì)應(yīng)的容器節(jié)點(diǎn)ID', `pod_ns_id`UInt16COMMENT'ip對(duì)應(yīng)的容器命名空間ID' ) ENGINE=Distributed(...)

ClickHouse 的字典表中保存tag ID和名稱對(duì)應(yīng)關(guān)系

CREATEDICTIONARYflow_tag.pod_map ( `id`UInt64, `name`String, `icon_id`Int64 ) PRIMARYKEYid SOURCE(...)

通過(guò) dictGet 實(shí)現(xiàn)tag ID到名稱的轉(zhuǎn)換

SELECTdictGet(flow_tag.pod_map,'name',toUInt64(pod_id))ASpod FROM`vtap_flow_port.1m` WHEREpod='deepflow' GROUPBYpod LIMIT1 查詢 K8s label

ClickHouse 的字典表中保存tag ID和 K8s label對(duì)應(yīng)關(guān)系

CREATEDICTIONARYflow_tag.k8s_label_map ( `pod_id`UInt64, `key`String, `value`String, ) PRIMARYKEYpod_id,key SOURCE(...) LIFETIME(MIN0MAX60) LAYOUT(COMPLEX_KEY_HASHED())

通過(guò) dictGet 實(shí)現(xiàn)tag ID到 K8s label 的轉(zhuǎn)換

SELECTdictGet(flow_tag.k8s_label_map,'value',(toUInt64(pod_id),'app'))AS`label.app` FROM`vtap_flow_port.1m` WHERE`label.app`='xxx' LIMIT1 查詢集成數(shù)據(jù)，包括 Prometheus、Telegraf、OpenTelemetry 等數(shù)據(jù)。

存儲(chǔ)集成數(shù)據(jù)時(shí)，會(huì)將數(shù)據(jù)中原有的 Tag 和 Metric 的 name 和 value 分別定義為 Array 類型，一一對(duì)應(yīng)。

CREATETABLEext_metrics.prometheus_web ( `time`DateTime('Asia/Shanghai')CODEC(DoubleDelta), `_tid`UInt8COMMENT'用于區(qū)分trident不同的pipeline', `az_id`UInt16COMMENT'可用區(qū)ID', `host_id`UInt16COMMENT'宿主機(jī)ID', `tag_names`Array(String)COMMENT'額外的tag', `tag_values`Array(String)COMMENT'額外的tag對(duì)應(yīng)的值', `metrics_float_names`Array(String)COMMENT'額外的metrics', `metrics_float_values`Array(Float64)COMMENT'額外的metrics值' )

Tag 候選項(xiàng)只需要保留不重復(fù)的值，所以我們使用 ReplacingMergeTree Engine

CREATETABLEflow_tag.ext_metrics_custom_field_local ( `time`DateTime('Asia/Shanghai')CODEC(DoubleDelta), `table`LowCardinality(String), `vpc_id`Int32, `pod_ns_id`UInt16, `field_type`LowCardinality(String)COMMENT'value:tag,metrics', `field_name`LowCardinality(String), `field_value_type`LowCardinality(String)COMMENT'value:string,float' ) ENGINE=ReplacingMergeTree(time)

通過(guò) indexOf 進(jìn)行 name 和 value 的對(duì)應(yīng)

SELECTtag_values[indexOf(tag_names,'host')]AS`tag.host` FROMdeepflow_agent_collect_sender WHERE(tag_values[indexOf(tag_names,'host')])='xxxx' LIMIT1

05、總結(jié)與后續(xù)迭代計(jì)劃

通過(guò)以上分享，相信您會(huì)發(fā)現(xiàn)DeepFlow有豐富、統(tǒng)一的標(biāo)準(zhǔn)化標(biāo)簽體系，非常方便進(jìn)行數(shù)據(jù)關(guān)聯(lián)、切分、下鉆。通過(guò) SmartEncoding 的性能優(yōu)化，Server + ClickHouse 的資源消耗通常為業(yè)務(wù)消耗的 1%，即監(jiān)控100個(gè) 16c64g 的容器節(jié)點(diǎn)，大概需要1個(gè) 16c64g 的 Node 部署 Server + ClickHouse，且可以通過(guò)對(duì)象存儲(chǔ)轉(zhuǎn)儲(chǔ)冷數(shù)據(jù)；而且常見的可觀測(cè)性數(shù)據(jù)一般都需要注入百量級(jí)的標(biāo)簽，DeepFlow Agent 由于只注入了 VPC、GPID 少數(shù)幾個(gè)字段，因此它用于標(biāo)簽注入的資源消耗幾乎只有其他方案的百分之幾。這樣10x性能的使用體驗(yàn)，相信 Cloud-Native、NewOps 都會(huì)喜歡！后續(xù)我們會(huì)支持更豐富的自定義標(biāo)簽，包括通過(guò) K8s API 獲取的k8s.annotation 和 k8s.env、通過(guò)操作系統(tǒng)獲取的 os.proc 信息、通過(guò)執(zhí)行命令獲取 os.app 信息；會(huì)從時(shí)間和帶寬消耗兩方面進(jìn)一步優(yōu)化AutoTagging的性能，通過(guò)不同類型資源的 API 可以設(shè)置不同的調(diào)用頻率，避免每次都是重新獲取全部資源來(lái)縮短縮短大規(guī)模下的資源同步時(shí)間；通過(guò)Agent 僅發(fā)送有變化的 K8s 資源信息，進(jìn)一步降低帶寬消耗。

06、關(guān)于DeepFlow

DeepFlow^[5]是一款開源的高度自動(dòng)化的可觀測(cè)性平臺(tái)，是為云原生應(yīng)用開發(fā)者建設(shè)可觀測(cè)性能力而量身打造的全棧、全鏈路、高性能數(shù)據(jù)引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術(shù)，創(chuàng)新的實(shí)現(xiàn)了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機(jī)制，幫助開發(fā)者提升埋點(diǎn)插碼的自動(dòng)化水平，降低可觀測(cè)性平臺(tái)的運(yùn)維復(fù)雜度。利用 DeepFlow 的可編程能力和開放接口，開發(fā)者可以快速將其融入到自己的可觀測(cè)性技術(shù)棧中。審核編輯：李倩

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題，請(qǐng)聯(lián)系本站處理。舉報(bào)投訴

核心技術(shù)

核心技術(shù)

+關(guān)注

關(guān)注
4

文章
625

瀏覽量
20151
數(shù)據(jù)存儲(chǔ)

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

+關(guān)注

關(guān)注
5

文章
997

瀏覽量
51677
軟件架構(gòu)

軟件架構(gòu)

+關(guān)注

關(guān)注
0

文章
64

瀏覽量
10482

原文標(biāo)題：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

文章出處：【微信號(hào)：AI_Architect，微信公眾號(hào)：智能計(jì)算芯世界】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

搜索歷史

DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

01觀測(cè)數(shù)據(jù)存儲(chǔ)的挑戰(zhàn)

02、DeepFlow 軟件架構(gòu)

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

05、總結(jié)與后續(xù)迭代計(jì)劃

06、關(guān)于DeepFlow

評(píng)論

搜索歷史

DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

01觀測(cè)數(shù)據(jù)存儲(chǔ)的挑戰(zhàn)

02、DeepFlow 軟件架構(gòu)

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

05、總結(jié)與后續(xù)迭代計(jì)劃

06、關(guān)于DeepFlow

評(píng)論

02、DeepFlow 軟件架構(gòu)

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

05、總結(jié)與后續(xù)迭代計(jì)劃

06、關(guān)于DeepFlow