[[439615]]

11月23日，阿里正式開(kāi)源可觀(guān)測(cè)數(shù)據(jù)采集器iLogtail。作為阿里內(nèi)部可觀(guān)測(cè)數(shù)據(jù)采集的基礎(chǔ)設(shè)施，iLogtail承載了阿里巴巴集團(tuán)、螞蟻的日志、監(jiān)控、Trace、事件等多種可觀(guān)測(cè)數(shù)據(jù)的采集工作。iLogtail運(yùn)行在服務(wù)器、容器、K8s、嵌入式等多種環(huán)境，支持采集數(shù)百種可觀(guān)測(cè)數(shù)據(jù)，目前已經(jīng)有千萬(wàn)級(jí)的安裝量，每天采集數(shù)十PB的可觀(guān)測(cè)數(shù)據(jù)，廣泛應(yīng)用于線(xiàn)上監(jiān)控、問(wèn)題分析/定位、運(yùn)營(yíng)分析、安全分析等多種場(chǎng)景。

一. iLogtail與可觀(guān)測(cè)性

可觀(guān)測(cè)性并不是一個(gè)全新的概念，而是從IT系統(tǒng)中的監(jiān)控、問(wèn)題排查、穩(wěn)定性建設(shè)、運(yùn)營(yíng)分析、BI、安全分析等逐漸演化而來(lái)，可觀(guān)測(cè)性相比傳統(tǒng)監(jiān)控，最核心的演進(jìn)是盡可能多的收集各類(lèi)可觀(guān)測(cè)數(shù)據(jù)，來(lái)實(shí)現(xiàn)目標(biāo)的白盒化。而iLogtail的核心定位就是可觀(guān)測(cè)數(shù)據(jù)的采集器，能夠盡可能多的采集各類(lèi)可觀(guān)測(cè)性數(shù)據(jù)，助力可觀(guān)測(cè)平臺(tái)打造各種上層的應(yīng)用場(chǎng)景。

二. 阿里可觀(guān)測(cè)數(shù)據(jù)采集的挑戰(zhàn)

對(duì)于可觀(guān)測(cè)數(shù)據(jù)的采集，有很多開(kāi)源的Agent，例如Logstash、Filebeats、Fluentd、Collectd、Telegraf等。這些Agent的功能非常豐富，使用這些Agent的組合再進(jìn)行一定的擴(kuò)展，基本可以滿(mǎn)足內(nèi)部各類(lèi)數(shù)據(jù)的采集需求。但由于一些性能、穩(wěn)定性、管控能力等關(guān)鍵性的挑戰(zhàn)無(wú)法滿(mǎn)足，最終我們還是選擇自研：

1、資源消耗：目前阿里內(nèi)部有數(shù)百萬(wàn)的主機(jī)(物理機(jī)/虛擬機(jī)/容器)，每天會(huì)產(chǎn)生幾十PB的可觀(guān)測(cè)數(shù)據(jù)，每1M的內(nèi)存減少、每1M/s的性能提升對(duì)于我們的資源節(jié)省都是巨大的，帶來(lái)的成本節(jié)約可能是數(shù)百萬(wàn)甚至上千萬(wàn)。目前眾多開(kāi)源Agent的設(shè)計(jì)更多的是偏重功能而非性能，基于現(xiàn)有開(kāi)源Agent改造基本不可行。例如：

• 開(kāi)源Agent普遍單核處理性能在2-10M/s左右，而我們希望有一個(gè)能達(dá)到100M/s的性能
• 在采集目標(biāo)增加、數(shù)據(jù)量增加、采集延遲、服務(wù)端異常等情況下，開(kāi)源Agent內(nèi)存都會(huì)呈現(xiàn)爆炸式增長(zhǎng)，而我們希望即使在各種環(huán)境下，內(nèi)存也能處在較低的水位
• 開(kāi)源Agent的資源消耗沒(méi)辦法控制，只能通過(guò)cgroup強(qiáng)行限制，最終的效果就是不斷OOM，不斷重啟，數(shù)據(jù)一直采集不上來(lái)。而我們希望在指定一個(gè)CPU、內(nèi)存、流量等資源限制后，Agent能一直在這個(gè)限制范圍內(nèi)正常工作

2、穩(wěn)定性：穩(wěn)定性是永恒的話(huà)題，數(shù)據(jù)采集的穩(wěn)定性，除了保證數(shù)據(jù)本身采集的準(zhǔn)確性外，還需要保證采集的Agent不能影響業(yè)務(wù)應(yīng)用，否則帶來(lái)的影響將是災(zāi)難性的。而穩(wěn)定性建設(shè)，除了Agent自身的基礎(chǔ)穩(wěn)定性外，還有很多特性目前開(kāi)源的Agent還沒(méi)有提供：

• Agent自恢復(fù)：Agent遇到Critical的事件后能夠自動(dòng)恢復(fù)，并且提供多個(gè)維度的自恢復(fù)能力，例如進(jìn)程自身、父子進(jìn)程、守護(hù)進(jìn)程
• 全局的多維度監(jiān)控：能夠從全局的角度監(jiān)控各個(gè)不同版本、不同采集配置、不同壓力、不同地域/網(wǎng)絡(luò)等屬性的Agent的穩(wěn)定性問(wèn)題
• 問(wèn)題隔離：作為Agent，無(wú)論怎樣出現(xiàn)問(wèn)題，都需要盡可能的隔離問(wèn)題，例如一個(gè)Agent上有多個(gè)采集配置，一個(gè)配置出問(wèn)題，不能影響其他配置;Agent自身出現(xiàn)問(wèn)題，不能影響機(jī)器上的應(yīng)用進(jìn)程的穩(wěn)定性
• 回滾能力：版本更新和發(fā)布是再所難免的問(wèn)題，在出現(xiàn)問(wèn)題的時(shí)候如何快速回滾，而且保證出問(wèn)題和回滾期間的數(shù)據(jù)采集還是at least once甚至是exactly once。

3、可管控：可觀(guān)測(cè)數(shù)據(jù)的應(yīng)用范圍非常的廣，幾乎所有的業(yè)務(wù)、運(yùn)維、BI、安全等部門(mén)都會(huì)要用，而一臺(tái)機(jī)器上也會(huì)產(chǎn)生各種數(shù)據(jù)，同一臺(tái)機(jī)器產(chǎn)生的數(shù)據(jù)上也會(huì)有多個(gè)部門(mén)的人要去使用，例如在2018年我們統(tǒng)計(jì)，平均一臺(tái)虛擬機(jī)上有100多個(gè)不同類(lèi)型的數(shù)據(jù)需要采集，設(shè)計(jì)10多個(gè)不同部門(mén)的人要去使用這些數(shù)據(jù)。除了這些之外，還會(huì)有其他很多企業(yè)級(jí)的特性需要支持，例如：

• 配置的遠(yuǎn)程管理：在大規(guī)模場(chǎng)景下，手工登錄機(jī)器修改配置基本沒(méi)有可行性，因此需要一套配置的圖形化管理、遠(yuǎn)程存儲(chǔ)、自動(dòng)下發(fā)的機(jī)制，而且還要能夠區(qū)分不同的應(yīng)用、不同的Region、不同的歸屬方等信息。同時(shí)因?yàn)樯婕暗竭h(yuǎn)程配置的動(dòng)態(tài)加卸載，Agent還需要能夠保證配置Reload期間數(shù)據(jù)不丟不重
• 采集配置優(yōu)先級(jí)：當(dāng)一臺(tái)機(jī)器上有多個(gè)采集配置在運(yùn)行時(shí)，如果遇到資源不足的情況，需要區(qū)分每個(gè)不同的配置優(yōu)先級(jí)，資源優(yōu)先供給高優(yōu)先級(jí)的配置，同時(shí)還要確保低優(yōu)先級(jí)的配置不被“餓死”
• 降級(jí)與恢復(fù)能力：在阿里，大促、秒殺是家常便飯，在這種波峰期間，可能有很多不重要的應(yīng)用被降級(jí)，同樣對(duì)應(yīng)應(yīng)用的數(shù)據(jù)也需要降級(jí)，降級(jí)后，在凌晨波峰過(guò)后，還需要有足夠的Burst能力快速追齊數(shù)據(jù)
• 數(shù)據(jù)采集齊全度：監(jiān)控、數(shù)據(jù)分析等場(chǎng)景都要求數(shù)據(jù)準(zhǔn)確度，數(shù)據(jù)準(zhǔn)確的前提是都能及時(shí)采集到服務(wù)端，但如何在計(jì)算前確定每臺(tái)機(jī)器、每個(gè)文件的數(shù)據(jù)都采集到了對(duì)應(yīng)的時(shí)間點(diǎn)，需要一套非常復(fù)雜的機(jī)制去計(jì)算

基于以上的背景和挑戰(zhàn)下，我們從2013年開(kāi)始，不斷逐漸優(yōu)化和改進(jìn)iLogtail來(lái)解決性能、穩(wěn)定性、可管控等問(wèn)題，并經(jīng)歷了阿里多次雙十一、雙十二、春晚紅包等項(xiàng)目的考驗(yàn)。目前iLogtail支持包括Logs、Traces、Metrics多種類(lèi)型數(shù)據(jù)的統(tǒng)一收集，核心的特點(diǎn)主要如下：

• 支持多種Logs、Traces、Metrics數(shù)據(jù)采集，尤其對(duì)容器、Kubernetes環(huán)境支持非常友好
• 數(shù)據(jù)采集資源消耗極低，單核采集能力100M/s，相比同類(lèi)可觀(guān)測(cè)數(shù)據(jù)采集的Agent性能好5-20倍
• 高穩(wěn)定性，在阿里巴巴以及數(shù)萬(wàn)阿里云客戶(hù)生產(chǎn)中使用驗(yàn)證，部署量近千萬(wàn)，每天采集數(shù)十PB可觀(guān)測(cè)數(shù)據(jù)
• 支持插件化擴(kuò)展，可任意擴(kuò)充數(shù)據(jù)采集、處理、聚合、發(fā)送模塊
• 支持配置遠(yuǎn)程管理，支持以圖形化、SDK、K8s Operator等方式進(jìn)行配置管理，可輕松管理百萬(wàn)臺(tái)機(jī)器的數(shù)據(jù)采集
• 支持自監(jiān)控、流量控制、資源控制、主動(dòng)告警、采集統(tǒng)計(jì)等多種高級(jí)管控特性

三. iLogtail發(fā)展歷程

秉承著阿里人簡(jiǎn)單的特點(diǎn)，iLogtail的命名也非常簡(jiǎn)單，我們最開(kāi)始期望的就是能夠有一個(gè)統(tǒng)一去Tail日志的工具，所以就叫做Logtail，添加上“i”的原因主要當(dāng)時(shí)使用了inotify的技術(shù)，能夠讓日志采集的延遲控制在毫秒級(jí)，因此最后叫做iLogtail。從2013年開(kāi)始研發(fā)，iLogtail整個(gè)發(fā)展歷程概括起來(lái)大致可以分為三個(gè)階段，分別是飛天5K階段、阿里集團(tuán)階段和云原生階段。

1.飛天5K階段

作為中國(guó)云計(jì)算領(lǐng)域的里程碑，2013年8月15日，阿里巴巴集團(tuán)正式運(yùn)營(yíng)服務(wù)器規(guī)模達(dá)到5000(5K)的“飛天”集群，成為中國(guó)第一個(gè)獨(dú)立研發(fā)擁有大規(guī)模通用計(jì)算平臺(tái)的公司，也是世界上第一個(gè)對(duì)外提供5K云計(jì)算服務(wù)能力的公司。

飛天5K項(xiàng)目從2009年開(kāi)始，從最開(kāi)始的30臺(tái)逐漸發(fā)展到5000，不斷解決系統(tǒng)核心的問(wèn)題，比如說(shuō)規(guī)模、穩(wěn)定性、運(yùn)維、容災(zāi)等等。而iLogtail在這一階段誕生，最開(kāi)始就是要解決5000臺(tái)機(jī)器的監(jiān)控、問(wèn)題分析、定位的工作(如今的詞語(yǔ)叫做“可觀(guān)測(cè)性”)。從30到5000的躍升中，對(duì)于可觀(guān)測(cè)問(wèn)題有著諸多的挑戰(zhàn)，包括單機(jī)瓶頸、問(wèn)題復(fù)雜度、排查便捷性、管理復(fù)雜度等。 

在5K階段，iLogtail本質(zhì)上解決的是從單機(jī)、小規(guī)模集群到大規(guī)模的運(yùn)維監(jiān)控挑戰(zhàn)，這一階段iLogtail主要的特點(diǎn)有：

• 功能：實(shí)時(shí)日志、監(jiān)控采集，日志抓取延遲毫秒級(jí)
• 性能：?jiǎn)魏颂幚砟芰?0M/s，5000臺(tái)集群平均資源占用0.5%CPU核
• 可靠性：自動(dòng)監(jiān)聽(tīng)新文件、新文件夾，支持文件輪轉(zhuǎn)，處理網(wǎng)絡(luò)中斷
• 管理：遠(yuǎn)程Web管理，配置文件自動(dòng)下發(fā)
• 運(yùn)維：加入集團(tuán)yum源，運(yùn)行狀態(tài)監(jiān)控，異常自動(dòng)上報(bào)
• 規(guī)模：3W+部署規(guī)模，上千采集配置項(xiàng)，日10TB數(shù)據(jù)

2. 阿里集團(tuán)階段

iLogtail在阿里云飛天5K項(xiàng)目中的應(yīng)用解決了日志、監(jiān)控統(tǒng)一收集的問(wèn)題，而當(dāng)時(shí)阿里巴巴集團(tuán)、螞蟻等還缺少一套統(tǒng)一、可靠的日志采集系統(tǒng)，因此我們開(kāi)始推動(dòng)iLogtail作為集團(tuán)、螞蟻的日志采集基礎(chǔ)設(shè)施。從5K這種相對(duì)獨(dú)立的項(xiàng)目到全集團(tuán)應(yīng)用，不是簡(jiǎn)單復(fù)制的問(wèn)題，而我們要面對(duì)的是更多的部署量、更高的要求以及更多的部門(mén)：

• 百萬(wàn)規(guī)模運(yùn)維問(wèn)題：此時(shí)整個(gè)阿里、螞蟻的物理機(jī)、虛擬機(jī)超過(guò)百萬(wàn)臺(tái)，我們希望只用1/3的人力就可以運(yùn)維管理百萬(wàn)規(guī)模的Logtail
• 更高的穩(wěn)定性：iLogtail最開(kāi)始采集的數(shù)據(jù)主要用于問(wèn)題排查，集團(tuán)廣泛的應(yīng)用場(chǎng)景對(duì)于日志可靠性要求越來(lái)越高，例如計(jì)費(fèi)計(jì)量數(shù)據(jù)、交易數(shù)據(jù)，而且還需要滿(mǎn)足雙十一、雙十二等超大數(shù)據(jù)流量的壓力考驗(yàn)。
• 多部門(mén)、團(tuán)隊(duì)：從服務(wù)5K團(tuán)隊(duì)到近千個(gè)團(tuán)隊(duì)，會(huì)有不同的團(tuán)隊(duì)使用不同的iLogtail，而一個(gè)iLogtail也會(huì)被多個(gè)不同的團(tuán)隊(duì)使用，在租戶(hù)隔離上對(duì)iLogtail是一個(gè)新的挑戰(zhàn)。

經(jīng)過(guò)幾年時(shí)間和阿里集團(tuán)、螞蟻同學(xué)的合作打磨，iLogtail在多租戶(hù)、穩(wěn)定性等方面取得了非常大的進(jìn)步，這一階段iLogtail主要的特點(diǎn)有：

• 功能：支持更多的日志格式，例如正則、分隔符、JSON等，支持多種日志編碼方式，支持?jǐn)?shù)據(jù)過(guò)濾、脫敏等高級(jí)處理
• 性能：極簡(jiǎn)模式下提升到單核100M/s，正則、分隔符、JSON等方式20M/s+
• 可靠性：采集可靠性支持Polling、輪轉(zhuǎn)隊(duì)列順序保證、日志清理保護(hù)、CheckPoint增強(qiáng);進(jìn)程可靠性增加Critical自恢復(fù)、Crash自動(dòng)上報(bào)、多級(jí)守護(hù)

日志保序采集方案原理(細(xì)節(jié)可參考《iLogtail技術(shù)分享(一) : Polling + Inotify 組合下的日志保序采集方案》)

• 多租戶(hù)：支持全流程多租戶(hù)隔離、多級(jí)高低水位隊(duì)列、采集優(yōu)先級(jí)、配置級(jí)/進(jìn)程級(jí)流量控制、臨時(shí)降級(jí)機(jī)制

多租戶(hù)隔離整體流程(細(xì)節(jié)可參考《iLogtail技術(shù)分享(二)：多租戶(hù)隔離技術(shù)+雙十一實(shí)戰(zhàn)效果》)

• 運(yùn)維：基于集團(tuán)StarAgent自動(dòng)安裝與守護(hù)，異常主動(dòng)通知，提供多種問(wèn)題自查工具
• 規(guī)模：百萬(wàn)+部署規(guī)模，千級(jí)別內(nèi)部租戶(hù)，10萬(wàn)+采集配置，日采集PB級(jí)數(shù)據(jù)

3.云原生階段

隨著阿里所有IT基礎(chǔ)設(shè)施全面云化，以及iLogtail所屬產(chǎn)品SLS(日志服務(wù))正式在阿里云上商業(yè)化，iLogtail開(kāi)始全面擁抱云原生。從阿里內(nèi)部商業(yè)化并對(duì)外部各行各業(yè)的公司提供服務(wù)，對(duì)于iLogtail的挑戰(zhàn)的重心已經(jīng)不是性能和可靠性，而是如何適應(yīng)云原生(容器化、K8s，適應(yīng)云上環(huán)境)、如何兼容開(kāi)源協(xié)議、如何去處理碎片化需求。這一階段是iLogtail發(fā)展最快的時(shí)期，經(jīng)歷了非常多重要的變革：

• 統(tǒng)一版本：iLogtail最開(kāi)始的版本還是基于GCC4.1.2編譯，代碼還依賴(lài)飛天基座，為了能適用更多的環(huán)境，iLogtail進(jìn)行了全版本的重構(gòu)，基于一套代碼實(shí)現(xiàn)Windows/Linux、X86/Arm、服務(wù)器/嵌入式等多種環(huán)境的編譯發(fā)版
• 全面支持容器化、K8s：除了支持容器、K8s環(huán)境的日志、監(jiān)控采集外，對(duì)于配置管理也進(jìn)行了升級(jí)，支持通過(guò)Operator的方式進(jìn)行擴(kuò)展，只需要配置一個(gè)AliyunLogConfig的K8s自定義資源就可以實(shí)現(xiàn)日志、監(jiān)控的采集

iLogtail Kubernetes日志采集原理(細(xì)節(jié)可參考《Kubernetes日志采集原理剖析》)

• 插件化擴(kuò)展：iLogtail增加插件系統(tǒng)，可自由擴(kuò)展Input、Processor、Aggregator、Flusher插件用以實(shí)現(xiàn)各類(lèi)自定義的功能

iLogtail插件系統(tǒng)整體流程(細(xì)節(jié)可參考《iLogtail插件系統(tǒng)簡(jiǎn)介》)

• 規(guī)模：千萬(wàn)部署規(guī)模，數(shù)萬(wàn)內(nèi)外部客戶(hù)，百萬(wàn)+采集配置項(xiàng)，日采集數(shù)十PB數(shù)據(jù)

四.開(kāi)源背景與期待

閉源自建的軟件永遠(yuǎn)無(wú)法緊跟時(shí)代潮流，尤其在當(dāng)今云原生的時(shí)代，我們堅(jiān)信開(kāi)源才是iLogtail最優(yōu)的發(fā)展策略，也是釋放其最大價(jià)值的方法。iLogtail作為可觀(guān)測(cè)領(lǐng)域最基礎(chǔ)的軟件，我們將之開(kāi)源，也希望能夠和開(kāi)源社區(qū)一起共建，持續(xù)優(yōu)化，爭(zhēng)取成為世界一流的可觀(guān)測(cè)數(shù)據(jù)采集器。對(duì)于未來(lái)iLogail的發(fā)展，我們期待：

• iLogtail在性能和資源占用上相比其他開(kāi)源采集軟件具備一定優(yōu)勢(shì)，相比開(kāi)源軟件，在千萬(wàn)部署規(guī)模、日數(shù)十PB數(shù)據(jù)的規(guī)模性下為我們減少了100TB的內(nèi)存和每年1億的CPU核小時(shí)數(shù)。我們也希望這款采集軟件可以為更多的企業(yè)帶來(lái)資源效率的提升，實(shí)現(xiàn)可觀(guān)測(cè)數(shù)據(jù)采集的“共同富裕”。
• 目前iLogtail還只是在阿里內(nèi)部以及很小一部分云上企業(yè)(雖然有幾萬(wàn)家，但是面對(duì)全球千萬(wàn)的企業(yè)，這個(gè)數(shù)字還很小)，面對(duì)的場(chǎng)景相對(duì)還較少，我們希望有更多不同行業(yè)、不同特色的公司可以使用iLogtail并對(duì)其提出更多的數(shù)據(jù)源、處理、輸出目標(biāo)的需求，豐富iLogtail支持的上下游生態(tài)。
• 性能、穩(wěn)定性是iLogtail的最基本追求，我們也希望能夠通過(guò)開(kāi)源社區(qū)，吸引更多優(yōu)秀的開(kāi)發(fā)者，一起共建iLogtail，持續(xù)提升這款可觀(guān)測(cè)數(shù)據(jù)采集器的性能和穩(wěn)定性。

鏈接匯總：

1)阿里正式開(kāi)源可觀(guān)測(cè)數(shù)據(jù)采集器iLogtail：https://github.com/alibaba/ilogtail

2)《iLogtail技術(shù)分享(一) : Polling + Inotify 組合下的日志保序采集方案》：https://zhuanlan.zhihu.com/p/29303600

3)《iLogtail技術(shù)分享(二)：多租戶(hù)隔離技術(shù)+雙十一實(shí)戰(zhàn)效果》：https://www.sohu.com/a/205324880_465959

4)《Kubernetes日志采集原理剖析》：https://developer.aliyun.com/article/806369

5)《iLogtail插件系統(tǒng)簡(jiǎn)介》：https://github.com/alibaba/ilogtail/blob/main/docs/zh/concept%26designs/Overview.md