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

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

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

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

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

可觀測性建設(shè)數(shù)據(jù)關(guān)聯(lián)難可觀測性指標數(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/...。

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

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

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

03、AutoTagging：構(gòu)建標準化的標簽體系

AutoTagging通過云API、K8s apiserver自動同步30多種資源標簽、100多種自定義微服務標簽，來構(gòu)建標準化的標簽體系。

DeepFlow資源同步DeepFlow的標簽體系：

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

下面，我們依次介紹一下對各類資源信息的同步機制，以實現(xiàn)標簽庫的構(gòu)建。同步 K8s 資源:

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

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

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

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

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

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

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

SmartEncoding 將標簽注入分為3個階段，通過采集時編碼、存儲時編碼、和查詢時編/解碼降低標簽寫入的資源消耗，我們來詳細看看每個階段都如何實現(xiàn)：采集時編碼

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

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

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

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

SELECTcol_1,col_2,col_3 FROMtbl_1 WHEREcol_4=y GROUPBYcol_1,col_2 HAVINGcol_5>100 ORDERBYcol_3 LIMIT100 ``` 我們可以查詢某個 Tag 的所有候選項： ```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 更多詳細用法^[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對應的資源ID', `l3_device_type`UInt8COMMENT'ip對應的資源類型', `l3_epc_id`Int32COMMENT'ip對應的EPCID', `pod_cluster_id`UInt16COMMENT'ip對應的容器集群ID', `pod_group_id`UInt32COMMENT'ip對應的容器工作負載ID', `pod_id`UInt32COMMENT'ip對應的容器PODID', `pod_node_id`UInt32COMMENT'ip對應的容器節(jié)點ID', `pod_ns_id`UInt16COMMENT'ip對應的容器命名空間ID' ) ENGINE=Distributed(...)

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

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

通過 dictGet 實現(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對應關(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 實現(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 類型，一一對應。

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

Tag 候選項只需要保留不重復的值，所以我們使用 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 進行 name 和 value 的對應

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ù)迭代計劃

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

06、關(guān)于DeepFlow

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

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

核心技術(shù)

核心技術(shù)

+關(guān)注

關(guān)注
4

文章
625

瀏覽量
20420
數(shù)據(jù)存儲

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

+關(guān)注

關(guān)注
5

文章
1008

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

軟件架構(gòu)

+關(guān)注

關(guān)注
0

文章
64

瀏覽量
10583

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

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

18video性欧美19sex,欧美高清videosddfsexhd,性少妇videosexfreexxx片中国,激情五月激情综合五月看花,亚洲人成网77777色在线播放

搜索歷史

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

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

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

03、AutoTagging：構(gòu)建標準化的標簽體系

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

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

06、關(guān)于DeepFlow

評論

搜索歷史

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

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

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

03、AutoTagging：構(gòu)建標準化的標簽體系

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

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

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

評論

03、AutoTagging：構(gòu)建標準化的標簽體系

06、關(guān)于DeepFlow