一、為什么需要 OneAgent？

字節(jié)跳動(dòng)擁有海量的主機(jī)和微服務(wù)實(shí)例，涵蓋物理機(jī)、虛擬機(jī)、容器等多種場(chǎng)景，每秒產(chǎn)生的千億級(jí)別的可觀(guān)測(cè)性數(shù)據(jù)，在可觀(guān)測(cè)性數(shù)據(jù)采集和管道化處理等方面給技術(shù)團(tuán)隊(duì)帶來(lái)了巨大挑戰(zhàn)：

• 字節(jié)跳動(dòng)內(nèi)部存在多套可觀(guān)測(cè)系統(tǒng)和多個(gè)數(shù)據(jù)采集組件，一臺(tái)機(jī)器上往往需要部署多個(gè)遙測(cè)采集 Agent，造成了資源的浪費(fèi)。這些采集組件來(lái)自不同的團(tuán)隊(duì)，有些已經(jīng)年久失修無(wú)人維護(hù)，運(yùn)維和排障非常困難；
• 內(nèi)外一體逐漸成為集團(tuán)業(yè)務(wù)開(kāi)發(fā)的一個(gè)重點(diǎn)，很多業(yè)務(wù)使用開(kāi)源 SDK，也想統(tǒng)一接入公司的可觀(guān)測(cè)性平臺(tái)，采集組件側(cè)存在大量的適配工作；
• 字節(jié)跳動(dòng)內(nèi)場(chǎng)多年打磨的 M.T.L 引擎也將逐步上云產(chǎn)品化，我們需要保證內(nèi)外統(tǒng)一的觀(guān)測(cè)接入及產(chǎn)品體驗(yàn)。

字節(jié)可觀(guān)測(cè)性埋點(diǎn)現(xiàn)狀分析

為了解決上述問(wèn)題，技術(shù)團(tuán)隊(duì)決定構(gòu)建 OneAgent 組件，提供 Logs、Metrics、Trace 和 Event 采集解決方案。

OneAgent 是字節(jié)可觀(guān)測(cè)團(tuán)隊(duì)提供的新一代可觀(guān)測(cè)性數(shù)據(jù)[M.T.L.E]采集和處理管道（DataPipeline），目標(biāo)是讓 OneAgent 成為集團(tuán)和云上的首選可觀(guān)測(cè)性基礎(chǔ)設(shè)施，簡(jiǎn)化在云環(huán)境中接入可觀(guān)測(cè)性系統(tǒng)的復(fù)雜度，同時(shí)讓用戶(hù)可以輕松地從可觀(guān)測(cè)性數(shù)據(jù)中獲取更多價(jià)值。

OneAgent 中的 One 指的是統(tǒng)一和復(fù)用，我們希望它作為一款可觀(guān)測(cè)數(shù)據(jù)采集、預(yù)處理 Agent，能在系統(tǒng)中發(fā)揮以下作用：

• 數(shù)據(jù)采集統(tǒng)一：Metrics、Log、Trace、Event 能夠使用同一個(gè) agent 實(shí)現(xiàn)采集
• Client、Server 端復(fù)用：可以支持部署在 Client 端采集，也可以部署在 Server 側(cè)作為 Collector Proxy
• 內(nèi)外場(chǎng)復(fù)用：內(nèi)部和商業(yè)化版本的采集標(biāo)準(zhǔn)鏈路上，能夠使用同一個(gè) Agent 作為采集器

通過(guò)調(diào)研了社區(qū)內(nèi)現(xiàn)有的開(kāi)源解決方案，我們最終決定和 iLogtail 社區(qū)達(dá)成了共建合作，采用開(kāi)源 iLogtail 作為 OneAgent 的底座，同時(shí)將通用能力直接以開(kāi)源的工作方式貢獻(xiàn)回社區(qū)。

二、OneAgent 架構(gòu)

基于開(kāi)源項(xiàng)目的框架，字節(jié)跳動(dòng)云原生可觀(guān)測(cè)團(tuán)隊(duì)打造的 OneAgent 本身分為 C++ 編寫(xiě)的 core 部分，和以 Go 為主的插件系統(tǒng)部分。

Core 是 iLogtail 的主體，主要負(fù)責(zé) OneAgent 自身狀態(tài)的管理，包括配置的加載和監(jiān)聽(tīng)、流水線(xiàn)的啟停、保存 CheckPoint、自監(jiān)控、告警等，也包含了日志文件采集相關(guān)的邏輯。Go 插件系統(tǒng)則對(duì)接了多種可觀(guān)測(cè)性生態(tài)，包括 Prometheus、OpenTelemetry、SkyWalking 等生態(tài)的諸多插件，大大拓寬了 iLogtail 的應(yīng)用場(chǎng)景。

以語(yǔ)言為界，iLogtail 包含了 C++ 和 Go 兩種流水線(xiàn)，兩者之間可以通過(guò) cgo 的方式來(lái)交互。

1. C++ 流水線(xiàn)起源于日志文件采集，在 iLogtail 1.0 階段是固定的一條流水線(xiàn)，不支持編排，自由度較低。后來(lái)在 iLogtail 2.0 階段放開(kāi)了 C++ 流水線(xiàn)做了插件化改造，現(xiàn)在已經(jīng)支持編排能力，目前的 C++ 流水線(xiàn)處在高速迭代發(fā)展階段，不過(guò)總體插件生態(tài)仍然弱于 Go pipeline，可以通過(guò)調(diào)用 Go 插件增強(qiáng)處理數(shù)據(jù)的能力。
2. Go 的 pipeline 的生態(tài)更加豐富，對(duì)接了多種開(kāi)源協(xié)議。Go Pipeline 既能獨(dú)立運(yùn)行，也能借由 Core 拉起。在 iLogtail 1.0 階段，Go 流水線(xiàn)只能調(diào)用 C++ 寫(xiě)的一些 Processor 來(lái)加速處理數(shù)據(jù)。隨著 iLogtail 2.0 將兩條流水線(xiàn)的打通，數(shù)據(jù)只要進(jìn)入任意一條流水線(xiàn)，都能在兩條流水線(xiàn)中自由流動(dòng)。

云原生可觀(guān)測(cè)團(tuán)隊(duì)目前使用 OneAgent 的 Go 流水線(xiàn)來(lái)采集和處理 Metrics 和 Traces 數(shù)據(jù)，使用 C++ 流水線(xiàn)搭配 Go Flusher 插件做 Logs 文件采集。

三、基于業(yè)務(wù)場(chǎng)景的開(kāi)源改造

在實(shí)際開(kāi)發(fā)過(guò)程中，由于字節(jié)跳動(dòng)擁有龐大的業(yè)務(wù)規(guī)模和復(fù)雜的業(yè)務(wù)場(chǎng)景，單純的開(kāi)源版本并不能完全滿(mǎn)足現(xiàn)實(shí)需要。為此，我們對(duì)核心的數(shù)據(jù)模型、流水線(xiàn)、編排調(diào)度、構(gòu)建體系都做了深度改造。

原生的 Event 數(shù)據(jù)模型

社區(qū)版本的 pipeline 是以日志作為底座的，使用 SLS-PB 數(shù)據(jù)模型。雖然也可以處理 Metrics、Traces 數(shù)據(jù)，但是都得先轉(zhuǎn)化成日志，這往往會(huì)造成性能額外開(kāi)銷(xiāo)及兼容性問(wèn)題。以下述 metric 為例，metric 的字段使用特殊約定的 key 存儲(chǔ)，其中 metrics 的多個(gè) labels 以固定格式拼接到一個(gè)字段中，value 則通過(guò) string 格式存儲(chǔ)。

{
    "__name__":"net_out_pkt",
    "__labels__":"cluster#$#ilogtail-test-cluster|hostname#$#master-1-1.c-ca9717110efa1b40|hostname#$#test-1|interface#$#eth0|ip#$#10.1.37.31",
    "__time_nano__":"1680079323040664058",
    "__value__":"32.764761658490045",
    "__time__":"1680079323"
}

這帶來(lái)一些問(wèn)題：

• 對(duì) label 進(jìn)行操作就會(huì)引入反序列化開(kāi)銷(xiāo)；
• value 運(yùn)算前需要做轉(zhuǎn)換；
• value 不支持多值，傳輸效率低；
• 對(duì)一些社區(qū)比較流行的數(shù)據(jù)協(xié)議，例如 Prometheus，OpenTelemetry 等的兼容性不夠好。

為了解決上述問(wèn)題，我們開(kāi)發(fā)了基于新數(shù)據(jù)模型的 2.0 pipeline。2.0 Pipeline 中流動(dòng)的每一條數(shù)據(jù)定義為 PipelineEvent，Metric、Trace、Log、Bytes，Profiling 等都是派生自 PipelineEvent 的具體事件，大幅提升了靈活性：

type PipelineEvent interface {
        GetName() string

        SetName(string)

        GetTags() Tags

        GetType() EventType

        GetTimestamp() uint64

        GetObservedTimestamp() uint64

        SetObservedTimestamp(uint64)
}

PipelineEvent 不但可以攜帶更豐富的信息，也更適合做 data pipeline 內(nèi)的計(jì)算模型，大大提升了通用處理能力。

目前，我們已經(jīng)把這項(xiàng)改造貢獻(xiàn)給社區(qū)，社區(qū)也已經(jīng)接受這個(gè)新的數(shù)據(jù)模型為核心處理模型，后續(xù)新的插件都將支持新的數(shù)據(jù)模型，存量的插件也在逐漸適配支持。

全新的構(gòu)建方案

社區(qū)在 v1.4.0 之前要求插件必須放在項(xiàng)目主倉(cāng)庫(kù)內(nèi)，但互聯(lián)網(wǎng)時(shí)代，代碼是企業(yè)最核心的資產(chǎn)之一，受限于字節(jié)跳動(dòng)內(nèi)部的安全合規(guī)要求，一些插件必須放在公司內(nèi)部的私有倉(cāng)庫(kù)，不能貢獻(xiàn)到開(kāi)源社區(qū)。一般面對(duì)這種情況，我們只能 fork 一個(gè)新的倉(cāng)庫(kù)來(lái)增加一些內(nèi)部專(zhuān)用的插件，但這會(huì)導(dǎo)致我們和社區(qū)上游漸行漸遠(yuǎn)，既也不能享受開(kāi)源項(xiàng)目的新特性，也不利于把最終用戶(hù)的反饋反哺社區(qū)。

針對(duì)這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)了一種產(chǎn)物構(gòu)建機(jī)制，能夠合并官方倉(cāng)庫(kù)和私有倉(cāng)庫(kù)的插件，一起構(gòu)建出包。在方案上，我們重點(diǎn)參考了 OpenTelemetry Collector 的做法，使用 YAML 文件渲染成最終的 Go 文件。我們對(duì)倉(cāng)庫(kù)做了如下改造：

v1.4.0 之前，插件的引入都放在 plugins/all/all.go 下：

package all

import (
        _ "github.com/alibaba/ilogtail/plugins/aggregator"
        _ "github.com/alibaba/ilogtail/plugins/aggregator/baseagg"
        ...
)

v1.4.0 之后，項(xiàng)目主倉(cāng)庫(kù)添加 plugins.yml 文件，內(nèi)置插件都加到這個(gè)文件里面進(jìn)行注冊(cè)，默認(rèn)使用 plugins.yml 來(lái)生成內(nèi)置插件的 all.go 。同時(shí)編譯腳本支持傳遞多個(gè) *_plugins.yml ， 使用 external_plugins.yml 來(lái)加載外部倉(cāng)庫(kù)的插件，生成 external_all.go 文件。

plugin.yml:

plugins:
  common:
    - import: "github.com/alibaba/ilogtail/plugins/aggregator"
    - import: "github.com/alibaba/ilogtail/plugins/aggregator/baseagg"
    ...

external_plugins.yml:

plugins:    // 需要注冊(cè)的plugins，按適用的系統(tǒng)分類(lèi)
common:
    - gomod: code.private.org/private/custom_plugins v1.0.0  // 必須，插件module
      import: code.private.org/private/custom_plugins        // 可選，代碼中import的package路徑
      path: ../custom_plugins                            // 可選，replace 本地路徑，用于調(diào)試
windows:
linux:

project:
replaces:       // 可選，array，用于解決多個(gè)插件module之間依賴(lài)沖突時(shí)的問(wèn)題
go_envs:        // 可選，map，插件的repo是私有的時(shí)候，可以添加如GOPRIVATE環(huán)境等設(shè)置
  GOPRIVATE: *.code.org
git_configs:    // 可選，map，私有插件repo可能需要認(rèn)證，可以通過(guò)設(shè)置git url insteadof調(diào)整
  url.https://user:token@github.com/user/.insteadof: https://github.com/user/

有了這個(gè)能力之后，各個(gè)公司能更自由地開(kāi)發(fā)自己場(chǎng)景的插件，大大降低了開(kāi)發(fā)門(mén)檻，大幅提升了開(kāi)源項(xiàng)目的共建體驗(yàn)。

字節(jié)跳動(dòng)的插件配置（脫敏）

插件開(kāi)發(fā)

基于上述這兩個(gè)特性，我們開(kāi)發(fā)一系列 OneAgent 插件運(yùn)用在不同場(chǎng)景，很好地支撐了業(yè)務(wù)的需求：

輸入插件：

• Unix Domain Socket Input
• Prometheus Service Input V2
• OpenTelemetry Input
• HTTP Server Input V2
• Metrics TCP Server Input
• TTLogAgent Input

處理插件：

• Prometheus Metric Validator
• Telegraf Metric Filter

聚合插件：

• Metric Tag Aggregator

輸出插件：

• HTTP Flusher
• OTLP Flusher
• TTLogAgent Flusher

拓展插件：

• Metric Event Filter
• Byted Metrics Decoder
• Status Code Request Breaker

上述插件中的部分也已經(jīng)貢獻(xiàn)給開(kāi)源社區(qū)。

四、OneAgent 案例分享

本節(jié)將會(huì)介紹 3 個(gè)字節(jié)跳動(dòng)使用 OneAgent 的案例。

存儲(chǔ)底座替換 Telegraf

字節(jié)跳動(dòng)內(nèi)部某業(yè)務(wù)的存儲(chǔ)業(yè)務(wù)主要使用 BytedMetrics 1.0 SDK 進(jìn)行打點(diǎn)，使用 Metrics Agent（ms2）和 Telegraf 作為指標(biāo)采集的 Agent。這條采集鏈路過(guò)長(zhǎng)并且資源消耗過(guò)高，并且產(chǎn)品側(cè)指標(biāo)存在采集延遲、指標(biāo)丟點(diǎn)的問(wèn)題。部分業(yè)務(wù)單個(gè)實(shí)例每分鐘打點(diǎn)可達(dá)百萬(wàn)級(jí)，采集組件至多可以占用 16 核心，卻仍然受限于性能問(wèn)題，無(wú)法實(shí)時(shí)地上報(bào)監(jiān)控指標(biāo)，從而造成了產(chǎn)品側(cè)指標(biāo)采集延遲、丟點(diǎn)的問(wèn)題。

ms2 是字節(jié)跳動(dòng)自研的高性能指標(biāo)采集 Agent，用 C++ 實(shí)現(xiàn)，主要用來(lái)聚合，清洗，降級(jí)數(shù)據(jù)以及投遞數(shù)據(jù)，以 Daemonset 的形式部署在各個(gè)集群，終態(tài)會(huì)和 OneAgent 融合。詳細(xì)介紹見(jiàn)文章：字節(jié)跳動(dòng)百萬(wàn)級(jí) Metrics Agent 性能優(yōu)化的探索與實(shí)踐

BytedMetrics SDK 1.0 是字節(jié)自研的第一代打點(diǎn) SDK，依賴(lài) ms2 做數(shù)據(jù)聚合。

BytedMetrics SDK 2.0 是字節(jié)自研的第二代高性能打點(diǎn) SDK，具有數(shù)據(jù)聚合能力，性能領(lǐng)先 Prometheus SDK 2-5 倍。

Telegraf 是 InfluxData 公司開(kāi)發(fā)的一款開(kāi)源指標(biāo)采集 Agent，用于主機(jī)指標(biāo)和業(yè)務(wù)指標(biāo)的采集，現(xiàn)在逐步被 OneAgent 替換。

為了解決上述問(wèn)題，我們使用 OneAgent 作為新的指標(biāo)采集 Agent，現(xiàn)階段已經(jīng)使用 OneAgent 平替 Telegraf，降低了采集 Agent 80%的 CPU 占用，解決了業(yè)務(wù)的監(jiān)控丟點(diǎn)和延遲問(wèn)題。

OneAgent上線(xiàn)效果

該業(yè)務(wù)用戶(hù)的打點(diǎn)方式多種多樣，涵蓋了 BytedMetrics 1.0 SDK、BytedMetrics 2.0 SDK、InfluxDB SDK、Prometheus Exporter、OpenTelemetry SDK 等。過(guò)去需要部署多個(gè) Agent 進(jìn)行采集，這不僅導(dǎo)致了資源的浪費(fèi)，還增加了運(yùn)維成本。如今，OneAgent 已經(jīng)能夠接收除 BytedMetrics 1.0 SDK 以外的所有數(shù)據(jù)，成功收斂了數(shù)個(gè)采集 Agent。

隨著業(yè)務(wù)逐漸接入 BytedMetrics 2.0 SDK，以及我們下一個(gè)階段對(duì) C++流水線(xiàn)的改造，最終 OneAgent 將取代 ms2，成為該業(yè)務(wù)唯一的可觀(guān)測(cè)數(shù)據(jù)采集 Agent，從而進(jìn)一步節(jié)省資源，這也是我們的最終目標(biāo)。

日志文件采集

字節(jié)跳動(dòng)內(nèi)部主流是 Go 微服務(wù)，主要使用侵入式的 BytedLogs SDK 來(lái)記錄日志，SDK 通過(guò) Unix Domain Socket 上報(bào)給本機(jī)的 TTLogAgent，可以實(shí)現(xiàn)無(wú)盤(pán)化采集日志。

TTLogAgent 是字節(jié)自研的日志采集 Agent，用 Go 實(shí)現(xiàn)，主要用來(lái)接收 Log SDK 上報(bào)的數(shù)據(jù)并發(fā)送到后端，同時(shí)也支持日志文件采集，日志降級(jí)，錯(cuò)誤日志分流等功能，以 daemonset 的形式部署在各個(gè)集群，最終會(huì)被 OneAgent 替換。

Logs SDK 是字節(jié)自研的高性能日志 SDK，采用鏈?zhǔn)?API，性能屬于業(yè)內(nèi)第一梯隊(duì)。

這也帶來(lái)一些問(wèn)題：

1. 如果進(jìn)程發(fā)生不可恢復(fù)的錯(cuò)誤，崩潰信息無(wú)法及時(shí)上報(bào)，這部分 stdout/stderr 輸出會(huì)重定向到一個(gè)文件中，當(dāng)前依賴(lài)一個(gè)腳本工具上報(bào) panic 日志。
2. 隨著公司上云和內(nèi)外一體策略，一些業(yè)務(wù)使用了開(kāi)源組件打日志，無(wú)法接入字節(jié)跳動(dòng)內(nèi)部的日志平臺(tái)，需要使用文件采集方案。

TTLogAgent 文件采集能力較弱，對(duì)日志的處理通用性也不夠，不支持正則處理多行日志，無(wú)法開(kāi)放給所有用戶(hù)使用。在對(duì)比 TTLogAgent 與 iLogtail 的優(yōu)劣之后，我們決定復(fù)用 OneAgent 的這部分能力，將 TTLogAgent 改造成 OneAgent 的一個(gè)插件。

事件驅(qū)動(dòng)的文件采集

OneAgent 采用了輪詢(xún)（polling）與事件（inotify）并存的模式進(jìn)行日志采集，既借助了 inotify 的低延遲與低性能消耗的特點(diǎn)，也通過(guò)輪詢(xún)的方式兼顧了運(yùn)行環(huán)境的全面性，可以實(shí)現(xiàn)毫秒級(jí)的日志采集的延遲控制，很好地應(yīng)對(duì)字節(jié)跳動(dòng)當(dāng)前的日志壓力。

改造后 TTLogAgent 變成了 OneAgent 的一個(gè)插件：

后續(xù)我們會(huì)把 TTLogAgent 的功能逐步遷移到 OneAgent，最終下線(xiàn) TTLogAgent。

對(duì)接開(kāi)源生態(tài)

OneAgent 不但可以作為采集 Agent，也可以部署成服務(wù)作為 Proxy 或 Gateway。字節(jié)跳動(dòng)內(nèi)部部署了多個(gè) OneAgent 服務(wù)，幫助用戶(hù)接入不同的可觀(guān)測(cè)性平臺(tái)，實(shí)現(xiàn)內(nèi)外一體的觀(guān)測(cè)體驗(yàn)。

• 有團(tuán)隊(duì)部署了 OneAgent 服務(wù)作為 Prometheus Remote Write 的后端，將指標(biāo)寫(xiě)入公司自研時(shí)序數(shù)據(jù)庫(kù) ByteTSD。

• 有團(tuán)隊(duì)使用 InfluxDB SDK 通過(guò) OneAgent 接入 ByteTSD 和 InfluxDB。

• 有團(tuán)隊(duì)使用 OpenTemetry SDK 通過(guò) OneAgent 寫(xiě)入內(nèi)場(chǎng)可觀(guān)測(cè)性平臺(tái)。

五、未來(lái)展望

根據(jù)后續(xù)規(guī)劃，未來(lái)我們會(huì)持續(xù)增強(qiáng) OneAgent 能力，提升其穩(wěn)定性和易用性。同時(shí)我們也會(huì)深度參與開(kāi)源社區(qū)共建，和廣大開(kāi)發(fā)者共同打造領(lǐng)先的可觀(guān)測(cè)數(shù)據(jù)采集器：

• 實(shí)現(xiàn) OneAgent 多 pipeline 的連接，增強(qiáng)數(shù)據(jù)處理能力。
• 擴(kuò)展增強(qiáng) C++ 的 pipeline，更高性能地處理 Metrics 和 Trace 數(shù)據(jù)，在一些計(jì)算密集型場(chǎng)景，Go 插件的處理能力還無(wú)法和 C++ 組件對(duì)齊。
• 加快 OneAgent 運(yùn)維控制面建設(shè)。
• 收斂目前字節(jié)內(nèi)部的 Agent 到 OneAgent，首先考慮融合 Telegraf、ms2 及 TTLogagent。

六、引用

字節(jié)跳動(dòng)百萬(wàn)級(jí) Metrics Agent 性能優(yōu)化的探索與實(shí)踐：https://mp.weixin.qq.com/s/bl1HbC6ti6Pw2FGxgstfBw

節(jié)約資源、提升性能，字節(jié)跳動(dòng)超大規(guī)模 Metrics 數(shù)據(jù)采集的優(yōu)化之道：https://mp.weixin.qq.com/s/spHNCBWfgOCHSomLvp5aWA

OpenTelemetry Collector Connector: https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md

云原生可觀(guān)測(cè)團(tuán)隊(duì)

字節(jié)跳動(dòng)云原生可觀(guān)測(cè)（Cloud Native-Observability）團(tuán)隊(duì)提供日均數(shù)十 PB 級(jí)可觀(guān)測(cè)性數(shù)據(jù)采集、存儲(chǔ)和查詢(xún)分析的引擎底座，致力于為業(yè)務(wù)、業(yè)務(wù)中臺(tái)、基礎(chǔ)架構(gòu)建設(shè)完整統(tǒng)一的可觀(guān)測(cè)性技術(shù)支撐能力。同時(shí)，團(tuán)隊(duì)也正通過(guò)火山引擎持續(xù)對(duì)外輸出云上可觀(guān)測(cè)技術(shù)能力。