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

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

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

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

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

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

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

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

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

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

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

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

2.1 自動裝箱、彈性擴縮容

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

2.2 資源抽象、混合使用

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

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

2.3 存儲抽象、靈活編排

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

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

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

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

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

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

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

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

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

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

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

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

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

K8s 節(jié)點本身就有多種媒介，例如有標準輸出、PVC日志、容器日志。

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

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

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

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

4.1 采集部署

部署模式

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

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

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

配置分發(fā)

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

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

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

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

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

配置自動化

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

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

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

Job場景支持

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

實踐中得出以下經(jīng)驗：

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

4.2 運行環(huán)境

容器運行時

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

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

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

Serverless 支持

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

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

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

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

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

單個采集端

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

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

多個采集端

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

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

插件框架

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

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

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

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

基于 eBPF 的無侵入采集

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

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

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

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

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

五、開源與未來展望

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

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

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