DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)
為了探究云原生應(yīng)用系統(tǒng)的內(nèi)部狀態(tài)，我們希望向觀測數(shù)據(jù)中注入盡量豐富的標(biāo)簽，這些標(biāo)簽以往通過開發(fā)人員手動在代碼中注入，或通過配置 Promtheus、OpenTelemetry 實(shí)現(xiàn)，一方面造成了很大的工作量和資源開銷，另一方面也導(dǎo)致不同信號源的數(shù)據(jù)標(biāo)簽不一致形成數(shù)據(jù)孤島。DeepFlow 依靠 AutoTagging 機(jī)制可以為所有觀測信號統(tǒng)一注入標(biāo)準(zhǔn)的、豐富的標(biāo)簽，很好的解決了這些問題。SmartEncoding 的高性能編碼機(jī)制通過對標(biāo)簽數(shù)據(jù)的分離編碼和查詢時關(guān)聯(lián)，我們將存儲開銷降低了 10~50 倍，并且能支持無限量的 K8s label/annotation 等信息作為業(yè)務(wù)自定義標(biāo)簽。朋友們大家好，我是云杉網(wǎng)絡(luò)的宋貞，很高興今天能和大家一起分享 DeepFlow 的 AutoTagging 和 SmartEncoding 技術(shù)。這是 DeepFlow 的兩項(xiàng)關(guān)鍵核心技術(shù)，希望通過今天的介紹，可以讓大家詳細(xì)了解 AutoTagging 和 SmartEncoding 的實(shí)現(xiàn)方法，并為各位在可觀測性平臺的性能提升或者說是資源優(yōu)化方向提供一個思路。內(nèi)容下載：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)今天的分享將會從五個方面展開：
可觀測性建設(shè)耗時長我們認(rèn)為應(yīng)用開發(fā)團(tuán)隊(duì)花了一半的時間用于可觀測性的建設(shè)。這張圖里面可以看到，開發(fā)者通常需要考慮在不同的 Dev Stack 和 Infra Stack 中如何埋點(diǎn)、如何插碼、如何傳遞追蹤上下文、如何生成指標(biāo)/追蹤/日志數(shù)據(jù)并進(jìn)行關(guān)聯(lián)，需要考慮的問題太多太雜。除此之外開發(fā)者還有很多時間在做 Debug，而這些 Debug 之所以耗費(fèi)了這么多時間，通常大部分是因?yàn)榭捎^測性建設(shè)的欠缺導(dǎo)致。
可觀測性建設(shè)數(shù)據(jù)關(guān)聯(lián)難可觀測性指標(biāo)數(shù)據(jù)一般分為Tracing、Metric和Logging三類。
DeepFlow軟件架構(gòu)DeepFlow的架構(gòu)其實(shí)非常簡單，它簡單到只有一個Agent和一個Server，分別是數(shù)據(jù)采集組件和數(shù)據(jù)存儲查詢組件。Agent是使用Rust來實(shí)現(xiàn)的，高性能且內(nèi)存安全，它通過eBPF技術(shù)實(shí)現(xiàn)了對任意開發(fā)技術(shù)棧、任意基礎(chǔ)設(shè)施的全自動應(yīng)用性能指標(biāo)數(shù)據(jù)采集（AutoMetrics），以及自動化的分布式鏈路追蹤（AutoTracing），這兩項(xiàng)是DeepFlow Agent獨(dú)有的能力，能極大降低開發(fā)者建設(shè)可觀測性的工作量。Server包含了4個內(nèi)部模塊：Controller面向采集器Agent的管理，能納管多資源池的10萬量級的Agent；Labeler面向標(biāo)簽數(shù)據(jù)的自動注入，提供AutoTagging的能力；Querier面向數(shù)據(jù)查詢，提供統(tǒng)一的SQL接口；Ingester面向數(shù)據(jù)存儲，提供插件化的、可替換可組合的數(shù)據(jù)庫接口。它支持水平擴(kuò)展，而且完全不依賴外部的消息隊(duì)列或負(fù)載均衡，就能夠去實(shí)現(xiàn)對多個Region、多個資源池中Agent的負(fù)載均攤。Server也有兩個非常核心的技術(shù)，AutoTagging和SmartEncoding。通過AutoTagging我們能為Agent采集到的所有觀測數(shù)據(jù)自動注入統(tǒng)一的資源、實(shí)例和API標(biāo)簽，使得我們能夠消除不同數(shù)據(jù)類型之間的隔閡，增強(qiáng)所有數(shù)據(jù)的關(guān)聯(lián)、切分、下鉆能力。SmartEncoding是我們非常創(chuàng)新的一個高性能的標(biāo)簽編碼機(jī)制，通過這個機(jī)制，我們既能方便的進(jìn)行數(shù)據(jù)關(guān)聯(lián)，又能將標(biāo)簽注入的存儲性能提升10倍，這在我們的實(shí)際生產(chǎn)環(huán)境中已經(jīng)進(jìn)行了廣泛的驗(yàn)證。
DeepFlow資源同步DeepFlow的標(biāo)簽體系：
同步K8s資源的數(shù)據(jù)流同步云資源
同步云資源的數(shù)據(jù)流理想很豐滿，現(xiàn)實(shí)很骨感。我們努力想實(shí)現(xiàn)觀測數(shù)據(jù)無縫跳轉(zhuǎn)，但當(dāng)上百個標(biāo)簽呈現(xiàn)在眼前時，你會發(fā)現(xiàn)后端資源消耗飆升，性能急劇下降，整個平臺別說無縫跳轉(zhuǎn)了，連使用都成了問題。于是 SmartEncoding 技術(shù)誕生了。
采集時編碼Controller 根據(jù)云平臺和 K8s 資源抽象好標(biāo)簽信息進(jìn)行 Int 編碼后，并不會將所有的標(biāo)簽下發(fā)給 Agent。僅會下發(fā)最少量的標(biāo)簽。這樣 Agent 只需要為數(shù)據(jù)追加很少的Int標(biāo)簽即可。在混合云場景下，為了標(biāo)識資源我們可以用 VPC ID 作為基，它能和 IP 地址聯(lián)合決定客戶端、服務(wù)端對應(yīng)的實(shí)例和服務(wù)；可以通過 gpid 解決遠(yuǎn)端進(jìn)程信息標(biāo)記的問題。我們主要考慮 Agent 做的工作盡量少，這樣可以最大限度的降低采集器的 CPU、內(nèi)存消耗，以及傳輸數(shù)據(jù)的帶寬消耗。我們在生產(chǎn)環(huán)境中發(fā)現(xiàn)有些 K8s 的標(biāo)簽會非常長，key 和 value 高達(dá)上百個字節(jié)。可以想象如果我們將上百個標(biāo)簽注入每個請求傳輸?shù)胶蠖耍牡膸挄浅？捎^。存儲時編碼
存儲時編碼同樣 Controller 會向 Ingester 下發(fā) Int 標(biāo)簽，但僅下發(fā)持久化存儲的標(biāo)簽。Ingester 在收到 Agent 發(fā)過來的數(shù)據(jù)后，會進(jìn)行一輪標(biāo)簽的擴(kuò)充，將 Agent 注入的少量標(biāo)簽擴(kuò)展為更為豐富的標(biāo)簽集合。但這里注意的是，我們并不存儲自定義標(biāo)簽。標(biāo)簽的存儲是為了方便檢索和聚合，我們只需要保證每個切分粒度上都有標(biāo)簽存在即可。舉例來講我們存儲 Region、AZ、VM、Node、Namespace、Service、POD 等固定的云或者 K8s 資源標(biāo)簽即可，而其他的自定義的標(biāo)簽一般是依附在這些標(biāo)簽之上的，存在一定的對應(yīng)的關(guān)系。另外，自定義標(biāo)簽動態(tài)性高，也不適合全部存儲。根據(jù)我們的經(jīng)驗(yàn)，一般每一個請求涉及到的的固定標(biāo)簽在40個左右，自定義標(biāo)簽在60個左右。通過只存儲固定的資源標(biāo)簽，我們能將壓力進(jìn)一步降低。查詢時編/解碼
查詢時編解碼DeepFlow SQL支持通過字符串查詢和聚合，并且也支持自定義標(biāo)簽的查詢和聚合。這里我們依賴 ClickHouse 的字典能力。通過編碼自定義標(biāo)簽的 Filter 和 Group 查詢請求，利用 ClickHouse 的字典轉(zhuǎn)換為系統(tǒng)標(biāo)簽；同時對于 Select 請求也可以利用 ClickHouse 的字典將系統(tǒng)標(biāo)簽轉(zhuǎn)為字符串或者自定義標(biāo)簽返回。我們再來回顧一下這三級編解碼，可以發(fā)現(xiàn)它能為我們節(jié)省大量的資源消耗，性能提升應(yīng)該十分可觀。一方面采集器的CPU、內(nèi)存可以降低，傳輸帶寬可以降低，最主要的還是后端存儲開銷的降低。我們在談?wù)摽捎^測性時經(jīng)常會談到采樣、避免高基數(shù)等。ClickHouse 采用稀疏索引，很好的避免了高基數(shù)問題。我們在此之上的多級編解碼又能將存儲開銷顯著降低，而且由于查詢階段掃描的數(shù)據(jù)量變小了，所以能獲得更好的查詢性能。這里有一些數(shù)據(jù)可以看一下，DeepFlow 默認(rèn)使用 ClickHouse 存儲數(shù)據(jù)，在 SmartEncoding 的加持下，標(biāo)準(zhǔn) Tag 的 CPU 和磁盤消耗相比 LowCard 存儲或直接存儲有一個數(shù)量級的優(yōu)化，而由于自定義 Tag 不會隨數(shù)據(jù)寫入，在通常的場景下整體寫入資源消耗可降低50倍。
- 從可觀測性建設(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觀測數(shù)據(jù)存儲的挑戰(zhàn)
可觀測性建設(shè)從去年開始在國內(nèi)非常的火熱，大家談的越來越多。隨著云原生、微服務(wù)的發(fā)展落地，可觀測性建設(shè)逐漸成為了一個必不可少的工程手段。
可觀測性建設(shè)耗時長我們認(rèn)為應(yīng)用開發(fā)團(tuán)隊(duì)花了一半的時間用于可觀測性的建設(shè)。這張圖里面可以看到，開發(fā)者通常需要考慮在不同的 Dev Stack 和 Infra Stack 中如何埋點(diǎn)、如何插碼、如何傳遞追蹤上下文、如何生成指標(biāo)/追蹤/日志數(shù)據(jù)并進(jìn)行關(guān)聯(lián)，需要考慮的問題太多太雜。除此之外開發(fā)者還有很多時間在做 Debug，而這些 Debug 之所以耗費(fèi)了這么多時間，通常大部分是因?yàn)榭捎^測性建設(shè)的欠缺導(dǎo)致。可觀測性建設(shè)數(shù)據(jù)關(guān)聯(lián)難可觀測性指標(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/...。
02、DeepFlow 軟件架構(gòu)
DeepFlow軟件架構(gòu)DeepFlow的架構(gòu)其實(shí)非常簡單，它簡單到只有一個Agent和一個Server，分別是數(shù)據(jù)采集組件和數(shù)據(jù)存儲查詢組件。Agent是使用Rust來實(shí)現(xiàn)的，高性能且內(nèi)存安全，它通過eBPF技術(shù)實(shí)現(xiàn)了對任意開發(fā)技術(shù)棧、任意基礎(chǔ)設(shè)施的全自動應(yīng)用性能指標(biāo)數(shù)據(jù)采集（AutoMetrics），以及自動化的分布式鏈路追蹤（AutoTracing），這兩項(xiàng)是DeepFlow Agent獨(dú)有的能力，能極大降低開發(fā)者建設(shè)可觀測性的工作量。Server包含了4個內(nèi)部模塊：Controller面向采集器Agent的管理，能納管多資源池的10萬量級的Agent；Labeler面向標(biāo)簽數(shù)據(jù)的自動注入，提供AutoTagging的能力；Querier面向數(shù)據(jù)查詢，提供統(tǒng)一的SQL接口；Ingester面向數(shù)據(jù)存儲，提供插件化的、可替換可組合的數(shù)據(jù)庫接口。它支持水平擴(kuò)展，而且完全不依賴外部的消息隊(duì)列或負(fù)載均衡，就能夠去實(shí)現(xiàn)對多個Region、多個資源池中Agent的負(fù)載均攤。Server也有兩個非常核心的技術(shù)，AutoTagging和SmartEncoding。通過AutoTagging我們能為Agent采集到的所有觀測數(shù)據(jù)自動注入統(tǒng)一的資源、實(shí)例和API標(biāo)簽，使得我們能夠消除不同數(shù)據(jù)類型之間的隔閡，增強(qiáng)所有數(shù)據(jù)的關(guān)聯(lián)、切分、下鉆能力。SmartEncoding是我們非常創(chuàng)新的一個高性能的標(biāo)簽編碼機(jī)制，通過這個機(jī)制，我們既能方便的進(jìn)行數(shù)據(jù)關(guān)聯(lián)，又能將標(biāo)簽注入的存儲性能提升10倍，這在我們的實(shí)際生產(chǎn)環(huán)境中已經(jīng)進(jìn)行了廣泛的驗(yàn)證。03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系
AutoTagging通過云API、K8s apiserver自動同步30多種資源標(biāo)簽、100多種自定義微服務(wù)標(biāo)簽，來構(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)/對等連接/云企業(yè)網(wǎng)
- 存儲資源：云數(shù)據(jù)庫RDS/Redis
-
容器資源
- 容器集群/容器節(jié)點(diǎn)/命名空間/Ingress/容器服務(wù)/工作負(fù)載/POD
- 為什么是 Agent watch 并上報(bào) K8s資源？一個 Server 可以管理多個集群中的 Agent，Agent在所屬集群中watch K8s，避免了集群外部用 server watch 時涉及到的權(quán)限和配置問題。
- 如何控制 Agent 對 K8s 資源的 watch？避免 K8s 的 API 壓力過大，不能讓所有的 Agent 都去 watch K8s，Server 在每個集群中選舉一個 Agent；僅讓被選中的 Agent watch K8s 資源。
- 內(nèi)存優(yōu)化：Agent 僅抓取同步必須的字段，同時會第一時間進(jìn)行壓縮。
- 帶寬優(yōu)化：僅當(dāng) K8s 資源有變化時，Agent 才會向 Server 發(fā)送具體的資源信息
同步K8s資源的數(shù)據(jù)流同步云資源-
同步云資源信息：通過調(diào)用云平臺 API 進(jìn)行資源抽象和轉(zhuǎn)換，然后將相關(guān)標(biāo)簽信息保存至 MySQL 中，并定期更新 ClickHosue 中的字典。
-
同步 Legacy Host 信息：一些環(huán)境中，可能沒有真正意義的云平臺，或者存在一些傳統(tǒng)主機(jī)需要監(jiān)控，這就需要用Legacy Host同步方案。由于沒有具體的云API，我們完全通過Agent抓取所在服務(wù)器的名稱等基本信息和網(wǎng)卡信息，上報(bào)給Server匯總并進(jìn)行資源抽象。
-
同步托管 K8s 信息：當(dāng) K8s 平臺部署在云資源上時，要做到真正的可觀測性，需要將K8s的資源和云資源關(guān)聯(lián)起來，才能真正做到無縫地關(guān)聯(lián)、切分和下鉆。我們一方面通過獲取 K8s 資源所在的 VPC，基于 VPC 內(nèi) IP 的唯一性，通過 VPC + IP 將 K8s 的容器節(jié)點(diǎn)與云服務(wù)器關(guān)聯(lián)起來；另一方面通過將云平臺的 API 調(diào)用與 K8s 獨(dú)立，兩者使用不同的調(diào)用頻率，從而解決大規(guī)模場景下，云平臺 API 慢與 K8s 資源更新快的矛盾。
同步云資源的數(shù)據(jù)流理想很豐滿，現(xiàn)實(shí)很骨感。我們努力想實(shí)現(xiàn)觀測數(shù)據(jù)無縫跳轉(zhuǎn)，但當(dāng)上百個標(biāo)簽呈現(xiàn)在眼前時，你會發(fā)現(xiàn)后端資源消耗飆升，性能急劇下降，整個平臺別說無縫跳轉(zhuǎn)了，連使用都成了問題。于是 SmartEncoding 技術(shù)誕生了。04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升
SmartEncoding 將標(biāo)簽注入分為3個階段，通過采集時編碼、存儲時編碼、和查詢時編/解碼降低標(biāo)簽寫入的資源消耗，我們來詳細(xì)看看每個階段都如何實(shí)現(xiàn)：采集時編碼采集時編碼Controller 根據(jù)云平臺和 K8s 資源抽象好標(biāo)簽信息進(jìn)行 Int 編碼后，并不會將所有的標(biāo)簽下發(fā)給 Agent。僅會下發(fā)最少量的標(biāo)簽。這樣 Agent 只需要為數(shù)據(jù)追加很少的Int標(biāo)簽即可。在混合云場景下，為了標(biāo)識資源我們可以用 VPC ID 作為基，它能和 IP 地址聯(lián)合決定客戶端、服務(wù)端對應(yīng)的實(shí)例和服務(wù)；可以通過 gpid 解決遠(yuǎn)端進(jìn)程信息標(biāo)記的問題。我們主要考慮 Agent 做的工作盡量少，這樣可以最大限度的降低采集器的 CPU、內(nèi)存消耗，以及傳輸數(shù)據(jù)的帶寬消耗。我們在生產(chǎn)環(huán)境中發(fā)現(xiàn)有些 K8s 的標(biāo)簽會非常長，key 和 value 高達(dá)上百個字節(jié)。可以想象如果我們將上百個標(biāo)簽注入每個請求傳輸?shù)胶蠖耍牡膸挄浅？捎^。存儲時編碼存儲時編碼同樣 Controller 會向 Ingester 下發(fā) Int 標(biāo)簽，但僅下發(fā)持久化存儲的標(biāo)簽。Ingester 在收到 Agent 發(fā)過來的數(shù)據(jù)后，會進(jìn)行一輪標(biāo)簽的擴(kuò)充，將 Agent 注入的少量標(biāo)簽擴(kuò)展為更為豐富的標(biāo)簽集合。但這里注意的是，我們并不存儲自定義標(biāo)簽。標(biāo)簽的存儲是為了方便檢索和聚合，我們只需要保證每個切分粒度上都有標(biāo)簽存在即可。舉例來講我們存儲 Region、AZ、VM、Node、Namespace、Service、POD 等固定的云或者 K8s 資源標(biāo)簽即可，而其他的自定義的標(biāo)簽一般是依附在這些標(biāo)簽之上的，存在一定的對應(yīng)的關(guān)系。另外，自定義標(biāo)簽動態(tài)性高，也不適合全部存儲。根據(jù)我們的經(jīng)驗(yàn)，一般每一個請求涉及到的的固定標(biāo)簽在40個左右，自定義標(biāo)簽在60個左右。通過只存儲固定的資源標(biāo)簽，我們能將壓力進(jìn)一步降低。查詢時編/解碼查詢時編解碼DeepFlow SQL支持通過字符串查詢和聚合，并且也支持自定義標(biāo)簽的查詢和聚合。這里我們依賴 ClickHouse 的字典能力。通過編碼自定義標(biāo)簽的 Filter 和 Group 查詢請求，利用 ClickHouse 的字典轉(zhuǎn)換為系統(tǒng)標(biāo)簽；同時對于 Select 請求也可以利用 ClickHouse 的字典將系統(tǒng)標(biāo)簽轉(zhuǎn)為字符串或者自定義標(biāo)簽返回。我們再來回顧一下這三級編解碼，可以發(fā)現(xiàn)它能為我們節(jié)省大量的資源消耗，性能提升應(yīng)該十分可觀。一方面采集器的CPU、內(nèi)存可以降低，傳輸帶寬可以降低，最主要的還是后端存儲開銷的降低。我們在談?wù)摽捎^測性時經(jīng)常會談到采樣、避免高基數(shù)等。ClickHouse 采用稀疏索引，很好的避免了高基數(shù)問題。我們在此之上的多級編解碼又能將存儲開銷顯著降低，而且由于查詢階段掃描的數(shù)據(jù)量變小了，所以能獲得更好的查詢性能。這里有一些數(shù)據(jù)可以看一下，DeepFlow 默認(rèn)使用 ClickHouse 存儲數(shù)據(jù)，在 SmartEncoding 的加持下，標(biāo)準(zhǔn) Tag 的 CPU 和磁盤消耗相比 LowCard 存儲或直接存儲有一個數(shù)量級的優(yōu)化，而由于自定義 Tag 不會隨數(shù)據(jù)寫入，在通常的場景下整體寫入資源消耗可降低50倍。
SELECTcol_1,col_2,col_3 FROMtbl_1 WHEREcol_4=y GROUPBYcol_1,col_2 HAVINGcol_5>100 ORDERBYcol_3 LIMIT100 ``` 我們可以查詢某個 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 的觀測數(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對應(yīng)的資源ID', `l3_device_type`UInt8COMMENT'ip對應(yīng)的資源類型', `l3_epc_id`Int32COMMENT'ip對應(yīng)的EPCID', `pod_cluster_id`UInt16COMMENT'ip對應(yīng)的容器集群ID', `pod_group_id`UInt32COMMENT'ip對應(yīng)的容器工作負(fù)載ID', `pod_id`UInt32COMMENT'ip對應(yīng)的容器PODID', `pod_node_id`UInt32COMMENT'ip對應(yīng)的容器節(jié)點(diǎn)ID', `pod_ns_id`UInt16COMMENT'ip對應(yīng)的容器命名空間ID' ) ENGINE=Distributed(...)
- ClickHouse 的字典表中保存tag ID和名稱對應(yīng)關(guān)系
CREATEDICTIONARYflow_tag.pod_map ( `id`UInt64, `name`String, `icon_id`Int64 ) PRIMARYKEYid SOURCE(...)
- 通過 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對應(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())
- 通過 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ù)。
- 存儲集成數(shù)據(jù)時，會將數(shù)據(jù)中原有的 Tag 和 Metric 的 name 和 value 分別定義為 Array 類型，一一對應(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對應(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)
- 通過 indexOf 進(jìn)行 name 和 value 的對應(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ì)劃
通過以上分享，相信您會發(fā)現(xiàn)DeepFlow有豐富、統(tǒng)一的標(biāo)準(zhǔn)化標(biāo)簽體系，非常方便進(jìn)行數(shù)據(jù)關(guān)聯(lián)、切分、下鉆。通過 SmartEncoding 的性能優(yōu)化，Server + ClickHouse 的資源消耗通常為業(yè)務(wù)消耗的 1%，即監(jiān)控100個 16c64g 的容器節(jié)點(diǎn)，大概需要1個 16c64g 的 Node 部署 Server + ClickHouse，且可以通過對象存儲轉(zhuǎn)儲冷數(shù)據(jù)；而且常見的可觀測性數(shù)據(jù)一般都需要注入百量級的標(biāo)簽，DeepFlow Agent 由于只注入了 VPC、GPID 少數(shù)幾個字段，因此它用于標(biāo)簽注入的資源消耗幾乎只有其他方案的百分之幾。這樣10x性能的使用體驗(yàn)，相信 Cloud-Native、NewOps 都會喜歡！后續(xù)我們會支持更豐富的自定義標(biāo)簽，包括通過 K8s API 獲取的k8s.annotation 和 k8s.env、通過操作系統(tǒng)獲取的 os.proc 信息、通過執(zhí)行命令獲取 os.app 信息；會從時間和帶寬消耗兩方面進(jìn)一步優(yōu)化AutoTagging的性能，通過不同類型資源的 API 可以設(shè)置不同的調(diào)用頻率，避免每次都是重新獲取全部資源來縮短縮短大規(guī)模下的資源同步時間；通過Agent 僅發(fā)送有變化的 K8s 資源信息，進(jìn)一步降低帶寬消耗。06、關(guān)于DeepFlow
DeepFlow[5]是一款開源的高度自動化的可觀測性平臺，是為云原生應(yīng)用開發(fā)者建設(shè)可觀測性能力而量身打造的全棧、全鏈路、高性能數(shù)據(jù)引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術(shù)，創(chuàng)新的實(shí)現(xiàn)了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機(jī)制，幫助開發(fā)者提升埋點(diǎn)插碼的自動化水平，降低可觀測性平臺的運(yùn)維復(fù)雜度。利用 DeepFlow 的可編程能力和開放接口，開發(fā)者可以快速將其融入到自己的可觀測性技術(shù)棧中。 審核編輯 ：李倩
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報(bào)投訴
-
核心技術(shù)
+關(guān)注
關(guān)注
4文章
625瀏覽量
19607 -
數(shù)據(jù)存儲
+關(guān)注
關(guān)注
5文章
971瀏覽量
50909 -
軟件架構(gòu)
+關(guān)注
關(guān)注
0文章
64瀏覽量
10288
原文標(biāo)題：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)
文章出處：【微信號：AI_Architect，微信公眾號：智能計(jì)算芯世界】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
5G手機(jī)?Redmi 10X性價比很高？Redmi 10X怎么樣？來看看Redmi 10X拆解
，Redmi又?jǐn)y手聯(lián)發(fā)科天璣820，發(fā)布Redmi 10X，最低售價1599。主打高性價比，是否如實(shí)，一拆便知。 本次拆解的是Redmi 10X，6GB RAM+ 128GB ROM版。以下數(shù)據(jù)信息均以拆解
示波器的10X檔和1X檔輸入阻抗
選擇1X檔時，信號是沒經(jīng)衰減進(jìn)入示波器的。而選擇10X檔時，信號是經(jīng)過衰減到1/10再到示波器的。當(dāng)選擇10X檔時，應(yīng)該將示波器上的讀數(shù)也擴(kuò)大10
發(fā)表于 05-20 14:43
10X genomics課程筆記
課程筆記10X genomics10X genomics技術(shù)：文獻(xiàn)在10X官網(wǎng)中的publications。對單個細(xì)胞做RNA表達(dá)情況的定量分析。基于油包水乳濁液酶反應(yīng)原理的分子生物學(xué)分析系統(tǒng)。可以
發(fā)表于 07-29 09:00
微軟承認(rèn)基于虛擬化的功能將會讓W(xué)indows 10X的性能更出色
Windows 10X遠(yuǎn)不只是Windows 10的新版本，因?yàn)樗辉O(shè)計(jì)為有著與Windows 7或Windows 10不同的應(yīng)用程序、文件和軟件交互體驗(yàn)。在Windows 10X系統(tǒng)
微軟Windows 10X系統(tǒng)支持UWP應(yīng)用和Win32應(yīng)用程序運(yùn)行
微軟確認(rèn)Windows 10X系統(tǒng)能夠運(yùn)行UWP應(yīng)用、網(wǎng)頁應(yīng)用以及傳統(tǒng)的Win32應(yīng)用程序。Win32、UWP和PWA應(yīng)用程序都會通過Windows 10X的容器進(jìn)行運(yùn)行，從而保護(hù)操作系統(tǒng)免受潛在的惡意軟件和性能問題的影響。
Windows 10X春季正式上線，面向輕量級設(shè)備
根據(jù)目前掌握的信息Windows 10X將會在今 12月進(jìn)入RTM階段，預(yù)估會在今年春季正式上線。而Windows 10X系統(tǒng)的主要更新會在每年的春季上線，因此微軟希望Windows 10給其讓路
微軟正式公開Windows 10X取代Windows 10，12月進(jìn)入RTM階段
微軟已經(jīng)正式公開了Windows 10X了，作為取代Windows 10的新系統(tǒng)，你對它期待嗎？ 根據(jù)目前掌握的信息Windows 10X將會在今年12月進(jìn)入RTM階段（下月就能用到），預(yù)估會在今年
Windows 10X今年即將到來？
微軟正在開發(fā)Windows 10X系統(tǒng)，已經(jīng)不是什么秘密了。最近更是有消息顯示，在本年度的12月份，微軟就會公布Windows 10X的RTM版本，在明年的1月份Win10X則會正式推向市場。 作為
微軟即將新推出Windows 10X系統(tǒng)
微軟正在開發(fā)Windows 10X系統(tǒng)，已經(jīng)不是什么秘密了。最近更是有消息顯示，在本年度的12月份，微軟就會公布Windows 10X的RTM版本，在明年的1月份Win10X則會正式推向市場。
盤點(diǎn)匯總Windows 10X的亮點(diǎn)功能
微軟已經(jīng)完成了Windows 10X的RTM版，并將分發(fā)給硬件制造商。預(yù)計(jì)，Windows 10X將于2021年初與微軟合作伙伴的硬件產(chǎn)品一起推出，包括惠普、戴爾、聯(lián)想等。
Windows 10X相較Windows 10有哪些亮點(diǎn)？
Windows 10X是一款面向雙屏可折疊設(shè)備的操作系統(tǒng)。在沉寂了幾個月后，微軟終于完成了Windows 10X的RTM版，后續(xù)將分發(fā)給硬件制造商，預(yù)計(jì)將于2021年初用在惠普、戴爾、聯(lián)想等品牌的硬件產(chǎn)品上。那么，Windows 10X
淺談Windows 10X與Windows 10的主要區(qū)別
Windows 10X是在Windows 10的基礎(chǔ)上開發(fā)，采用現(xiàn)代的組件取代舊的程序，用戶界面相似，但是取消了活動磁貼以及文件資源器等。Windows 10X在2020年12月就完成了RTM版，微軟計(jì)劃在3月-6月期間正式發(fā)布
微軟全面開放Windows 10X的鏡像
微軟傾力打造的Windows 10X系統(tǒng)已經(jīng)完全泄露，但鏡像僅支持Surface Pro 7。
10x無源探頭正確使用方法介紹
用好無源探頭。10x無源探頭的最佳用法使用10x無源探頭時，有五個重要的最佳測量準(zhǔn)則要遵守，以獲得10x探頭的最佳性能并避免常見的錯誤： 1、使用示波器前面板上的校準(zhǔn)參考信號來補(bǔ)償探頭
工商網(wǎng)監(jiān)
評論