建站
咨詢
售后
建站咨詢
新聞中心
本文根據(jù)余韜老師在 GOPS 2022·上海站演講整理而成，更多精彩，請(qǐng)關(guān)注高效運(yùn)維公眾號(hào)。
公司主營業(yè)務(wù)：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出彭澤免費(fèi)做網(wǎng)站回饋大家。
作者簡介：
余韜，阿里巴巴技術(shù)專家。
10年工作經(jīng)驗(yàn)，目前就職于阿里巴巴日志服務(wù)可觀測平臺(tái)團(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)相對(duì)簡單，開發(fā)工作僅由幾個(gè)人就能完成，每個(gè)人都對(duì)整個(gè)系統(tǒng)有完整了解。隨著業(yè)務(wù)越來越復(fù)雜，涉及到的模塊越來越多，很難有一個(gè)人了解系統(tǒng)全貌，此時(shí)就需要通過將它的可觀測性數(shù)據(jù)展示出來以定位問題。
隨著軟件的復(fù)雜性增加，跨團(tuán)隊(duì)合作也會(huì)越來越多，團(tuán)隊(duì)間的溝通或排障也需要提高效率，防止推諉，因此需要拿數(shù)據(jù)說話，對(duì)可觀測性數(shù)據(jù)的需求也越來越突出。軟件運(yùn)行環(huán)境也隨著系統(tǒng)的基礎(chǔ)組件云化趨勢，變得越來越復(fù)雜。從單機(jī)到容器化，再到現(xiàn)在的云原生。越來越多的組件依賴第三方或者云上的云原生接口，使這個(gè)系統(tǒng)越來越像一個(gè)黑盒，不利于穩(wěn)定性運(yùn)行。
可觀測性數(shù)據(jù)暴露就是希望將這些黑盒的東西白盒化。通常我們會(huì)把可觀測性數(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)行針對(duì)性的用戶體驗(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à)值和潛力非常巨大。我們回到大會(huì)的運(yùn)維主題，現(xiàn)在很多企業(yè)上云，第一件事就是把應(yīng)用部署到 K8s。下面我們簡單介紹一下 K8s 下業(yè)務(wù)部署特點(diǎn)及數(shù)據(jù)采集需求。
二、K8s下業(yè)務(wù)部署特點(diǎn)及數(shù)據(jù)采集需求
2.1 自動(dòng)裝箱、彈性擴(kuò)縮容
K8s 具有自動(dòng)裝箱和彈性擴(kuò)縮容的能力，部署應(yīng)用只需要進(jìn)行聲明即可實(shí)現(xiàn)編排，大大解放了研發(fā)人員部署的精力和時(shí)間。同時(shí)，也因?yàn)閼?yīng)用部署效率提高，使得應(yīng)用的版本迭代變得非?？欤瑧?yīng)用的混布也會(huì)變得頻繁，單節(jié)點(diǎn)資源利用率大幅提高。為了幫助不同需求的應(yīng)用進(jìn)行不同形態(tài)的部署K8s提供了非常豐富的控制器并提供擴(kuò)展能力。有些控制器提供了水平拓展、滾動(dòng)更新能力，都是非常常見且實(shí)用的，這些功能也會(huì)使得系統(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)用部署的靈活性大大提高。比如說混合云場景，有些客戶會(huì)在線下自建一個(gè)機(jī)房，將穩(wěn)定流量工作負(fù)載放在自建機(jī)房上，對(duì)于一些可能有流量突增的工作負(fù)載則放在具備彈性伸縮能力的云節(jié)點(diǎn)上。
2.3 存儲(chǔ)抽象、靈活編排
K8s 對(duì)存儲(chǔ)進(jìn)行了比較好的抽象，可以滿足應(yīng)用不同的數(shù)據(jù)持久化需求。同時(shí)這樣的抽象也使得容器再不用關(guān)心底層存儲(chǔ)的細(xì)節(jié)，如磁盤從哪里掛載，只需要聲明存儲(chǔ)的類型、容量和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)混布容器，怎么管理這么多采集對(duì)象。在 K8s 環(huán)境下容器部署變化非?？?，比如說進(jìn)行動(dòng)態(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ī)制也可能不同，對(duì)應(yīng)容器的內(nèi)容存放路徑也各不相同，這就使得采集器需要適配多樣的運(yùn)行時(shí)環(huán)境。
而容器運(yùn)行的節(jié)點(diǎn)環(huán)境，包括物理機(jī)、VM、虛擬節(jié)點(diǎn)。對(duì)于虛擬節(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。
- 存儲(chǔ)擴(kuò)展能力，單機(jī)部署通常掛載 NAS，K8s 則支持多種存儲(chǔ)種類的掛載，使用 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í)后臺(tái)數(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 上會(huì)分別有不同數(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á)到使用要求。
這些情形都對(duì)端上采集構(gòu)成了新的挑戰(zhàn)。
四、對(duì)應(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è)并行的采集容器并通過共享存儲(chǔ)來采集業(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ā)
采集客戶端部署之后，如何管理這些采集對(duì)象？涉及到配置分發(fā)。比較簡單的做法是利用 K8s ConfigMap 分發(fā)配置，但它的缺點(diǎn)也比較明顯：
- ConfigMap 有大小限制
- 分發(fā)不靈活，每組采集器需要單獨(dú)配置
為了解決這些問題，可以用 ConfigServer 進(jìn)行中心化配置下發(fā)，有圖形界面支持，對(duì)運(yùn)維人員管控比較方便；在各個(gè) Agent 上有標(biāo)識(shí)，可以靈活實(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è)組件來通信，不太方便。
配置自動(dòng)化
我們也能夠通過 CRD 的方式進(jìn)行配置，這種方式能夠獲得 ConfigServer 的所有好處，同時(shí)能夠更好地在自動(dòng)化流水線中集成采集配置的下發(fā)，直接使用 CRD 這一標(biāo)準(zhǔn) K8s資源對(duì)于這些流水線組件沒有額外的開發(fā)代價(jià)。
如圖所示，綠色的是log-controller，它會(huì)實(shí)時(shí)監(jiān)聽采集的 CRD，CRD 是由 YAML 文件描述，如果 YAML 文件新增、刪除或變更，這些事件會(huì)觸發(fā) log-controller 將配置同步到 ConfigServer 上，在容器中部署的 iLogtail 則從 ConfigServer 拉取采集配置，這樣就實(shí)現(xiàn)了采集配置的聲明式部署。
這種方法在某些特殊場景下也不是完全適用，比如說配置特別多，而且 K8s 的 APIServer 存儲(chǔ)沒有改造，對(duì) APIServer 壓力也是個(gè)需要考慮的。
Job場景支持
我們知道 K8s 場景下容器快速變化，比較典型的是 Job 控制器部署的容器。Job 的特點(diǎn)是跑完就結(jié)束了，所以增刪 Pod 的頻率很高。例如，有些 CI/CD 任務(wù)非常短，僅僅幾秒，就容易丟數(shù)據(jù)。還例如，在無人車模擬場景里，會(huì)同時(shí)起幾千個(gè) Pod，瞬時(shí)新增容器并發(fā)量極大，這都是我們在采集時(shí)要考慮的因素。
實(shí)踐中得出以下經(jīng)驗(yàn)：
- 需要盡快發(fā)現(xiàn)容器，鎖定文件句柄。
- 需要召回探測間隔期間退出的容器，有些容器可能因出錯(cuò)在探測間隔期間剛創(chuàng)建就退出了，這時(shí)候在下一次探測時(shí)我們不能忽略掉已經(jīng)退出的容器，需要對(duì)退出容器也進(jìn)行采集，保證數(shù)據(jù)完整。
- 對(duì)于一些關(guān)鍵日志，需要打在標(biāo)準(zhǔn)輸出中。因?yàn)闊o論如何，容器銷毀之后，容器內(nèi)的文件都是無法訪問的，但是標(biāo)準(zhǔn)輸出不太一樣，標(biāo)準(zhǔn)輸出由 Kubelet 單獨(dú)管理的，有保存的策略，通常不會(huì)立刻被刪除，這樣可以保證在容器快速變化的場景下數(shù)據(jù)不會(huì)丟失。
4.2 運(yùn)行環(huán)境
容器運(yùn)行時(shí)
接下來談一下運(yùn)行環(huán)境適配的問題，首先我們看一下常見的開源 Agent 對(duì)于不同部署模式下的采集支持情況。DaemonSet 下容器內(nèi)文件采集只有 iLogtail 是支持的，iLogtail 是如何做到這一點(diǎn)的？
我們看右邊的圖，iLogtail 發(fā)現(xiàn)容器的方式和其他開源軟件不太一樣，不是通過 API Server，它是直接和本地的容器運(yùn)行時(shí)通信來獲得容器的運(yùn)行元信息。這些信息里會(huì)有 Overlay 的信息，這就是容器存放容器內(nèi)文件的數(shù)據(jù)位置信息，還有 Mount point和對(duì)應(yīng)掛載的路徑，我們通過這些信息，通過 DaemonSet 可以直接采集到這些數(shù)據(jù)，不需要如共享卷的方式來采集數(shù)據(jù)。
但是為了實(shí)現(xiàn)這一點(diǎn)，需要對(duì)各種運(yùn)行時(shí)進(jìn)行適配。比如說 Docker 和 Containerd，它們通信的方式就不一樣，我們要自動(dòng)檢測，它們的標(biāo)準(zhǔn)輸出格式也不一樣，它們對(duì)容器內(nèi)文件存放的位置也不一樣，這些都需要進(jìn)行特定的適配。我們適配之后，用戶用起來就會(huì)比較簡單，只需要通過配置容器上的路徑就能采集，不需要其他的額外工作。
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)收到新建容器請(qǐng)求，會(huì)通過 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í)非常像，它會(huì)通過靜態(tài)文件發(fā)現(xiàn)容器，同時(shí)通過掛載在 iLogtail 容器中的 ECI 根目錄去采集 ECI 節(jié)點(diǎn)上的業(yè)務(wù)容器日志。
通過這種方式，我們就可以比較平滑地讓用戶在沒有感知情況下只考慮使用 DaemonSet 也能采集 ECI Serverless 的容器日志。為了避免丟失數(shù)據(jù)，ECI 會(huì)保證 iLogtail 收到退出信號(hào)晚于業(yè)務(wù)容器。
4.3 單節(jié)點(diǎn)日志規(guī)模大
單個(gè)采集端
首先，iLogtail 的采集性能在各個(gè)開源采集器里是比較領(lǐng)先的，極簡模式下可以達(dá)到440MB/s，然而默認(rèn)部署通常會(huì)限制 iLogtail 資源，可能達(dá)不到極限速度，這時(shí)候如果產(chǎn)生日志延時(shí)，可以從幾個(gè)方面判斷：
- 客戶端?？梢栽黾淤Y源并且調(diào)大 iLogtail 并行處理和發(fā)送的參數(shù)。
- 服務(wù)端。日志服務(wù)具備自動(dòng)擴(kuò)容能力，但對(duì)于一些特殊場景，如日志積壓，自動(dòng)擴(kuò)容可能有一些延遲，這時(shí)候需要手動(dòng)調(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)對(duì)大量輸入輸出需求，我們?yōu)?iLogtail 做了插件化的框架方便擴(kuò)展，C++部分主要是處理文件、接受采集配置、發(fā)送數(shù)據(jù)等核心功能，插件負(fù)責(zé)接入一些別的輸入源，例如 Binlog、Syslog 都是通過插件實(shí)現(xiàn)的；同時(shí)對(duì)接第三方數(shù)據(jù)源也是通過插件輸入，在改造過程中也是把一些 iLogtail 處理能力進(jìn)行了插件化，使得處理不局限于 Parse 一種，而是可以利用多個(gè)處理插件在端上進(jìn)行靈活組合，實(shí)現(xiàn)端上輕量級(jí)處理流水線。
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)。對(duì) CK 和 ES 的直接寫入支持，目前也在規(guī)劃中。
基于 eBPF 的無侵入采集
下面介紹 eBPF 的接入和可觀測性采集辦法。對(duì)于端上的 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ù)，對(duì)它進(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ù)洹?/p>
對(duì)于這些數(shù)據(jù)，可以對(duì)它進(jìn)行聚合和處理從而得到一些指標(biāo)數(shù)據(jù)，可以用來制作儀表盤實(shí)現(xiàn)圖形化展示。如果結(jié)合黃金指標(biāo)或者應(yīng)用 SLS 智能巡檢服務(wù)，則可以得到告警事件。如果對(duì)這些事件進(jìn)行處理，我們就能得到完整的運(yùn)維閉環(huán)。
五、開源與未來展望
iLogtail 現(xiàn)在已經(jīng)開源，大家可以共同參與討論和開發(fā)，后續(xù)計(jì)劃會(huì)分成四塊共建：
- 生態(tài)拓展：Kafka Flusher 已經(jīng)支持到2.0，OTLP有1.0的初步支持，ClickHouse Flusher 和 GRPC Input/Output 都在規(guī)劃中。
- 框架增強(qiáng)：iLogtail 從日志發(fā)展過來，整個(gè)數(shù)據(jù)模型偏向于日志，對(duì)時(shí)序數(shù)據(jù)或 Trace 數(shù)據(jù)，都是通過私有協(xié)議和日志服務(wù)的 SLS 綁定。對(duì)于開源來說，更希望是開放的，有更好的架構(gòu)支持。
- eBPF：對(duì)于四層協(xié)議做了比較完整的解析，可以進(jìn)行流量觀察。對(duì)于七層協(xié)議，支持 Http/Redis/數(shù)據(jù)庫類型協(xié)議，對(duì)于常見的 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
分享名稱：創(chuàng)新互聯(lián)下的可觀測數(shù)據(jù)采集實(shí)踐，看這一篇就夠了！
網(wǎng)頁URL：http://fisionsoft.com.cn/article/cdsgecg.html
