本文根據(jù)余韜老師在 GOPS 2022·上海站演講整理而成，更多精彩，請關(guān)注高效運(yùn)維公眾號。

作者簡介：
余韜，阿里巴巴技術(shù)專家。
10年工作經(jīng)驗(yàn)，目前就職于阿里巴巴日志服務(wù)可觀測平臺團(tuán)隊(duì)，負(fù)責(zé)iLogtail開源，主要關(guān)注大數(shù)據(jù)分析、數(shù)據(jù)采集Agent、海量數(shù)據(jù)接入治理等領(lǐng)域。
曾負(fù)責(zé)百度統(tǒng)計(jì)、百度分析云產(chǎn)品的研發(fā)工作。

一、可觀測數(shù)據(jù)類型與價(jià)值

1.1 IT系統(tǒng)的可觀測性

“可觀測性”最早起源于電氣領(lǐng)域，指的是一個(gè)系統(tǒng)如果是可觀測的，它的狀態(tài)可以由外部輸出來推斷。比如一個(gè)汽車引擎，普通告警只能知道它的總體狀態(tài)，如果加入儀表盤，比如水溫、氣壓、轉(zhuǎn)速，我們就可以大致定位它的故障方向，如果要解決這個(gè)問題，還是要依賴于組件內(nèi)每個(gè)傳感器的詳細(xì)觀測數(shù)據(jù)。

在IT系統(tǒng)領(lǐng)域，可觀測性卻是近幾年才越來越熱的，我覺得和IT系統(tǒng)的發(fā)展有一定關(guān)系。最初軟件系統(tǒng)相對簡單，開發(fā)工作僅由幾個(gè)人就能完成，每個(gè)人都對整個(gè)系統(tǒng)有完整了解。隨著業(yè)務(wù)越來越復(fù)雜，涉及到的模塊越來越多，很難有一個(gè)人了解系統(tǒng)全貌，此時(shí)就需要通過將它的可觀測性數(shù)據(jù)展示出來以定位問題。

隨著軟件的復(fù)雜性增加，跨團(tuán)隊(duì)合作也會越來越多，團(tuán)隊(duì)間的溝通或排障也需要提高效率，防止推諉，因此需要拿數(shù)據(jù)說話，對可觀測性數(shù)據(jù)的需求也越來越突出。軟件運(yùn)行環(huán)境也隨著系統(tǒng)的基礎(chǔ)組件云化趨勢，變得越來越復(fù)雜。從單機(jī)到容器化，再到現(xiàn)在的云原生。越來越多的組件依賴第三方或者云上的云原生接口，使這個(gè)系統(tǒng)越來越像一個(gè)黑盒，不利于穩(wěn)定性運(yùn)行。

可觀測性數(shù)據(jù)暴露就是希望將這些黑盒的東西白盒化。通常我們會把可觀測性數(shù)據(jù)分為三類：Log，Traces，Metric。

1.2 IT系統(tǒng)可觀測性場景與應(yīng)用演進(jìn)

這三類數(shù)據(jù)的定義是比較寬泛的，并不局限于運(yùn)維領(lǐng)域。例如在線上運(yùn)營領(lǐng)域，通過在APP上增加埋點(diǎn)數(shù)據(jù)，可以觀測到用戶使用中的卡點(diǎn)問題，進(jìn)行針對性的用戶體驗(yàn)改進(jìn)；在線下運(yùn)營領(lǐng)域，通過在商場使用 WIFI 或者監(jiān)控設(shè)備來統(tǒng)計(jì)人流，可以解決新店選址或人流疏導(dǎo)難題。在交通領(lǐng)域，通過地圖數(shù)據(jù)或者車聯(lián)網(wǎng)數(shù)據(jù)，可以解決城市交通治理問題。

可以看到可觀測性數(shù)據(jù)的應(yīng)用價(jià)值和潛力非常巨大。我們回到大會的運(yùn)維主題，現(xiàn)在很多企業(yè)上云，第一件事就是把應(yīng)用部署到 K8s。下面我們簡單介紹一下 K8s 下業(yè)務(wù)部署特點(diǎn)及數(shù)據(jù)采集需求。

二、K8s下業(yè)務(wù)部署特點(diǎn)及數(shù)據(jù)采集需求

2.1 自動裝箱、彈性擴(kuò)縮容

K8s 具有自動裝箱和彈性擴(kuò)縮容的能力，部署應(yīng)用只需要進(jìn)行聲明即可實(shí)現(xiàn)編排，大大解放了研發(fā)人員部署的精力和時(shí)間。同時(shí)，也因?yàn)閼?yīng)用部署效率提高，使得應(yīng)用的版本迭代變得非常快，應(yīng)用的混布也會變得頻繁，單節(jié)點(diǎn)資源利用率大幅提高。為了幫助不同需求的應(yīng)用進(jìn)行不同形態(tài)的部署K8s提供了非常豐富的控制器并提供擴(kuò)展能力。有些控制器提供了水平拓展、滾動更新能力，都是非常常見且實(shí)用的，這些功能也會使得系統(tǒng)中的容器創(chuàng)建和消亡比較快。

2.2 資源抽象、混合使用

第二個(gè)是資源抽象，K8s使得不同軟件和硬件的節(jié)點(diǎn)都可以在一個(gè)集群中統(tǒng)一調(diào)度混合使用。為了更好地管理這些異構(gòu)資源，我們通常將相似的資源節(jié)點(diǎn)分配到同一個(gè)節(jié)點(diǎn)池里，比如說有的節(jié)點(diǎn)池是linux系統(tǒng)的主機(jī)，有些是windows系統(tǒng)的主機(jī)，有些是配備 GPU 的主機(jī)。將這些節(jié)點(diǎn)統(tǒng)一由一個(gè)K8s Master管理時(shí)，能使機(jī)器資源利用最大化。

而節(jié)點(diǎn)本身除了可以是物理主機(jī)外，也可以是虛擬節(jié)點(diǎn)。比如說阿里云的 ECI 服務(wù)，其實(shí)就是把一個(gè) pod 模擬成一個(gè) Virtual Kubelet，使得它也能當(dāng)做一個(gè)節(jié)點(diǎn)接受任務(wù)調(diào)度。當(dāng)資源向其調(diào)度的時(shí)候，它的容器實(shí)際跑在云上的 Serverless 資源上，而不是物理的節(jié)點(diǎn)上。這種資源抽象能力，使得應(yīng)用部署的靈活性大大提高。比如說混合云場景，有些客戶會在線下自建一個(gè)機(jī)房，將穩(wěn)定流量工作負(fù)載放在自建機(jī)房上，對于一些可能有流量突增的工作負(fù)載則放在具備彈性伸縮能力的云節(jié)點(diǎn)上。

2.3 存儲抽象、靈活編排

K8s 對存儲進(jìn)行了比較好的抽象，可以滿足應(yīng)用不同的數(shù)據(jù)持久化需求。同時(shí)這樣的抽象也使得容器再不用關(guān)心底層存儲的細(xì)節(jié)，如磁盤從哪里掛載，只需要聲明存儲的類型、容量和IO需求。這使得部署在 K8s 的應(yīng)用可以突破單機(jī)磁盤限制，一定程度上讓所有應(yīng)用都有了一定的存算分離能力。

三、K8s下可觀測數(shù)據(jù)采集的常見挑戰(zhàn)

K8s 給我們提供了一系列靈活和方便的部署能力的同時(shí)也給可觀測性的數(shù)據(jù)采集帶來一些挑戰(zhàn)。下面以這四點(diǎn)進(jìn)行講解：

3.1 采集部署運(yùn)維復(fù)雜

K8s 部署方便靈活，導(dǎo)致一個(gè)節(jié)點(diǎn)上的容器有可能非常多，我們怎么能夠部署一個(gè)采集端采集這么多異構(gòu)混布容器，怎么管理這么多采集對象。在 K8s 環(huán)境下容器部署變化非常快，比如說進(jìn)行動態(tài)擴(kuò)縮容的時(shí)候，很可能流量上來和下去的時(shí)候容器就很快創(chuàng)建和銷毀了；而節(jié)點(diǎn)資源不足的時(shí)候，容器的被驅(qū)逐現(xiàn)象也是非常常見的，這就使得容器的生命周期可能非常短暫，需要采集端快速發(fā)現(xiàn)容器，同時(shí)避免數(shù)據(jù)采集丟失。

3.2 容器和節(jié)點(diǎn)運(yùn)行環(huán)境多樣

隨著容器技術(shù)發(fā)展，容器運(yùn)行的環(huán)境越來越多樣化。以前都是用 Docker 進(jìn)行容器運(yùn)維，隨著 K8s 崛起，逐漸地 Docker 運(yùn)行時(shí)邊緣化，目前最新的版本都是默認(rèn)支持 Containerd 運(yùn)行時(shí)，同時(shí)還有 CRI-O 等新興的容器運(yùn)行時(shí)。這些運(yùn)行時(shí)的出現(xiàn)使采集節(jié)點(diǎn)上的容器數(shù)據(jù)不再只有一種格式，同時(shí)不同運(yùn)行時(shí)的通信機(jī)制也可能不同，對應(yīng)容器的內(nèi)容存放路徑也各不相同，這就使得采集器需要適配多樣的運(yùn)行時(shí)環(huán)境。

而容器運(yùn)行的節(jié)點(diǎn)環(huán)境，包括物理機(jī)、VM、虛擬節(jié)點(diǎn)。對于虛擬節(jié)點(diǎn)的部署模式和物理機(jī)是不同的，特別是容器元信息和數(shù)據(jù)保存周期和物理機(jī)不同，這些都需要采集端和節(jié)點(diǎn)具備合理的配合方案，避免數(shù)據(jù)采集不到。

3.3 單節(jié)點(diǎn)日志規(guī)模大

多種因素的作用下使得節(jié)點(diǎn)的日志規(guī)模變大。

• 混合部署，單機(jī)部署比較傾向于部署一個(gè)單體結(jié)構(gòu)應(yīng)用。但在 K8s上，一個(gè)節(jié)點(diǎn)部署 50 個(gè)以上實(shí)例也非常常見。
• 磁盤，傳統(tǒng)節(jié)點(diǎn)使用的是本機(jī)硬盤（HDD/SSD），即使是SSD IO吞吐極限也只有約 500MB/s；K8s 節(jié)點(diǎn)（特別是云上節(jié)點(diǎn)），可以利用云盤，最高規(guī)格速率可以達(dá)到 1 GB/s。
• 存儲擴(kuò)展能力，單機(jī)部署通常掛載 NAS，K8s 則支持多種存儲種類的掛載，使用 PVC 實(shí)現(xiàn)靈活擴(kuò)展，突破單機(jī)的讀寫速度和容量瓶頸。

在實(shí)際應(yīng)用中也遇見過單節(jié)點(diǎn)產(chǎn)生巨量日志的用戶，比如某打車APP，在一個(gè)節(jié)點(diǎn)上同時(shí)部署APP埋點(diǎn)定位數(shù)據(jù)/GPS定位數(shù)據(jù)/車輛實(shí)時(shí)后臺數(shù)據(jù)接收等等，使得單節(jié)點(diǎn)采集200M/s以上的日志。

3.4 可觀測數(shù)據(jù)異構(gòu)

K8s 節(jié)點(diǎn)本身就有多種媒介，例如有標(biāo)準(zhǔn)輸出、PVC日志、容器日志。

同時(shí)在 Log/Metric/Traces 上會分別有不同數(shù)據(jù)輸入源：在 Log 方面因?yàn)閼?yīng)用混部，同時(shí)要收集多種格式日志，像業(yè)務(wù)應(yīng)用、MySQL binlog、Nginx Access Log 等數(shù)據(jù)。在 Metric 方面，通常需要采集 Prometheus 指標(biāo)。在 Traces 方面，則又有 SkyWalking 等數(shù)據(jù)需要收集。如此復(fù)雜的采集需求使得單節(jié)點(diǎn)上采集的客戶端需要同時(shí)支持采集多種類型的可觀測數(shù)據(jù)才能達(dá)到使用要求。

這些情形都對端上采集構(gòu)成了新的挑戰(zhàn)。

四、對應(yīng)問題處理方案與實(shí)踐

我們從采集部署、環(huán)境、日志規(guī)模和異構(gòu)數(shù)據(jù)四方面來分享。

4.1 采集部署

部署模式

通常端上的采集器在 K8s 有兩種部署模式：一種是 DaemonSet，一種 Sidecar。DaemonSet 是在一個(gè)節(jié)點(diǎn)上部署一個(gè)采集器讓它來采集節(jié)點(diǎn)上所有容器的日志，Sidecar 模式是在業(yè)務(wù)容器中同時(shí)起一個(gè)并行的采集容器并通過共享存儲來采集業(yè)務(wù)容器的日志。

DaemonSet 模式有幾個(gè)明顯優(yōu)點(diǎn)：耦合性比較低，每個(gè)應(yīng)用不需要單獨(dú)為它修改部署，直接可以進(jìn)行采集；性價(jià)比高，只需要使用一份容器的資源就可以采到整個(gè)節(jié)點(diǎn)數(shù)據(jù)，和業(yè)務(wù)部署數(shù)量有解耦。

Sidecar 也有它的應(yīng)用場景，比如日志量特別大的容器，采集需要和其他進(jìn)行隔離，可以提供比較高的隔離性，同時(shí)它的靈活性也有一定好處。

配置分發(fā)

采集客戶端部署之后，如何管理這些采集對象？涉及到配置分發(fā)。比較簡單的做法是利用 K8s ConfigMap 分發(fā)配置，但它的缺點(diǎn)也比較明顯：

• ConfigMap 有大小限制
• 分發(fā)不靈活，每組采集器需要單獨(dú)配置

為了解決這些問題，可以用 ConfigServer 進(jìn)行中心化配置下發(fā)，有圖形界面支持，對運(yùn)維人員管控比較方便；在各個(gè) Agent 上有標(biāo)識，可以靈活實(shí)現(xiàn)分組；也不受 ConfigMap 大小限制，可以支持大量的配置，單節(jié)點(diǎn)最多能夠穩(wěn)定支持 1000 個(gè)配置。

這樣的部署方式已經(jīng)可以滿足大規(guī)模的應(yīng)用，但在某些場景下也有些不足：

比如用戶在 CI/CD 流水線里部署應(yīng)用的同時(shí)希望下發(fā)日志配置將日志采集上來，這時(shí)候用 ConfigServer 的 API 就需要定制一個(gè)組件來通信，不太方便。

配置自動化

我們也能夠通過 CRD 的方式進(jìn)行配置，這種方式能夠獲得 ConfigServer 的所有好處，同時(shí)能夠更好地在自動化流水線中集成采集配置的下發(fā)，直接使用 CRD 這一標(biāo)準(zhǔn) K8s資源對于這些流水線組件沒有額外的開發(fā)代價(jià)。

如圖所示，綠色的是 log-controller，它會實(shí)時(shí)監(jiān)聽采集的 CRD，CRD 是由 YAML 文件描述，如果 YAML 文件新增、刪除或變更，這些事件會觸發(fā) log-controller 將配置同步到 ConfigServer 上，在容器中部署的 iLogtail 則從 ConfigServer 拉取采集配置，這樣就實(shí)現(xiàn)了采集配置的聲明式部署。

這種方法在某些特殊場景下也不是完全適用，比如說配置特別多，而且 K8s 的 APIServer 存儲沒有改造，對 APIServer 壓力也是個(gè)需要考慮的。

Job場景支持

我們知道 K8s 場景下容器快速變化，比較典型的是 Job 控制器部署的容器。Job 的特點(diǎn)是跑完就結(jié)束了，所以增刪 Pod 的頻率很高。例如，有些 CI/CD 任務(wù)非常短，僅僅幾秒，就容易丟數(shù)據(jù)。還例如，在無人車模擬場景里，會同時(shí)起幾千個(gè) Pod，瞬時(shí)新增容器并發(fā)量極大，這都是我們在采集時(shí)要考慮的因素。

實(shí)踐中得出以下經(jīng)驗(yàn)：

1. 需要盡快發(fā)現(xiàn)容器，鎖定文件句柄。
2. 需要召回探測間隔期間退出的容器，有些容器可能因出錯(cuò)在探測間隔期間剛創(chuàng)建就退出了，這時(shí)候在下一次探測時(shí)我們不能忽略掉已經(jīng)退出的容器，需要對退出容器也進(jìn)行采集，保證數(shù)據(jù)完整。
3. 對于一些關(guān)鍵日志，需要打在標(biāo)準(zhǔn)輸出中。因?yàn)闊o論如何，容器銷毀之后，容器內(nèi)的文件都是無法訪問的，但是標(biāo)準(zhǔn)輸出不太一樣，標(biāo)準(zhǔn)輸出由 Kubelet 單獨(dú)管理的，有保存的策略，通常不會立刻被刪除，這樣可以保證在容器快速變化的場景下數(shù)據(jù)不會丟失。

4.2 運(yùn)行環(huán)境

容器運(yùn)行時(shí)

接下來談一下運(yùn)行環(huán)境適配的問題，首先我們看一下常見的開源 Agent 對于不同部署模式下的采集支持情況。DaemonSet 下容器內(nèi)文件采集只有 iLogtail 是支持的，iLogtail 是如何做到這一點(diǎn)的？

我們看右邊的圖，iLogtail 發(fā)現(xiàn)容器的方式和其他開源軟件不太一樣，不是通過 API Server，它是直接和本地的容器運(yùn)行時(shí)通信來獲得容器的運(yùn)行元信息。這些信息里會有 Overlay 的信息，這就是容器存放容器內(nèi)文件的數(shù)據(jù)位置信息，還有 Mount point和對應(yīng)掛載的路徑，我們通過這些信息，通過 DaemonSet 可以直接采集到這些數(shù)據(jù)，不需要如共享卷的方式來采集數(shù)據(jù)。

但是為了實(shí)現(xiàn)這一點(diǎn)，需要對各種運(yùn)行時(shí)進(jìn)行適配。比如說 Docker 和 Containerd，它們通信的方式就不一樣，我們要自動檢測，它們的標(biāo)準(zhǔn)輸出格式也不一樣，它們對容器內(nèi)文件存放的位置也不一樣，這些都需要進(jìn)行特定的適配。我們適配之后，用戶用起來就會比較簡單，只需要通過配置容器上的路徑就能采集，不需要其他的額外工作。

Serverless 支持

剛才談到過容器的運(yùn)行節(jié)點(diǎn)環(huán)境比較多樣，其中 Serverless 這種場景怎么支持？Serverless 沒有物理節(jié)點(diǎn)，無法部署 DaemonSet，而 Sidecar 采集不了標(biāo)準(zhǔn)輸出，都不是完美解決方案。更為復(fù)雜的情況是通過 Virtual Kubelet 實(shí)現(xiàn) HPA 的場景，一部分容器已經(jīng)運(yùn)行在實(shí)體節(jié)點(diǎn)上并使用 DaemonSet 在采集日志，但一旦發(fā)生彈性擴(kuò)縮容，容器創(chuàng)建到虛擬節(jié)點(diǎn)上，沒有 DaemonSet 容器，但日志還要采集上來，怎么辦？

來看一下我們是怎么做的。Virtual Kubelet 虛擬節(jié)點(diǎn)收到新建容器請求，會通過 ECI 創(chuàng)建一個(gè)容器，在 ECI 中同時(shí)運(yùn)行業(yè)務(wù)容器和 iLogtail 容器。iLogtail 容器用戶不感知，這種模式稱為 hidecar 模式。

ECI 中業(yè)務(wù)容器的信息，包括 Mount Point 和容器內(nèi)文件在主機(jī)上的位置等，都通過靜態(tài)文件發(fā)給 iLogtail，這種情況下 iLogtail 的工作模式和 DaemonSet 時(shí)非常像，它會通過靜態(tài)文件發(fā)現(xiàn)容器，同時(shí)通過掛載在 iLogtail 容器中的 ECI 根目錄去采集 ECI 節(jié)點(diǎn)上的業(yè)務(wù)容器日志。

通過這種方式，我們就可以比較平滑地讓用戶在沒有感知情況下只考慮使用 DaemonSet 也能采集 ECI Serverless 的容器日志。為了避免丟失數(shù)據(jù)，ECI 會保證 iLogtail 收到退出信號晚于業(yè)務(wù)容器。

4.3 單節(jié)點(diǎn)日志規(guī)模大

單個(gè)采集端

首先，iLogtail 的采集性能在各個(gè)開源采集器里是比較領(lǐng)先的，極簡模式下可以達(dá)到440MB/s，然而默認(rèn)部署通常會限制 iLogtail 資源，可能達(dá)不到極限速度，這時(shí)候如果產(chǎn)生日志延時(shí)，可以從幾個(gè)方面判斷：

• 客戶端。可以增加資源并且調(diào)大 iLogtail 并行處理和發(fā)送的參數(shù)。
• 服務(wù)端。日志服務(wù)具備自動擴(kuò)容能力，但對于一些特殊場景，如日志積壓，自動擴(kuò)容可能有一些延遲，這時(shí)候需要手動調(diào)整。
• 網(wǎng)絡(luò)鏈路。發(fā)送端和接受端帶寬是否足夠；中間存在代理則要檢查 VIP、SLB 是否達(dá)到上限。如果涉及跨境傳輸，可能需要改進(jìn)鏈路，比如啟用全球加速或使用企業(yè)云網(wǎng)。

多個(gè)采集端

如果做了上面優(yōu)化，仍然有客戶端瓶頸導(dǎo)致的日志延時(shí)怎么辦？可以用借用 Sidecar 部署思路（在一個(gè)節(jié)點(diǎn)上運(yùn)行多個(gè)采集容器），把吞吐量較大的日志拆分出去，部署到多個(gè)容器，這樣單節(jié)點(diǎn)采集能力不受到一個(gè) DaemonSet 采集器上限限制。

4.4 異構(gòu)數(shù)據(jù)的支持

插件框架

iLogtail 誕生之初主要是為了采集文件日志，隨著整個(gè)服務(wù)上云，云上開放生態(tài)建設(shè)越來越多，需要接入的數(shù)據(jù)也越來越多。iLogtail 除了寫入 SLS，也要支持寫入第三方日志庫。

為了應(yīng)對大量輸入輸出需求，我們?yōu)?iLogtail 做了插件化的框架方便擴(kuò)展，C++部分主要是處理文件、接受采集配置、發(fā)送數(shù)據(jù)等核心功能，插件負(fù)責(zé)接入一些別的輸入源，例如 Binlog、Syslog 都是通過插件實(shí)現(xiàn)的；同時(shí)對接第三方數(shù)據(jù)源也是通過插件輸入，在改造過程中也是把一些 iLogtail 處理能力進(jìn)行了插件化，使得處理不局限于 Parse 一種，而是可以利用多個(gè)處理插件在端上進(jìn)行靈活組合，實(shí)現(xiàn)端上輕量級處理流水線。

iLogtail可觀測性數(shù)據(jù)生態(tài)支持

目前 iLogtail 的生態(tài)在 Log 方面，一直是 iLogtail 的強(qiáng)項(xiàng)，除了支持容器數(shù)據(jù)采集外，還增加了 Windows Event、eBPF 等一些數(shù)據(jù)源。在 Metric 方面，有 Telegraf、Prometheus 數(shù)據(jù)源，OpenTelemetry 數(shù)據(jù)格式接入也在進(jìn)行中。Trace 方面主要接入 Skywalking 的數(shù)據(jù)。輸出方面除了支持阿里云的 SLS，也支持了 Kafka 的寫入，并且支持格式轉(zhuǎn)換可以被 CK、ES 等直接消費(fèi)。對 CK 和 ES 的直接寫入支持，目前也在規(guī)劃中。

基于 eBPF 的無侵入采集

下面介紹 eBPF 的接入和可觀測性采集辦法。對于端上的 Trace 和 Metric 數(shù)據(jù)接入，通常來說需要用 SDK 在應(yīng)用中進(jìn)行埋點(diǎn)。雖然也有無埋點(diǎn)數(shù)據(jù)采集，如使用 Java Agent，但受限于特定語言。有沒有辦法將無侵入采集推廣到其他語言？eBPF 技術(shù)提供了這樣的可能性。

在 ilogtail 的實(shí)現(xiàn)中 eBPF 的采集原理分為用戶態(tài)和內(nèi)核態(tài)。內(nèi)核態(tài)主要是通過 Kprobe 模塊用一定規(guī)則去抓取系統(tǒng)調(diào)用的數(shù)據(jù)，對它進(jìn)行解包并關(guān)聯(lián)下發(fā)配置、進(jìn)行過濾，把過濾后的解析數(shù)據(jù)發(fā)送到用戶態(tài)。

用戶態(tài)拿到的數(shù)據(jù)通常只有一些id信息，并不完整，ilogtail 使用一些插件來采集端上的 Process、容器等元信息，將這些信息與內(nèi)核態(tài)采集的數(shù)據(jù)進(jìn)行關(guān)聯(lián)/聚合，得到完整的數(shù)據(jù)后再發(fā)送到后端。

端上的情況大概是這樣，完整的構(gòu)建采集方案還需要結(jié)合服務(wù)端整體的能力。除了采集數(shù)據(jù) DaemonSet 的 iLogtail，完整的方案還需要部署 Deployment 的 iLogtail 來拿到更詳細(xì)的集群和容器信息，有了這個(gè)數(shù)據(jù)已經(jīng)可以構(gòu)建完整的主機(jī)監(jiān)控。進(jìn)一步我們可以從云上拿到云資產(chǎn)信息，再進(jìn)行一次 join 以得到更加完整的 K8s 鏈路拓?fù)洹?/span>

對于這些數(shù)據(jù)，可以對它進(jìn)行聚合和處理從而得到一些指標(biāo)數(shù)據(jù)，可以用來制作儀表盤實(shí)現(xiàn)圖形化展示。如果結(jié)合黃金指標(biāo)或者應(yīng)用 SLS 智能巡檢服務(wù)，則可以得到告警事件。如果對這些事件進(jìn)行處理，我們就能得到完整的運(yùn)維閉環(huán)。

五、開源與未來展望

iLogtail 現(xiàn)在已經(jīng)開源，大家可以共同參與討論和開發(fā)，后續(xù)計(jì)劃會分成四塊共建：

• 生態(tài)拓展：Kafka Flusher 已經(jīng)支持到2.0，OTLP有1.0的初步支持，ClickHouse Flusher 和 GRPC Input/Output 都在規(guī)劃中。
• 框架增強(qiáng)：iLogtail 從日志發(fā)展過來，整個(gè)數(shù)據(jù)模型偏向于日志，對時(shí)序數(shù)據(jù)或 Trace 數(shù)據(jù)，都是通過私有協(xié)議和日志服務(wù)的 SLS 綁定。對于開源來說，更希望是開放的，有更好的架構(gòu)支持。
• eBPF：對于四層協(xié)議做了比較完整的解析，可以進(jìn)行流量觀察。對于七層協(xié)議，支持 Http/Redis/數(shù)據(jù)庫類型協(xié)議，對于常見的 RPC 框架，有待社區(qū)共建。
• 全局管控：配置方案的管控能力，日志服務(wù)有商業(yè)版的支持，我們也希望把這個(gè)能力帶到開源上來。目前管控協(xié)議和管控服務(wù)已經(jīng)有個(gè)初步的版本，后續(xù)希望把前端構(gòu)建好，并且把如 K8s Operator 能力/iLogtail自身的可觀測性數(shù)據(jù)也都能集成進(jìn)來。

Github：https://github.com/alibaba/ilogtail