建站
咨詢
售后
建站咨詢
新聞中心
一、如何定義 DeepFlow Wasm Plugin ？
DeepFlow 的 Wasm Plugin 機(jī)制是整個 DeepFlow Pipeline 機(jī)制中的重要組成部分，它為用戶提供了一個可編程的、安全的和資源消耗可控的運(yùn)行沙箱環(huán)境。此機(jī)制為 deepflow-agent 增加了靈活性和可擴(kuò)展性，使用戶能夠以一種安全可靠的方式自定義和擴(kuò)展代理的功能。
1、Wasm Plugin 機(jī)制為用戶提供了可編程性
通過使用 Wasm 編程語言，用戶可以編寫自定義的插件邏輯，以滿足特定的需求和應(yīng)用場景。這種可編程性使得用戶能夠根據(jù)具體的業(yè)務(wù)需求，對流量進(jìn)行更細(xì)粒度的處理和分析。用戶可以通過編寫自定義的 Wasm 模塊來實(shí)現(xiàn)特定的協(xié)議解析、數(shù)據(jù)處理、安全策略等功能，從而高度定制化代理的行為。
2、Wasm Plugin 機(jī)制提供了安全性
Wasm Plugin 運(yùn)行在一個安全的沙箱環(huán)境中，這意味著插件的執(zhí)行受到嚴(yán)格的限制和監(jiān)控，以確保其不會對代理的穩(wěn)定性和安全性造成威脅。Wasm 的設(shè)計理念和安全機(jī)制使得插件的運(yùn)行受到嚴(yán)格的隔離，防止惡意插件對代理或底層系統(tǒng)進(jìn)行攻擊或?yàn)E用資源。這種安全性保證了代理的運(yùn)行環(huán)境的可信度和可靠性。
3、Wasm Plugin 機(jī)制還具有資源消耗可控性
通過限制插件的資源使用，例如 CPU 時間、內(nèi)存等，Agent 可以有效地控制插件的運(yùn)行消耗，以避免插件對代理性能產(chǎn)生不利影響。這種資源消耗可控性使得代理能夠在處理大規(guī)模流量時保持高效和穩(wěn)定，避免因插件的運(yùn)行而引起的性能下降或崩潰。
綜上，DeepFlow Wasm Plugin 機(jī)制通過增強(qiáng)原生支持的協(xié)議、支持私有協(xié)議解析、提供零侵?jǐn)_分布式追蹤和自定義脫敏功能等，為用戶提供了更強(qiáng)大和靈活的工具。這些增強(qiáng)功能使得用戶能夠深入分析和處理協(xié)議數(shù)據(jù)，滿足不同業(yè)務(wù)場景需求，并提升系統(tǒng)的性能、安全性和可擴(kuò)展性。
二、DeepFlow Wasm Plugin 到底是如何工作的？
在深入了解 Wasm Plugin 的執(zhí)行流程之前，建議先對 Deepflow 協(xié)議解析有一個基本的認(rèn)識。了解 Deepflow 協(xié)議解析的概念和原理可以為理解 Wasm Plugin 的執(zhí)行流程提供有益的背景知識。
當(dāng)我們提及 Wasm Plugin 時，通常作用于 Web 瀏覽器中執(zhí)行高性能的計算任務(wù)，而 Deepflow 協(xié)議解析則涉及到數(shù)據(jù)傳輸和處理的協(xié)議層面。通過深入了解 Deepflow 協(xié)議解析，我們可以更好地理解 Wasm Plugin 在數(shù)據(jù)傳輸和處理過程中的作用和應(yīng)用。因此，在探討 Wasm Plugin 的執(zhí)行流程之前，對 Deepflow 協(xié)議解析進(jìn)行一個基本的認(rèn)識是非常有幫助的，它為我們建立起了一個更完整和全面的技術(shù)背景，使我們能夠更好地理解和應(yīng)用 Wasm Plugin 的相關(guān)概念和功能。
在 deepflow-agent 中，數(shù)據(jù)包從原始字節(jié)轉(zhuǎn)化為應(yīng)用層結(jié)構(gòu)的過程涉及以下幾個關(guān)鍵階段。在這些階段中，我們會使用到一些重要的數(shù)據(jù)結(jié)構(gòu)和接口，它們發(fā)揮著關(guān)鍵的作用，具體可參考：
1、L7Protocol（第七層協(xié)議）：其源碼位于 l7_protocol.rs 文件中。L7Protocol 用于標(biāo)識不同的協(xié)議常量，例如 HTTP、HTTPS、DNS 等。通過使用 L7Protocol，我們可以在流量中準(zhǔn)確地識別和標(biāo)記不同的應(yīng)用層協(xié)議。
2、L7ProtocolParser（第七層協(xié)議解析器）：其源碼位于 l7_protocol_log.rs 文件中。這個 trait 主要用于協(xié)議的判斷和解析，它能夠根據(jù)特定的規(guī)則和模式，從流量數(shù)據(jù)中解析出 L7ProtocolInfo（第七層協(xié)議信息）。L7ProtocolParser 的實(shí)現(xiàn)類可以根據(jù)具體的協(xié)議特征，進(jìn)行解析和識別，從而獲得有關(guān)協(xié)議的詳細(xì)信息。
3、L7ProtocolInfo（第七層協(xié)議信息）：其源碼位于 l7_protocol_info.rs 文件中。L7ProtocolInfo 是由 L7ProtocolParser 解析出來的數(shù)據(jù)結(jié)構(gòu)，它包含了有關(guān)協(xié)議的詳細(xì)信息，例如協(xié)議類型、協(xié)議版本、源IP地址、目標(biāo)IP地址等。L7ProtocolInfo 在后續(xù)的會話聚合和分析中發(fā)揮著重要的作用。
4、L7ProtocolInfoInterface（第七層協(xié)議信息接口）：其源碼同樣位于 l7_protocol_info.rs 文件中。所有的 L7ProtocolInfo 都需要實(shí)現(xiàn)這個接口，以提供一致的方法和屬性。通過實(shí)現(xiàn) L7ProtocolInfoInterface，我們可以對協(xié)議信息進(jìn)行統(tǒng)一的操作和處理，以滿足后續(xù)的需求。
5、L7ProtocolSendLog（發(fā)送到深度流分析服務(wù)器的第七層協(xié)議日志）：其源碼位于 pb_adapter.rs 文件中。L7ProtocolSendLog 是一個結(jié)構(gòu)體，用于將解析后的第七層協(xié)議信息統(tǒng)一發(fā)送到深度流分析服務(wù)器。通過使用 L7ProtocolSendLog，我們可以將協(xié)議信息傳遞給服務(wù)器進(jìn)行進(jìn)一步的處理和分析。
通過以上組件和接口的協(xié)同工作，deepflow-agent 能夠準(zhǔn)確地識別和解析不同的應(yīng)用層協(xié)議，并將相關(guān)的協(xié)議信息發(fā)送到 deepflow-server器，為后續(xù)的流量分析和應(yīng)用提供有價值的數(shù)據(jù)基礎(chǔ)。這些組件和接口的設(shè)計和實(shí)現(xiàn)，為 deepflow-agent 的功能和性能提供了堅實(shí)的基礎(chǔ)。
綜上所述，針對 Deepflow 協(xié)議解析而言，其整體的流程可概括為如下：
了解完 Deepflow 的協(xié)議解析后，我們回到 Wasm plugin，Wasm plugin 整體的執(zhí)行流程如下所示：
針對上述執(zhí)行流程結(jié)構(gòu)，其中序列化/反序列化的結(jié)構(gòu)主要涉及如下6個，具體可參考如下：
- VmCtxBase
在目前所有的 Export 函數(shù)調(diào)用的時候，host 會將 VmCtxBase 序列化到線性內(nèi)存，序列化的格式參考：vm.rs#L199
同樣地，instance 也會反序列化，具體代碼可以參考：mod.rs#L152
- L7ProtocolInfo
在 Export 函數(shù) parse_payload 最后，instance 會序列化 L7ProtocolInfo 到線性內(nèi)存，
host 也會反序列化。
- VmHttpReqCtx
在 http 請求解析完成返回之前，會調(diào)用 Export 函數(shù) on_http_req，host 會序列化 VmCtxBase 和 VmHttpReqCtx 到 instance 的線性內(nèi)存
VmHttpReqCtx 的序列化的代碼和格式可以參考：vm.rs#L328instance 反序列化的代碼參考：serde.go#L173
-
VmHttpRespCtx
在 http 響應(yīng)解析完成返回之前，會調(diào)用 Export 函數(shù) on_http_resp，host 會序列化 VmCtxBase 和 VmHttpRespCtx 到 instance 的線性內(nèi)存
VmHttpRespCtx 的序列化的格式參考：vm.rs#L395
instance 反序列化的代碼參考：serde.go#L232
-
Trace，[]KeyVal
在 Export 函數(shù) on_http_req/on_http_resp 返回之前，instance 會將 Trace 和 []KeyVal 序列化到線性內(nèi)存
序列化的代碼和格式可以參考：serde.go#L515
反序列化的代碼和格式可參考：abi_import.rs#L376
三、如何基于 Golang SDK 開發(fā) DeepFlow Wasm Plugin ？
通常而言，Wasm Plugin 可支持多種語言進(jìn)行開發(fā)。這里，我們以 Golang 為例，簡要解析如何使用 Golang 快速開發(fā) Wasm Plugin。需要注意的是，本項(xiàng)目中 Golang SDK 編譯需要用到 TinyGo 工具鏈。
為什么需要 TinyGo ？
TinyGo 是一個專門為嵌入式設(shè)備和 WebAssembly（Wasm）環(huán)境設(shè)計的 Go 編程語言工具鏈。它是 Go 語言的一個輕量級替代品，旨在在資源受限的環(huán)境中運(yùn)行和編譯 Go 代碼。
TinyGo 的目標(biāo)是提供一個高效的 Go 編譯器和運(yùn)行時環(huán)境，以便在小型設(shè)備和嵌入式系統(tǒng)上運(yùn)行 Go 程序。相較于標(biāo)準(zhǔn)的 Go 編譯器，TinyGo 優(yōu)化了編譯輸出的大小和性能，以適應(yīng)資源受限的環(huán)境。這使得開發(fā)者可以使用 Go 語言的簡潔性和強(qiáng)大的工具生態(tài)系統(tǒng)來構(gòu)建嵌入式系統(tǒng)、物聯(lián)網(wǎng)設(shè)備和其他資源有限的應(yīng)用。
除了針對嵌入式設(shè)備，TinyGo 還支持 WebAssembly，使得開發(fā)者可以使用 Go 語言編寫的代碼在 Web 瀏覽器環(huán)境中運(yùn)行。這使得開發(fā)者可以在瀏覽器中直接運(yùn)行高性能的 Go 代碼，從而擴(kuò)展了 Go 語言的應(yīng)用范圍。
針對 Wasm Plugin 的開發(fā)實(shí)現(xiàn)，我們可以參考：https://deepflow.io/docs/zh/integration/process/wasm-plugin/，其關(guān)鍵步驟主要涉及如下，具體：
1、 獲取 Golang SDK 進(jìn)行項(xiàng)目創(chuàng)建
go mod init {ProjectName}
go get github.com/deepflowio/deepflow-wasm-go-sdk需要注意的是：確保在執(zhí)行這些命令之前，已經(jīng)正確設(shè)置了 Go 開發(fā)環(huán)境，并且可以訪問 GitHub。
2、 實(shí)現(xiàn)協(xié)議解析邏輯
package main
import (
"github.com/deepflowio/deepflow-wasm-go-sdk/sdk"
)
func main(){
sdk.Warn("plugin loaded")
sdk.SetParser(SomeParser{})
}
type SomeParser struct {
}
func (p SomeParser) HookIn() []sdk.HookBitmap {
return []sdk.HookBitmap{
// 一般只需要 hook 協(xié)議解析
sdk.HOOK_POINT_PAYLOAD_PARSE,
}
}
func (p SomeParser) OnHttpReq(ctx *sdk.HttpReqCtx) sdk.Action {
return sdk.ActionNext()
}
func (p SomeParser) OnHttpResp(ctx *sdk.HttpRespCtx) sdk.Action {
return sdk.ActionNext()
}
func (p SomeParser) OnCheckPayload(ctx *sdk.ParseCtx) (uint8, string) {
// 這里是協(xié)議判斷的邏輯， 返回 0 表示失敗
// return 0, ""
return 1, "some protocol"
}
func (p SomeParser) OnParsePayload(ctx *sdk.ParseCtx) sdk.Action {
// 這里是解析協(xié)議的邏輯
if ctx.L4 != sdk.TCP|| ctx.L7 != 1{
return sdk.ActionNext()
}
return sdk.ActionNext()
}注：以上是一個簡單的插件示例，展示了如何使用 "deepflowio/deepflow-wasm-go-sdk" 庫來開發(fā)自定義的插件，并實(shí)現(xiàn)不同的回調(diào)函數(shù)來處理網(wǎng)絡(luò)數(shù)據(jù)包。在實(shí)際的業(yè)務(wù)場景中，我們可以根據(jù)自己的需求進(jìn)一步擴(kuò)展和修改這些回調(diào)函數(shù)的實(shí)現(xiàn)邏輯，以滿足自身的場景訴求。
3、編譯為 Wasm Plugin
# 建議 go 版本不低于1.21，tinygo 版本不低于 0.29
tinygo build -o wasm.wasm -target wasi -gc=precise -panic=trap -scheduler=none -no-debug *.go執(zhí)行命令后，將會生成名為"wasm.wasm"的WebAssembly文件，可以在支持 WebAssembly 的環(huán)境中加載和運(yùn)行。
Wasm Plugin 開發(fā)完后，我們需要將其部署至 DeepFlow 中，針對 Wasm Plugin 的部署主要涉及如下步驟：
1、將編譯好的插件上傳至 Deepflow-Server
deepflow-ctl plugin create --type wasm --image wasm.wasm --name wasm-devops執(zhí)行命令后，Deepflow-ctl 將會創(chuàng)建一個名為"wasm-devops"的 WebAssembly 插件，并將指定的 WebAssembly 文件作為插件的執(zhí)行代碼。我們可以根據(jù)需要進(jìn)一步配置和管理這個插件。
2、Agent 端加載 Wasm Plugin
static_config:
ebpf:
# 對于 deepflow-agent 原生不支持的協(xié)議， eBPF 數(shù)據(jù)需要添加端口白名單才能上報
kprobe-whitelist:
port-list: 9999
# 如果配置了 l7-protocol-enabled，別忘了放行 Custom 類型的協(xié)議
l7-protocol-enabled:
- Custom
# other protocol
wasm-plugins:
- wasm-devops // 對應(yīng) deepflow-ctl 上傳插件的名稱注：目前修改此配置后 deepflow-agent 會自動重啟。
3、驗(yàn)證是否成功加載
kubectl -n deepflow logs -f deepflow-agent-xxxxx | grep -i plugin至此，一個 Wasm Plugin 已成功開發(fā)完成，并應(yīng)用至我們的業(yè)務(wù)場景中。
四、案例分享 - 解析 JSON 中的錯誤信息
在此案例中，被監(jiān)控 HTTP API 的響應(yīng)消息為 JSON 格式，當(dāng) API 出錯時 HTTP 協(xié)議的狀態(tài)碼可能仍然是 200，確切的錯誤信息通過 JSON 中的 OPT_STATUS 等字段返回：
{ "OPT_STATUS": "AUTH_HEADER_ERROR", // 不等于 SUCCESS 時表示調(diào)用失敗
"DESCRIPTION": "請傳遞正確的驗(yàn)證頭信息", // 詳細(xì)錯誤信息
... // 其他返回字段
}查閱 API 文檔后我們得知，OPT_STATUS 的值不等于 SUCCESS 時表示 API 調(diào)用失敗。在常規(guī)的 DeepFlow 解析流程中，會按照如下方式構(gòu)造 HTTP 調(diào)用日志的各個字段：
- response_code：賦值為 HTTP 響應(yīng)頭中的狀態(tài)碼，例如 200、404、500 等
- response_status：狀態(tài)碼小于 400 時認(rèn)為正常，4XX 認(rèn)為是客戶端異常，5XX 認(rèn)為是服務(wù)端異常
- response_exception：賦值為 HTTP 異常狀態(tài)碼對應(yīng)的英文解釋，例如 404 時此字段賦值為 Not Found
- response_result：當(dāng) HTTP 狀態(tài)碼為異常時賦值為整個 HTTP Payload
當(dāng)我們安裝了 Wasm 插件后，我們可以在上述解析的基礎(chǔ)上，將失敗 API 的調(diào)用日志中的如下字段進(jìn)行覆寫，以實(shí)現(xiàn)正確體現(xiàn)業(yè)務(wù)錯誤的效果：
- response_code：當(dāng) JSON 中 OPT_STATUS != SUCCESS、且 HTTP 狀態(tài)碼小于 400 時，此值覆寫為 500
- response_status：按照新的 response_code 重新賦值，例如 500 時賦值為服務(wù)端異常
- response_exception：當(dāng) JSON 中的 OPT_STATUS != SUCCESS時覆寫為 DESCRIPTION 字段的值
- response_result：當(dāng) response_code 大于等于 400 時賦值為整個 JSON Payload
我們將 Wasm 插件代碼放到了這個 GitHub 倉庫中。上述 API 行為描述的實(shí)際上是 DeepFlow 企業(yè)版中的 statistics 服務(wù)，下面演示將此 Wasm 插件注入到 DeepFlow Agent 以后，對 DeepFlow 企業(yè)版服務(wù)的自我觀測效果。首先我們在命令行中觸發(fā)一次 statistics 服務(wù)的 API 調(diào)用：
# 請求
curl https://cloud.deepflow.io/api/statistics/v1/stats/querier/DBDescription/ShowDatabases
# HTTP 響應(yīng)頭
HTTP/2 401
date: Tue, 22 Aug 2023 01:44:29 GMT
content-type: application/json
content-length: 152
# HTTP 響應(yīng)體
{
"DATA": false,
"DESCRIPTION": "請傳遞正確的驗(yàn)證頭信息",
"ERR": null,
"LEVEL": 0,
"OPT_STATUS": "AUTH_HEADER_ERROR"
}上述 API 響應(yīng)中，HTTP 的狀態(tài)碼為 401，OPT_STATUS=AUTH_HEADER_ERROR。我們能在 DeepFlow 頁面正確的看到客戶端異常指標(biāo)（本例中插件注入在 cloud.deepflow K8s 集群的 deepflow-agent 中）：
在 DeepFlow 調(diào)用日志頁面，可以看到客戶端異常的調(diào)用日志的詳情信息，整個 JSON body 放在了 response_result里面：
對該調(diào)用發(fā)起追蹤，能看到是因?yàn)閒auths返回的 401 異常：
下面是詳細(xì)的調(diào)用鏈。第一步發(fā)起 DNS 請求：
第二步調(diào)用后端服務(wù)驗(yàn)證 License：
第三步發(fā)起 DNS 請求 fauths 服務(wù)的地址：
第四步調(diào)用 fauth 的 /auth API 驗(yàn)證權(quán)限，中間需要訪問 Redis 獲取用戶信息：
上述案例展示了 DeepFlow 中Wasm Plugin 機(jī)制的強(qiáng)大能力，使得在實(shí)際業(yè)務(wù)場景中能夠輕松解決問題的跟蹤、定位和分析。
通過使用自定義的 Wasm Plugin，我們可以針對特定需求開發(fā)定制化的功能，如解析 JSON 中的錯誤信息。這種能力使得我們能夠在流量處理過程中靈活地捕捉和處理問題，無論是在調(diào)試階段還是在生產(chǎn)環(huán)境中。
使用 DeepFlow 的 Wasm Plugin 機(jī)制，我們可以輕松地擴(kuò)展原生協(xié)議的解析能力，提取更多的業(yè)務(wù)信息。特別是對于私有協(xié)議，如 Protobuf 和 Thrift，我們可以通過自定義插件來解析這些依賴 Schema 的 Payload 內(nèi)容，從中提取關(guān)鍵的業(yè)務(wù)字段。這為我們深入了解協(xié)議數(shù)據(jù)提供了便利，使得我們能夠更好地理解和利用數(shù)據(jù)。
網(wǎng)站題目：DeepFlow是如何通過WasmPlugin實(shí)現(xiàn)業(yè)務(wù)可觀測性？
URL分享：http://www.fisionsoft.com.cn/article/dpihjgh.html
