iLogtail開源之路

　　2022年6月底，阿里云iLogtail代碼完整開源，正式發(fā)布了完整功能的iLogtail社區(qū)版。iLogtail作為阿里云SLS官方標配的采集器，多年以來一直穩(wěn)定服務(wù)阿里集團、螞蟻集團以及眾多公有云上的企業(yè)客戶，目前已經(jīng)有千萬級的安裝量，每天采集數(shù)十PB的可觀測數(shù)據(jù)，廣泛應(yīng)用于線上監(jiān)控、問題分析/定位、運營分析、安全分析等多種場景。此次完整開源，iLogtail社區(qū)版首次在內(nèi)核能力上與企業(yè)版完全對齊，開發(fā)者可以構(gòu)建出與企業(yè)版性能相當?shù)膇Logtail云原生可觀測性數(shù)據(jù)采集器。

　　iLogtail的核心定位是可觀測數(shù)據(jù)的采集器，幫助開發(fā)者構(gòu)建統(tǒng)一的數(shù)據(jù)采集層，助力可觀測平臺打造各種上層的應(yīng)用場景。iLogtail一貫秉承開放共建的原則，歡迎任何形式的社區(qū)討論交流及公建。

　　可觀測性探討

　　生活中的可觀測

　　可觀測性指的是從系統(tǒng)的外部輸出推斷及衡量系統(tǒng)內(nèi)部狀態(tài)。在我們生活當中也會遇到很多可觀測的例子。汽車儀表盤就是一個很典型的可觀測例子，在駕駛汽車過程中，特別需要高度重視就是行駛安全問題。而汽車儀表盤降低了識別汽車內(nèi)部狀態(tài)的門檻，即使非汽車工程專業(yè)人員也能通過儀表盤快速識別汽車的內(nèi)部狀態(tài)。

　　另外，我們平常的看病可以認為是人體可觀測的例子。在古代，醫(yī)療水平比較落后，整體來說人體是一個黑盒，只能通過表面的望聞問切來診斷病因，然而這種方式過度的依賴醫(yī)生的經(jīng)驗、缺乏有力的數(shù)據(jù)支撐。而到了近代，隨著心電圖、X光等醫(yī)療設(shè)備的發(fā)展，人體的內(nèi)部機制變得越來越透明，大幅提升了醫(yī)療水平，給人們的身體健康帶來了福音。通過上述的例子我們可以看到，可觀測性不僅要能定性地反饋系統(tǒng)內(nèi)部狀態(tài)，最重要的是要定量的論證系統(tǒng)內(nèi)部狀態(tài)，需要有足夠的數(shù)據(jù)依據(jù)，也就是我們提到的可觀測數(shù)據(jù)的質(zhì)量和準確性。

　　機遇與挑戰(zhàn)

　　回到我們軟件行業(yè)，經(jīng)過幾十年的飛速發(fā)展，整個開發(fā)模式、系統(tǒng)架構(gòu)、部署模式、基礎(chǔ)設(shè)施等也都經(jīng)過了幾次顛覆性的變革，這些變革帶來了更快的開發(fā)和部署效率，但隨之而來整個的系統(tǒng)也更加的復(fù)雜、開發(fā)所依賴人和部門也更多、部署模式和運行環(huán)境也更加動態(tài)和不確定，這也對可觀測數(shù)據(jù)采集提出了更高的要求。首先需要適應(yīng)開發(fā)模式快速迭代的需求，需要能夠與DevOps流程等進行高度的集成，通過輕量級、自動化集成的方式實現(xiàn)開發(fā)、測試、運維的一體化;也需要適應(yīng)部署架構(gòu)分布式、容器化的需求，提升業(yè)務(wù)服務(wù)動態(tài)、及時、準確發(fā)現(xiàn)的能力;最后，云原生的發(fā)展也帶來了更多的上下游依賴，因此也需要適應(yīng)數(shù)據(jù)來源、數(shù)據(jù)類型越來越多的需求。

　　可觀測性的數(shù)據(jù)基礎(chǔ)

　　Logs、Traces、Metrics作為可觀測性數(shù)據(jù)的三大支柱，基本可以滿足各類監(jiān)控、告警、分析、問題排查等需求。這里大致分析下這三類數(shù)據(jù)的特點、轉(zhuǎn)化方式以及適用場景：

　　Logs：作為軟件運行狀態(tài)的載體，通過日志可以詳細解釋系統(tǒng)運行狀態(tài)及還原業(yè)務(wù)處理的過程。常見日志類型包括運行日志、訪問日志、交易日志、內(nèi)核日志、滿日志、錯誤日志等。

　　Metrics：是指對系統(tǒng)中某一類信息的統(tǒng)計聚合，相對比較離散。一般有name、labels、time、values組成，Metrics數(shù)據(jù)量一般很小，相對成本更低，查詢的速度比較快。

　　Traces：是最標準的調(diào)用日志，除了定義了調(diào)用的父子關(guān)系外(一般通過TraceID、SpanID、ParentSpanID)，一般還會定義操作的服務(wù)、方法、屬性、狀態(tài)、耗時等詳細信息。

　　三者間的轉(zhuǎn)換關(guān)系：Logs在調(diào)用鏈場景結(jié)構(gòu)化后其實可以轉(zhuǎn)變?yōu)門race，在進行聚合、降采樣操作后會變成Metrics。

　　開源方案探討

　　目前行業(yè)上主流的可觀測開源方案，大概可以分為5個部分。

　　采集端：承載可觀測數(shù)據(jù)采集及一部分前置的數(shù)據(jù)處理功能。隨著云原生的發(fā)展，采集端也需要適應(yīng)時代潮流，提供對K8s采集的友好支持。常見的采集端有Filebeat、FluentD/Fluent-bIt，以及我們開源的iLogtail。

　　消息隊列：采集Agent往往不會直接將采集到的數(shù)據(jù)發(fā)送到存儲系統(tǒng)，而是寫入消息隊列，起到削峰填谷的作用，避免流量洪峰導(dǎo)致存儲系統(tǒng)宕機。常見消息隊列為Kafka、RabbitMQ等。

　　計算：用于消費消息隊列中的數(shù)據(jù)，經(jīng)過處理、聚合后輸出到存儲系統(tǒng)。比較常見的為Flink、Logstash等。

　　存儲分析引擎：提供采集數(shù)據(jù)持久化存儲能力，并提供查詢分析能力。常見的存儲分析引擎為Elasticsearch、ClickHouse及Loki。

　　可視化：借助Kibana和Grafana提供采集數(shù)據(jù)的可視化能力。

　　另外，日志服務(wù)SLS作為一款云原生觀測與分析平臺，為Log、Metric、Trace等數(shù)據(jù)提供大規(guī)模、低成本、實時的平臺化服務(wù)。SLS一站式提供數(shù)據(jù)采集、加工、查詢與分析、可視化、告警、消費與投遞等功能，用戶可以基于SLS快速構(gòu)建一套完整的可觀測平臺。iLogtail企業(yè)版作為SLS官方標配的采集器，承載了業(yè)務(wù)數(shù)據(jù)采集的職責，而iLogtail社區(qū)版正是從企業(yè)版發(fā)展而來的，功能及性能自然也繼承了企業(yè)版的絕大部分能力。

　　iLogtail發(fā)展歷程

　　iLogtail的前身源自阿里云的神農(nóng)項目，自從2013年正式孵化以來，iLogtail始終在不斷演進。

　　誕生初期，面對阿里云自身和早期客戶運維和可觀測性需求，iLogtail主要解決的是從單機、小規(guī)模集群到大規(guī)模的運維監(jiān)控挑戰(zhàn)，此時的iLogtail已經(jīng)具備了基本的文件發(fā)現(xiàn)和輪轉(zhuǎn)處理能力，可以實現(xiàn)日志、監(jiān)控實時采集，抓取毫秒級延遲，單核處理能力約為10M/s。通過Web前端可支持中心化配置文件自動下發(fā)，支持3W+部署規(guī)模，上千采集配置項，實現(xiàn)日10TB數(shù)據(jù)的高效采集。

　　2015年，阿里巴巴開始推進集團和螞蟻金服業(yè)務(wù)上云，面對近千個團隊、數(shù)百萬終端、以及雙11、雙12等超大流量數(shù)據(jù)采集的挑戰(zhàn)，iLogtail在功能、性能、穩(wěn)定性和多租戶支持方面都需要進行巨大的改進。至2017年前后，iLogtail已經(jīng)具備了正則、分隔符、JSON等多個格式日志的解析能力，支持多種日志編碼方式，支持數(shù)據(jù)過濾、脫敏等高級處理能力，單核處理能力極簡模式下提升到100M/s，正則、分隔符、JSON等方式20M/s+。采集可靠性方面，增加文件發(fā)現(xiàn)Polling方式兜底、輪轉(zhuǎn)隊列順序保證、日志清理丟失保護、CheckPoint增強;進程可靠性方面，增加異常自動恢復(fù)、Crash自動上報、守護進程等。通過全流程多租戶隔離、多級高低水位隊列、配置級/進程級流量控制、臨時降級等機制，支持百萬+部署規(guī)模，千級別租戶，10萬+采集配置項，實現(xiàn)日PB級數(shù)據(jù)的穩(wěn)定采集。

　　隨著阿里推進核心業(yè)務(wù)全面上云，以及iLogtail所屬日志服務(wù)(SLS)正式在阿里云上商業(yè)化，iLogtail開始全面擁抱云原生。面對多元的云上環(huán)境、迅速發(fā)展的開源生態(tài)和大量涌入的行業(yè)客戶需求，iLogtail的發(fā)展的重心轉(zhuǎn)移到解決如何適應(yīng)云原生、如何兼容開源協(xié)議和如何去處理碎片化需求等問題上。2018年iLogtail正式支持docker容器采集，2019年支持containerd容器采集，2020年全面升級Metric采集，2021年增加Trace支持。通過全面支持容器化、K8S Operator管控和可擴展插件系統(tǒng)，iLogtail支持千萬部署規(guī)模，數(shù)萬內(nèi)外部客戶，百萬+采集配置項，實現(xiàn)日數(shù)十PB數(shù)據(jù)的穩(wěn)定采集。2021年11月iLogtail邁出了開源的第一步，將Golang插件代碼開源。自開源以來，吸引了數(shù)百名開發(fā)者的關(guān)注，并且也有不少開發(fā)者貢獻了processor跟flusher插件。2022年6月C++核心代碼也正式開源了，自此開發(fā)者可以基于該版本構(gòu)建完整的云原生可觀測數(shù)據(jù)采集方案。

　　iLogtail核心優(yōu)勢

　　核心優(yōu)勢 -- 輕量、高效、穩(wěn)定、可靠

　　輕量

　　可觀測數(shù)據(jù)采集Agent作為一個基礎(chǔ)設(shè)施，往往需要每臺機器都有部署，比如目前阿里內(nèi)部有數(shù)百萬的裝機量，每天會產(chǎn)生幾十PB的可觀測數(shù)據(jù)。因此不管是內(nèi)存還是CPU的一點點節(jié)省，都能帶來比較大的成本收益。特別是，K8s Sidecar模式對于內(nèi)存的要求更加苛刻，因為iLogtail與業(yè)務(wù)容器共同部署，iLogtail部署量會隨業(yè)務(wù)規(guī)模擴大而增長。從設(shè)計初期，我們就比較重視iLogtail的資源占用問題，選擇了主體部分C++、插件部分Golang實現(xiàn)，并且通過一些技術(shù)細節(jié)(詳見下文)的優(yōu)化，使得內(nèi)存還是CPU相對于同類Agent都有較大的優(yōu)勢。

　　高效采集

　　對于日志采集，比較常見的手段是輪詢機制，這是一種主動探測的收集方式，通過定期檢測日志文件有無更新來觸發(fā)日志采集;相應(yīng)的也存在一種被動監(jiān)聽的事件模式，依賴于操作系統(tǒng)的事件通知(對操作系統(tǒng)有一定的要求)，常見的事件通知機制是Linux 2.6.13內(nèi)核版本引入的inotify機制。輪詢相對事件通知的實現(xiàn)復(fù)雜度要低很多、天然支持跨平臺而且對于系統(tǒng)限制性不高;但輪詢的采集延遲以及資源消耗較高，而且在文件規(guī)模較大時輪詢一次的時間較長，比較容易發(fā)生采集延遲。

　　為了同時兼顧采集效率以及跨平臺的支持，iLogtail采用了輪詢(polling)與事件(inotify)并存的模式進行日志采集，既借助了inotify的低延遲與低性能消耗的特點，也通過輪詢的方式兼顧了運行環(huán)境的全面性。

　　iLogtail內(nèi)部以事件的方式觸發(fā)日志讀取行為。其中，polling和inotify作為兩個獨立模塊，分別將各自產(chǎn)生的Create/Modify/Delete事件，存入Polling Event Queue和Inotify Event Queue中。

　　輪詢模塊由DirFilePolling和ModifyPolling兩個線程組成，DirFilePolling負責根據(jù)用戶配置定期遍歷文件夾，將符合日志采集配置的文件加入到modify cache中;ModifyPolling負責定期掃描modify cache中文件狀態(tài)，對比上一次狀態(tài)(Dev、Inode、Modify Time、Size)，若發(fā)現(xiàn)更新則生成modify event。

　　inotify屬于事件監(jiān)聽方式，根據(jù)用戶配置監(jiān)聽對應(yīng)的目錄以及子目錄，當監(jiān)聽目錄存在變化，內(nèi)核會產(chǎn)生相應(yīng)的通知事件。

　　由Event Handler線程負責將兩個事件隊列合并到內(nèi)部的Event Queue中，并處理相應(yīng)的Create/Modify/Delete事件，進而進行實際的日志采集。

　　此外，我們也通過一些技術(shù)手段，保證了polling、inotify兩種機制的高效配合，整體近一步提升了iLogtail運行效率。

　　事件合并：為避免輪詢事件和inotify事件多次觸發(fā)事件處理行為，iLogtail在事件處理之前將重復(fù)的輪詢/inotify事件進行合并，減少無效的事件處理行為;

　　輪詢自動降級：如果在系統(tǒng)支持且資源足夠的場景下，inotify無論從延遲和性能消耗都要優(yōu)于輪詢，因此當某個目錄inotify可以正常工作時，則該目錄的輪詢進行自動降級，輪詢間隔大幅降低到對CPU基本無影響的程度。

　　日志順序采集

　　日志順序性采集是日志采集需要提供的基本功能，也是一個采集的難點，需要考慮如下場景：

　　適應(yīng)不同的日志輪轉(zhuǎn)(rotate)機制：日志輪轉(zhuǎn)是指當日志滿足一定條件(時間或文件大小)時，需要進行重命名、壓縮等操作，之后創(chuàng)建新的日志文件繼續(xù)寫入。另外，不同使用日志庫輪轉(zhuǎn)文件的格式不盡相同，有的時間結(jié)尾，有的數(shù)字結(jié)尾等。

　　適應(yīng)不同的采集路徑配置方式：優(yōu)秀的日志采集agent并不應(yīng)該強制限制用戶的配置方式，尤其在指定日志采集文件名時，需要適應(yīng)不同用戶的配置習(xí)慣。不管是精準路徑匹配，還是模糊匹配，例如*.log或*.log*，都不能出現(xiàn)日志輪轉(zhuǎn)時多收集或者少收集的情況。

　　為了實現(xiàn)日志文件的順序采集，首先需要定義好文件的唯一標識。我們知道在文件系統(tǒng)中，可以通過dev+inode的組合唯一標識一個文件。文件的move操作雖然可以改變文件名，但并不涉及文件的刪除創(chuàng)建，dev+inode并不會變化，因此通過dev+inode可以非常方便的判斷一個文件是否發(fā)生了輪轉(zhuǎn)。但是dev+inode只能保證同一時刻文件的唯一性，當涉及文件快速刪除創(chuàng)建的時候，前后兩個文件的dev+inode很可能是相同的。因此純粹通過dev+inode判斷輪轉(zhuǎn)并不可行，iLogtail引入了文件簽名(signature)的概念，使用日志文件的前1024字節(jié)的hash作為文件的signature，只有當dev+inode+signature一致的情況下才會認為該文件是輪轉(zhuǎn)的文件。此外，iLogtail內(nèi)部也引入了文件輪轉(zhuǎn)隊列，保證了文件的順序采集。

　　采集可靠性

　　iLogtail作為一個可觀測數(shù)據(jù)基礎(chǔ)采集組件，除了資源、性能外，可靠性也是一項關(guān)鍵指標。對于一些異常場景，iLogtail也有充分的設(shè)計考慮，保證了在網(wǎng)絡(luò)異常、流量突增、進程重啟等場景下依然能夠完成正常的采集任務(wù)。

　　日志處理阻塞

　　問題描述：iLogtail需要大量部署在不同的業(yè)務(wù)機器上，運行環(huán)境是復(fù)雜多變的，應(yīng)用日志burst寫入、網(wǎng)絡(luò)暫時性阻塞、服務(wù)端Quota不足、CPU/磁盤負載較高等情況在所難免，當這些情況發(fā)生時，很容易造成日志采集進度落后于日志產(chǎn)生進度，此時，iLogtail需要在合理的資源限制下盡可能保留住這些日志，等待網(wǎng)絡(luò)恢復(fù)或系統(tǒng)負載下降時將這些日志采集到服務(wù)器，并且保證日志采集順序不會因為采集阻塞而混亂。

　　解決思路：

　　iLogtail內(nèi)部通過保持輪轉(zhuǎn)日志file descriptor的打開狀態(tài)來防止日志采集阻塞時未采集完成的日志文件被file system回收(在文件輪轉(zhuǎn)隊列中的file descriptor一直保持打開狀態(tài)，保證文件引用計數(shù)至少為1)。同時，通過文件輪轉(zhuǎn)隊列的順序讀取保證日志采集順序與日志產(chǎn)生順序一致。

　　若日志采集進度長時間持續(xù)落后于日志產(chǎn)生進度，完全的不回收機制，則很有可能出現(xiàn)文件輪轉(zhuǎn)隊列會無限增長的情況，進而導(dǎo)致磁盤被寫爆，因此iLogtail內(nèi)部對于文件輪轉(zhuǎn)隊列設(shè)置了上限，當size超過上限時禁止后續(xù)Reader的創(chuàng)建，只有這種持續(xù)的極端情況出現(xiàn)時，才會出現(xiàn)丟日志采集的情況。當然，在問題被放大之前，iLogtail也會通過報警的方式，通知用戶及時介入修復(fù)問題。

　　采集配置更新/進程升級

　　問題描述：配置更新或進行升級時需要中斷采集并重新初始化采集上下文，iLogtail需要保證在配置更新/進程升級時，即使日志發(fā)生輪轉(zhuǎn)也不會丟失日志。

　　解決思路：

　　為保證配置更新/升級過程中日志數(shù)據(jù)不丟失，在iLogtail在配置重新加載前或進程主動退出前，會將當前所有采集的狀態(tài)保存到本地的checkpoint文件中;當新配置應(yīng)用/進程啟動后，會加載上一次保存的checkpoint，并通過checkpoint恢復(fù)之前的采集狀態(tài)。

　　然而在老版本checkpoint保存完畢到新版本采集Reader創(chuàng)建完成的時間段內(nèi)，很有可能出現(xiàn)日志輪轉(zhuǎn)的情況，因此新版本在加載checkpoint時，會檢查對應(yīng)checkpoint的文件名、dev+inode有無變化。

　　若文件名與dev+inode未變且signature未變，則直接根據(jù)該checkpoint創(chuàng)建Reader即可。

　　若文件名與dev+inode變化則從當前目錄查找對應(yīng)的dev+inode，若查找到則對比signature是否變化。若signature未變則認為是文件輪轉(zhuǎn)，根據(jù)新文件名創(chuàng)建Reader;若signature變化則認為是該文件被刪除后重新創(chuàng)建，忽略該checkpoint。

　　進程crash、宕機等異常情況

　　問題描述：在進程crash或宕機時，iLogtail需要提供容錯機制，不丟數(shù)據(jù)，盡可能的少重復(fù)采集。解決思路：

　　進程crash或宕機沒有退出前記錄checkpoint的時機，因此iLogtail還會定期將采集進度dump到本地：除了恢復(fù)正常日志文件狀態(tài)外，還會查找輪轉(zhuǎn)后的日志，盡可能降低日志丟失風(fēng)險。

　　核心優(yōu)勢 -- 性能及隔離性

　　無鎖化設(shè)計及時間片調(diào)度

　　業(yè)界主流的Agent對于每個配置會分配獨立的線程/go runtime來進行數(shù)據(jù)讀取，而iLogtail數(shù)據(jù)的讀取只配置了一個線程，主要原因是：

　　數(shù)據(jù)讀取的瓶頸并不在于計算而是磁盤，單線程足以完成所有配置的事件處理以及數(shù)據(jù)讀取。

　　單線程的另一個優(yōu)勢是可以使事件處理和數(shù)據(jù)讀取在無鎖環(huán)境下運行，相對多線程處理性價比較高。

　　iLogtail數(shù)據(jù)讀取線程可完成每秒200MB以上的數(shù)據(jù)讀取(SSD速率可以更高)。

　　但單線程的情況下會存在多個配置間資源分配不均的問題，如果使用簡單的FCFS( First Come First Serve)方式，一旦一個寫入速度極高的文件占據(jù)了處理單元，它就一直運行下去，直到該文件被處理完成并主動釋放資源，此方式很有可能造成其他采集的文件被餓死。

　　因此我們采用了基于時間片的采集調(diào)度方案，使各個配置間盡可能公平的調(diào)度，防止采集文件餓死的現(xiàn)象發(fā)生。iLogtail將Polling以及Inotify事件合并到無鎖的事件隊列中，每個文件的修改事件會觸發(fā)日志讀取。每次讀取從上次記錄的偏移位置開始，并嘗試在固定的時間片內(nèi)將文讀取到EOF處。如果時間片內(nèi)讀取完畢，則表示事件處理完成，刪除事件;否則，將事件重新Push到隊列尾部，等待下一次調(diào)用。

　　通過以上設(shè)計，保證了iLogtail可以高性能的進行數(shù)據(jù)采集。對比數(shù)據(jù)可以詳見：https://developer.aliyun.com/article/850614

　　多租戶隔離

　　基于時間片的采集調(diào)度保證了各個配置的日志在數(shù)據(jù)讀取時得到公平的調(diào)度，滿足了多租戶隔離中基本的公平性，但對于隔離性并未起到幫助作用。例如當部分采集配置因處理復(fù)雜或網(wǎng)絡(luò)異常等原因阻塞時，阻塞配置依然會進行處理，最終會導(dǎo)致隊列到達上限而阻塞數(shù)據(jù)讀取線程，影響其他正常配置。為此我們設(shè)計了一套多級高低水位反饋隊列用以在不同采集配置間實現(xiàn)讀取、解析、發(fā)送各個步驟的有效的協(xié)調(diào)，為了更好的實現(xiàn)不同配置間隔離性，所以iLogtail會為每個配置創(chuàng)建一組隊列。

　　多級：iLogtail從采集到輸出總體要經(jīng)過讀取->解析->發(fā)送三個步驟，iLogtail在相鄰步驟間分別設(shè)置一個隊列。

　　高低水位：每個隊列設(shè)置高低兩個水位，高水位時停止非緊急數(shù)據(jù)寫入，只有恢復(fù)到低水位時才允許再次寫入。

　　反饋：在準備讀取當前隊列數(shù)據(jù)時會同步檢查下一級隊列狀態(tài)，下一級隊列高水位則跳過讀取;當前隊列從高水位消費到低水位時，異步通知關(guān)聯(lián)的前一級隊列。

　　極端場景處理

　　對于一些阻塞場景的可靠性也需要考慮，主要包括事件處理、數(shù)據(jù)讀取邏輯以及數(shù)據(jù)發(fā)送控制三個方面：

　　事件處理與數(shù)據(jù)讀取無關(guān)，即使讀取關(guān)聯(lián)的隊列滿也照常處理，這里的處理主要是更新文件meta、將輪轉(zhuǎn)文件放入輪轉(zhuǎn)隊列，可保證在配置阻塞的情況下，即使文件輪轉(zhuǎn)也不會丟失數(shù)據(jù)。

　　當配置關(guān)聯(lián)的解析隊列滿時，如果將事件重新放回隊列尾，則會造成較多的無效調(diào)度，使CPU空轉(zhuǎn)。因此iLogtail在遇到解析隊列滿時，將該事件放到一個專門的blocked隊列中，當解析隊列異步反饋時重新將blocked隊列中的數(shù)據(jù)放回事件隊列。

　　Sender中每個配置的隊列關(guān)聯(lián)一個SenderInfo，SenderInfo中記錄該配置當前網(wǎng)絡(luò)是否正常、Quota是否正常以及最大允許的發(fā)送速率。每次Sender會根據(jù)SenderInfo中的狀從隊列中取數(shù)據(jù)，這里包括：網(wǎng)絡(luò)失敗重試、Quota超限重試、狀態(tài)更新、流控等邏輯。

　　核心優(yōu)勢 -- 插件化擴展能力

　　iLogtail進程由兩部分組成，一是C++編寫的主體二進制進程，提供了管控、文件采集、C++加速處理的功能;二是Golang編寫的插件部分，通過插件系統(tǒng)實現(xiàn)了處理能力的擴展以及更豐富的上下游生態(tài)支持。

　　上下游生態(tài)：通過插件系統(tǒng)的擴展，目前iLogtail已經(jīng)支持了眾多數(shù)據(jù)源的接入，數(shù)據(jù)源類型覆蓋Log、Metric、Trace，數(shù)據(jù)源除了文件的采集，還包括了標準協(xié)議的支持，例如HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。數(shù)據(jù)輸出生態(tài)也從SLS逐步擴展到Kafka、gPRC等，未來也會支持ClickHouse、ElasticSearch等。

　　處理能力擴展：iLogtail采用PipeLine的設(shè)計，通過Input插件采集到數(shù)據(jù)，會經(jīng)過采集配置中設(shè)定的Processor處理，之后經(jīng)過Aggregator插件打包，最終通過Flusher發(fā)送到日志存儲系統(tǒng)。數(shù)據(jù)處理環(huán)境包含數(shù)據(jù)切分、字段提取、過濾、數(shù)據(jù)增強等環(huán)節(jié)，所有插件可以自由組合。此外，針對于正則、Json、分隔符等特定格式，iLogtail還提供了C++加速能力。

　　快速迭代：開發(fā)者也可以根據(jù)自己的需求，定制開發(fā)相應(yīng)的插件。因為每個插件相互獨立，所以開發(fā)者只需要按照接口規(guī)范開發(fā)即可，入手門檻較低。以Processor插件接口為例，只需要實現(xiàn)以下接口，即可快速提供一個處理插件。

　　復(fù)制

　　// Processor also can be a filter

　　type Processor interface {

　　// Init called for init some system resources, like socket, mutex...

　　Init(Context) error

　　// Description returns a one-sentence description on the Input

　　Description() string

　　// Apply the filter to the given metric

　　ProcessLogs(logArray []*protocol.Log) []*protocol.Log

　　}

　　1.

　　2.

　　3.

　　4.

　　5.

　　6.

　　7.

　　8.

　　9.

　　10.

　　11.

　　核心優(yōu)勢 -- K8s采集能力

　　作為容器編排領(lǐng)域的標準，Kubernetes(K8s)應(yīng)用的場景越來越廣泛，iLogtail 在K8s下也提供了完備的采集能力。

　　部署模式

　　在Kubernetes場景下，iLogtail主要常用的有3種工作模式：

　　DaemonSet方式

　　模式：在K8s的每個node上部署一個iLogtail，由該iLogtail采集節(jié)點上所有容器的日志到日志系統(tǒng)。

　　優(yōu)點：運維簡單、資源占用少、支持采集容器的標準輸出和文本文件、配置方式靈活。

　　缺點：iLogtail需要采集節(jié)點上所有容器的日志，各個容器之間的隔離性較弱，且對于業(yè)務(wù)超級多的集群可能存在一定的性能瓶頸。

　　Sidecar方式：

　　模式：一個POD中伴隨業(yè)務(wù)容器運行一個iLogtail容器，用于采集該POD中業(yè)務(wù)容器產(chǎn)生的日志。

　　優(yōu)點：Sidecar方式為每個需要采集日志的容器創(chuàng)建一個Sidecar容器，多租戶隔離性好、性能好。

　　缺點：資源占用較多。

　　Deployment方式：

　　模式：當業(yè)務(wù)容器用PVC掛載日志目錄或者需要全局連接API Server獲取K8s元數(shù)據(jù)等場景，可以選擇在集群中部署一個單副本的iLogtail Deployment進行數(shù)據(jù)采集。

　　采集原理

　　自K8s問世以來，docker運行時一直是主流，但是隨著K8s將dockershim移除，K8s官方推薦優(yōu)先選擇containerd 或 CRI-O作為容器運行時。docker份額目前雖然還是主流但是已經(jīng)在呈逐年下降的趨勢，contailerd、cri-o地位逐年都在快速上升。因此，從K8s支持全面性上，iLogtail需要支持主流的運行時，目前已經(jīng)支持Docker和Containerd兩種容器引擎的數(shù)據(jù)采集。K8s提供了強大的運維部署、彈性伸縮、故障恢復(fù)能力，極大地便利了分布式系統(tǒng)的開發(fā)和管理，然而這也帶來了可觀測數(shù)據(jù)采集難度的增大。特別是一些短Job場景，比如一些機器學(xué)習(xí)的訓(xùn)練任務(wù)，生命周期只有幾分鐘甚至幾秒，如何快速準確地發(fā)現(xiàn)所需要采集的容器至關(guān)重要。

　　容器自動發(fā)現(xiàn)與釋放

　　iLogtail通過訪問位于宿主機上容器運行時(Docker Engine/ContainerD)的sock獲取容器信息。

　　通過監(jiān)聽Docker Event及增量獲取機制，及時感知容器新增與釋放。

　　容器上下文信息獲取

　　容器層級信息：容器名、ID、掛載點、環(huán)境變量、Label

　　K8s層級信息：Pod、命名空間、Labels。

　　容器過濾及隔離性：基于容器上下文信息，提供采集容器過濾能力，可以將不同采集配置應(yīng)用到不同的采集容器上，既可以保證采集的隔離性，也可以減少不必要的資源浪費。

　　元信息關(guān)聯(lián)：基于容器上下文信息和容器環(huán)境變量，提供在日志中富化K8s元信息的能力。

　　采集路徑發(fā)現(xiàn)

　　標準輸出：iLogtail可以根據(jù)容器元信息自動識別不同運行時的標準輸出格式和日志路徑，不需要額外手動配置。

　　容器內(nèi)文件：對于overlay、overlay2的存儲驅(qū)動，iLogtail可以根據(jù)日志類型及容器運行時自動拼接出采集路徑，簡單高效。

　　此外，對于CICD自動化部署和運維程度要求較高的用戶，iLogtail還提供了K8s原生支持，支持通過CRD的方式進行采集配置管理。目前該功能僅企業(yè)版可用，后續(xù)會逐步開源。該方案中，iLogtail K8s新增了一個CustomResourceDefinition擴展，名為AliyunLogConfig。同時開發(fā)了alibaba-log-controller用于監(jiān)聽AliyunLogConfig事件并自動創(chuàng)建iLogtail的采集配置，進而完成日志采集工作。

　　企業(yè)版與社區(qū)版

　　差異比較

　　iLogtail開源后，目前會有兩個版本分支。

　　企業(yè)版：可以從阿里云SLS官方下載到。主要服務(wù)于SLS。

　　社區(qū)版：從GitHub倉庫，release頁下載。

　　iLogtail開源，秉承技術(shù)共享與開發(fā)者共建的原則，所以核心功能是完全開源的，因此可以認為在核心采集能力上(包括采集處理功能、性能、可靠性等)與企業(yè)版是完全對標的。企業(yè)版相對于社區(qū)版的優(yōu)勢主要在于阿里云基礎(chǔ)能力的集成上。

　　作為阿里云SLS官方標配采集器，與SLS無縫集成

　　SLS平臺為iLogtail提供了強大的管控能力，及豐富的API支持。

　　SLS提供了對于Log、Metric、Trace的統(tǒng)一存儲分析能力，使用iLogtail企業(yè)版將數(shù)據(jù)采集到SLS，可以更好的構(gòu)建各類上層應(yīng)用。借助SLS可以實現(xiàn)日志上下文預(yù)覽、Exactly Once等高級特性。

　　借助SLS平臺，可以實現(xiàn)第三方Agent的管控能力。例如，未來SLS也會跟DeepFlow進行深度集成。

　　SLS作為可觀測平臺，既可以承載可觀測數(shù)據(jù)存儲分析的功能，也可以承載流量管道的作用，可以簡化架構(gòu)部署。

　　CloudLens For SLS為iLogtail采集狀態(tài)、數(shù)據(jù)流量監(jiān)控提供了便捷的手段。

　　支持的操作系統(tǒng)、系統(tǒng)架構(gòu)更加豐富，企業(yè)版支持Windows系統(tǒng)跟ARM架構(gòu)。

　　阿里云服務(wù)加持

　　自動化安裝部署能力更高，借助阿里云的運維服務(wù)，可以實現(xiàn)iLogtail批量自動安裝。

　　與阿里云ECS、ACK、ASK、EMR等高度集成，可以一鍵安裝部署，采集數(shù)據(jù)可以快速接入，內(nèi)置分析。

　　企業(yè)版服務(wù)上的保證

　　SLS官方提供企業(yè)應(yīng)用場景下最全最及時的文檔/最佳實踐支持

　　及時的專家服務(wù)(工單、群支持)與需求承接。

　　大規(guī)模/復(fù)雜場景專業(yè)化支持：比如K8s短job，單節(jié)點大流量日志、大規(guī)模采集配置等。

　　基于SLS的云原生可觀測平臺

　　SLS提供了對于Log、Metric、Trace的統(tǒng)一存儲分析能力，并且也可以承載流量管道作用，具備強大的數(shù)據(jù)加工能力，基于SLS可以快速構(gòu)建出一套云原生可觀測平臺。智能告警中樞、智能算法服務(wù)近一步增強了該平臺的智能化水平。用戶可以基于此平臺，便捷高效的構(gòu)建各類ITOps、DevOps、SecOps、BusinessOps上層應(yīng)用。iLogtail企業(yè)版作為SLS官方標配官方標配采集器，在SLS數(shù)據(jù)接入領(lǐng)域充當著排頭兵的指責，承載了大量的接入流量。

　　開源社區(qū)展望

　　技術(shù)共享一直是iLogtail秉承的理念，我們期望和歡迎更多開發(fā)者參與共建。我們希望跟開發(fā)者一起，將iLogtail的上下游生態(tài)建的更豐富。為了提升開發(fā)者的體驗，我們也會持續(xù)的改善iLogtail核心能力跟框架能力，進一步降低開發(fā)門檻，豐富測試體系建設(shè)，為開發(fā)者提供必要的技術(shù)支持。如何高效管理采集配置一直是可觀測采集器的痛點，為此我們也會在不久將來開源服務(wù)端全局管控方案及iLogtail監(jiān)控方案，也歡迎開發(fā)者參與共建，一起打造統(tǒng)一的管控生態(tài)。最后，OpenTelemetry作為可觀測領(lǐng)域的標準，iLogtail也將積極擁抱。K8s原生體驗也是我們追求的方向，我們也有計劃推出iLogtail Operator。

　　關(guān)于iLogtail

　　iLogtail作為阿里云SLS提供的可觀測數(shù)據(jù)采集器，可以運行在服務(wù)器、容器、K8s、嵌入式等多種環(huán)境，支持采集數(shù)百種可觀測數(shù)據(jù)(日志、監(jiān)控、Trace、事件等)，已經(jīng)有千萬級的安裝量。目前，iLogtail已正式開源，歡迎使用及參與共建。

　　GitHub: https://github.com/alibaba/ilogtail

　　社區(qū)版文檔：https://ilogtail.gitbook.io/ilogtail-docs/about/readme

　　企業(yè)版官網(wǎng)：https://help.aliyun.com/document_detail/65018.html​