2022年6月底,阿里云iLogtail代碼完整開源,正式發(fā)布了完整功能的iLogtail社區(qū)版。iLogtail作為阿里云SLS官方標(biāo)配的采集器,多年以來一直穩(wěn)定服務(wù)阿里集團(tuán)、螞蟻集團(tuán)以及眾多公有云上的企業(yè)客戶,目前已經(jīng)有千萬級(jí)的安裝量,每天采集數(shù)十PB的可觀測數(shù)據(jù),廣泛應(yīng)用于線上監(jiān)控、問題分析/定位、運(yùn)營分析、安全分析等多種場景。此次完整開源,iLogtail社區(qū)版首次在內(nèi)核能力上與企業(yè)版完全對(duì)齊,開發(fā)者可以構(gòu)建出與企業(yè)版性能相當(dāng)?shù)膇Logtail云原生可觀測性數(shù)據(jù)采集器。
iLogtail的核心定位是可觀測數(shù)據(jù)的采集器,幫助開發(fā)者構(gòu)建統(tǒng)一的數(shù)據(jù)采集層,助力可觀測平臺(tái)打造各種上層的應(yīng)用場景。iLogtail一貫秉承開放共建的原則,歡迎任何形式的社區(qū)討論交流及公建。
可觀測性探討
生活中的可觀測
可觀測性指的是從系統(tǒng)的外部輸出推斷及衡量系統(tǒng)內(nèi)部狀態(tài)。在我們生活當(dāng)中也會(huì)遇到很多可觀測的例子。汽車儀表盤就是一個(gè)很典型的可觀測例子,在駕駛汽車過程中,特別需要高度重視就是行駛安全問題。而汽車儀表盤降低了識(shí)別汽車內(nèi)部狀態(tài)的門檻,即使非汽車工程專業(yè)人員也能通過儀表盤快速識(shí)別汽車的內(nèi)部狀態(tài)。
另外,我們平常的看病可以認(rèn)為是人體可觀測的例子。在古代,醫(yī)療水平比較落后,整體來說人體是一個(gè)黑盒,只能通過表面的望聞問切來診斷病因,然而這種方式過度的依賴醫(yī)生的經(jīng)驗(yàn)、缺乏有力的數(shù)據(jù)支撐。而到了近代,隨著心電圖、X光等醫(yī)療設(shè)備的發(fā)展,人體的內(nèi)部機(jī)制變得越來越透明,大幅提升了醫(yī)療水平,給人們的身體健康帶來了福音。通過上述的例子我們可以看到,可觀測性不僅要能定性地反饋系統(tǒng)內(nèi)部狀態(tài),最重要的是要定量的論證系統(tǒng)內(nèi)部狀態(tài),需要有足夠的數(shù)據(jù)依據(jù),也就是我們提到的可觀測數(shù)據(jù)的質(zhì)量和準(zhǔn)確性。
機(jī)遇與挑戰(zhàn)
回到我們軟件行業(yè),經(jīng)過幾十年的飛速發(fā)展,整個(gè)開發(fā)模式、系統(tǒng)架構(gòu)、部署模式、基礎(chǔ)設(shè)施等也都經(jīng)過了幾次顛覆性的變革,這些變革帶來了更快的開發(fā)和部署效率,但隨之而來整個(gè)的系統(tǒng)也更加的復(fù)雜、開發(fā)所依賴人和部門也更多、部署模式和運(yùn)行環(huán)境也更加動(dòng)態(tài)和不確定,這也對(duì)可觀測數(shù)據(jù)采集提出了更高的要求。首先需要適應(yīng)開發(fā)模式快速迭代的需求,需要能夠與DevOps流程等進(jìn)行高度的集成,通過輕量級(jí)、自動(dòng)化集成的方式實(shí)現(xiàn)開發(fā)、測試、運(yùn)維的一體化;也需要適應(yīng)部署架構(gòu)分布式、容器化的需求,提升業(yè)務(wù)服務(wù)動(dòng)態(tài)、及時(shí)、準(zhǔn)確發(fā)現(xiàn)的能力;最后,云原生的發(fā)展也帶來了更多的上下游依賴,因此也需要適應(yīng)數(shù)據(jù)來源、數(shù)據(jù)類型越來越多的需求。
可觀測性的數(shù)據(jù)基礎(chǔ)
Logs、Traces、Metrics作為可觀測性數(shù)據(jù)的三大支柱,基本可以滿足各類監(jiān)控、告警、分析、問題排查等需求。這里大致分析下這三類數(shù)據(jù)的特點(diǎn)、轉(zhuǎn)化方式以及適用場景:
Logs:作為軟件運(yùn)行狀態(tài)的載體,通過日志可以詳細(xì)解釋系統(tǒng)運(yùn)行狀態(tài)及還原業(yè)務(wù)處理的過程。常見日志類型包括運(yùn)行日志、訪問日志、交易日志、內(nèi)核日志、滿日志、錯(cuò)誤日志等。
Metrics:是指對(duì)系統(tǒng)中某一類信息的統(tǒng)計(jì)聚合,相對(duì)比較離散。一般有name、labels、time、values組成,Metrics數(shù)據(jù)量一般很小,相對(duì)成本更低,查詢的速度比較快。
Traces:是最標(biāo)準(zhǔn)的調(diào)用日志,除了定義了調(diào)用的父子關(guān)系外(一般通過TraceID、SpanID、ParentSpanID),一般還會(huì)定義操作的服務(wù)、方法、屬性、狀態(tài)、耗時(shí)等詳細(xì)信息。
三者間的轉(zhuǎn)換關(guān)系:Logs在調(diào)用鏈場景結(jié)構(gòu)化后其實(shí)可以轉(zhuǎn)變?yōu)門race,在進(jìn)行聚合、降采樣操作后會(huì)變成Metrics。
開源方案探討
目前行業(yè)上主流的可觀測開源方案,大概可以分為5個(gè)部分。
采集端:承載可觀測數(shù)據(jù)采集及一部分前置的數(shù)據(jù)處理功能。隨著云原生的發(fā)展,采集端也需要適應(yīng)時(shí)代潮流,提供對(duì)K8s采集的友好支持。常見的采集端有Filebeat、FluentD/Fluent-bIt,以及我們開源的iLogtail。
消息隊(duì)列:采集Agent往往不會(huì)直接將采集到的數(shù)據(jù)發(fā)送到存儲(chǔ)系統(tǒng),而是寫入消息隊(duì)列,起到削峰填谷的作用,避免流量洪峰導(dǎo)致存儲(chǔ)系統(tǒng)宕機(jī)。常見消息隊(duì)列為Kafka、RabbitMQ等。
計(jì)算:用于消費(fèi)消息隊(duì)列中的數(shù)據(jù),經(jīng)過處理、聚合后輸出到存儲(chǔ)系統(tǒng)。比較常見的為Flink、Logstash等。
存儲(chǔ)分析引擎:提供采集數(shù)據(jù)持久化存儲(chǔ)能力,并提供查詢分析能力。常見的存儲(chǔ)分析引擎為Elasticsearch、ClickHouse及Loki。
可視化:借助Kibana和Grafana提供采集數(shù)據(jù)的可視化能力。
另外,日志服務(wù)SLS作為一款云原生觀測與分析平臺(tái),為Log、Metric、Trace等數(shù)據(jù)提供大規(guī)模、低成本、實(shí)時(shí)的平臺(tái)化服務(wù)。SLS一站式提供數(shù)據(jù)采集、加工、查詢與分析、可視化、告警、消費(fèi)與投遞等功能,用戶可以基于SLS快速構(gòu)建一套完整的可觀測平臺(tái)。iLogtail企業(yè)版作為SLS官方標(biāo)配的采集器,承載了業(yè)務(wù)數(shù)據(jù)采集的職責(zé),而iLogtail社區(qū)版正是從企業(yè)版發(fā)展而來的,功能及性能自然也繼承了企業(yè)版的絕大部分能力。
iLogtail發(fā)展歷程
iLogtail的前身源自阿里云的神農(nóng)項(xiàng)目,自從2013年正式孵化以來,iLogtail始終在不斷演進(jìn)。
誕生初期,面對(duì)阿里云自身和早期客戶運(yùn)維和可觀測性需求,iLogtail主要解決的是從單機(jī)、小規(guī)模集群到大規(guī)模的運(yùn)維監(jiān)控挑戰(zhàn),此時(shí)的iLogtail已經(jīng)具備了基本的文件發(fā)現(xiàn)和輪轉(zhuǎn)處理能力,可以實(shí)現(xiàn)日志、監(jiān)控實(shí)時(shí)采集,抓取毫秒級(jí)延遲,單核處理能力約為10M/s。通過Web前端可支持中心化配置文件自動(dòng)下發(fā),支持3W+部署規(guī)模,上千采集配置項(xiàng),實(shí)現(xiàn)日10TB數(shù)據(jù)的高效采集。
2015年,阿里巴巴開始推進(jìn)集團(tuán)和螞蟻金服業(yè)務(wù)上云,面對(duì)近千個(gè)團(tuán)隊(duì)、數(shù)百萬終端、以及雙11、雙12等超大流量數(shù)據(jù)采集的挑戰(zhàn),iLogtail在功能、性能、穩(wěn)定性和多租戶支持方面都需要進(jìn)行巨大的改進(jìn)。至2017年前后,iLogtail已經(jīng)具備了正則、分隔符、JSON等多個(gè)格式日志的解析能力,支持多種日志編碼方式,支持?jǐn)?shù)據(jù)過濾、脫敏等高級(jí)處理能力,單核處理能力極簡模式下提升到100M/s,正則、分隔符、JSON等方式20M/s+。采集可靠性方面,增加文件發(fā)現(xiàn)Polling方式兜底、輪轉(zhuǎn)隊(duì)列順序保證、日志清理丟失保護(hù)、CheckPoint增強(qiáng);進(jìn)程可靠性方面,增加異常自動(dòng)恢復(fù)、Crash自動(dòng)上報(bào)、守護(hù)進(jìn)程等。通過全流程多租戶隔離、多級(jí)高低水位隊(duì)列、配置級(jí)/進(jìn)程級(jí)流量控制、臨時(shí)降級(jí)等機(jī)制,支持百萬+部署規(guī)模,千級(jí)別租戶,10萬+采集配置項(xiàng),實(shí)現(xiàn)日PB級(jí)數(shù)據(jù)的穩(wěn)定采集。
隨著阿里推進(jìn)核心業(yè)務(wù)全面上云,以及iLogtail所屬日志服務(wù)(SLS)正式在阿里云上商業(yè)化,iLogtail開始全面擁抱云原生。面對(duì)多元的云上環(huán)境、迅速發(fā)展的開源生態(tài)和大量涌入的行業(yè)客戶需求,iLogtail的發(fā)展的重心轉(zhuǎn)移到解決如何適應(yīng)云原生、如何兼容開源協(xié)議和如何去處理碎片化需求等問題上。2018年iLogtail正式支持docker容器采集,2019年支持containerd容器采集,2020年全面升級(jí)Metric采集,2021年增加Trace支持。通過全面支持容器化、K8S Operator管控和可擴(kuò)展插件系統(tǒng),iLogtail支持千萬部署規(guī)模,數(shù)萬內(nèi)外部客戶,百萬+采集配置項(xiàng),實(shí)現(xiàn)日數(shù)十PB數(shù)據(jù)的穩(wěn)定采集。2021年11月iLogtail邁出了開源的第一步,將Golang插件代碼開源。自開源以來,吸引了數(shù)百名開發(fā)者的關(guān)注,并且也有不少開發(fā)者貢獻(xiàn)了processor跟flusher插件。2022年6月C++核心代碼也正式開源了,自此開發(fā)者可以基于該版本構(gòu)建完整的云原生可觀測數(shù)據(jù)采集方案。
iLogtail核心優(yōu)勢
核心優(yōu)勢 -- 輕量、高效、穩(wěn)定、可靠
輕量
可觀測數(shù)據(jù)采集Agent作為一個(gè)基礎(chǔ)設(shè)施,往往需要每臺(tái)機(jī)器都有部署,比如目前阿里內(nèi)部有數(shù)百萬的裝機(jī)量,每天會(huì)產(chǎn)生幾十PB的可觀測數(shù)據(jù)。因此不管是內(nèi)存還是CPU的一點(diǎn)點(diǎn)節(jié)省,都能帶來比較大的成本收益。特別是,K8s Sidecar模式對(duì)于內(nèi)存的要求更加苛刻,因?yàn)閕Logtail與業(yè)務(wù)容器共同部署,iLogtail部署量會(huì)隨業(yè)務(wù)規(guī)模擴(kuò)大而增長。從設(shè)計(jì)初期,我們就比較重視iLogtail的資源占用問題,選擇了主體部分C++、插件部分Golang實(shí)現(xiàn),并且通過一些技術(shù)細(xì)節(jié)(詳見下文)的優(yōu)化,使得內(nèi)存還是CPU相對(duì)于同類Agent都有較大的優(yōu)勢。
高效采集
對(duì)于日志采集,比較常見的手段是輪詢機(jī)制,這是一種主動(dòng)探測的收集方式,通過定期檢測日志文件有無更新來觸發(fā)日志采集;相應(yīng)的也存在一種被動(dòng)監(jiān)聽的事件模式,依賴于操作系統(tǒng)的事件通知(對(duì)操作系統(tǒng)有一定的要求),常見的事件通知機(jī)制是Linux 2.6.13內(nèi)核版本引入的inotify機(jī)制。輪詢相對(duì)事件通知的實(shí)現(xiàn)復(fù)雜度要低很多、天然支持跨平臺(tái)而且對(duì)于系統(tǒng)限制性不高;但輪詢的采集延遲以及資源消耗較高,而且在文件規(guī)模較大時(shí)輪詢一次的時(shí)間較長,比較容易發(fā)生采集延遲。
為了同時(shí)兼顧采集效率以及跨平臺(tái)的支持,iLogtail采用了輪詢(polling)與事件(inotify)并存的模式進(jìn)行日志采集,既借助了inotify的低延遲與低性能消耗的特點(diǎn),也通過輪詢的方式兼顧了運(yùn)行環(huán)境的全面性。
iLogtail內(nèi)部以事件的方式觸發(fā)日志讀取行為。其中,polling和inotify作為兩個(gè)獨(dú)立模塊,分別將各自產(chǎn)生的Create/Modify/Delete事件,存入Polling Event Queue和Inotify Event Queue中。
輪詢模塊由DirFilePolling和ModifyPolling兩個(gè)線程組成,DirFilePolling負(fù)責(zé)根據(jù)用戶配置定期遍歷文件夾,將符合日志采集配置的文件加入到modify cache中;ModifyPolling負(fù)責(zé)定期掃描modify cache中文件狀態(tài),對(duì)比上一次狀態(tài)(Dev、Inode、Modify Time、Size),若發(fā)現(xiàn)更新則生成modify event。
inotify屬于事件監(jiān)聽方式,根據(jù)用戶配置監(jiān)聽對(duì)應(yīng)的目錄以及子目錄,當(dāng)監(jiān)聽目錄存在變化,內(nèi)核會(huì)產(chǎn)生相應(yīng)的通知事件。
由Event Handler線程負(fù)責(zé)將兩個(gè)事件隊(duì)列合并到內(nèi)部的Event Queue中,并處理相應(yīng)的Create/Modify/Delete事件,進(jìn)而進(jìn)行實(shí)際的日志采集。
此外,我們也通過一些技術(shù)手段,保證了polling、inotify兩種機(jī)制的高效配合,整體近一步提升了iLogtail運(yùn)行效率。
事件合并:為避免輪詢事件和inotify事件多次觸發(fā)事件處理行為,iLogtail在事件處理之前將重復(fù)的輪詢/inotify事件進(jìn)行合并,減少無效的事件處理行為;
輪詢自動(dòng)降級(jí):如果在系統(tǒng)支持且資源足夠的場景下,inotify無論從延遲和性能消耗都要優(yōu)于輪詢,因此當(dāng)某個(gè)目錄inotify可以正常工作時(shí),則該目錄的輪詢進(jìn)行自動(dòng)降級(jí),輪詢間隔大幅降低到對(duì)CPU基本無影響的程度。
日志順序采集
日志順序性采集是日志采集需要提供的基本功能,也是一個(gè)采集的難點(diǎn),需要考慮如下場景:
適應(yīng)不同的日志輪轉(zhuǎn)(rotate)機(jī)制:日志輪轉(zhuǎn)是指當(dāng)日志滿足一定條件(時(shí)間或文件大小)時(shí),需要進(jìn)行重命名、壓縮等操作,之后創(chuàng)建新的日志文件繼續(xù)寫入。另外,不同使用日志庫輪轉(zhuǎn)文件的格式不盡相同,有的時(shí)間結(jié)尾,有的數(shù)字結(jié)尾等。
適應(yīng)不同的采集路徑配置方式:優(yōu)秀的日志采集agent并不應(yīng)該強(qiáng)制限制用戶的配置方式,尤其在指定日志采集文件名時(shí),需要適應(yīng)不同用戶的配置習(xí)慣。不管是精準(zhǔn)路徑匹配,還是模糊匹配,例如*.log或*.log*,都不能出現(xiàn)日志輪轉(zhuǎn)時(shí)多收集或者少收集的情況。
為了實(shí)現(xiàn)日志文件的順序采集,首先需要定義好文件的唯一標(biāo)識(shí)。我們知道在文件系統(tǒng)中,可以通過dev+inode的組合唯一標(biāo)識(shí)一個(gè)文件。文件的move操作雖然可以改變文件名,但并不涉及文件的刪除創(chuàng)建,dev+inode并不會(huì)變化,因此通過dev+inode可以非常方便的判斷一個(gè)文件是否發(fā)生了輪轉(zhuǎn)。但是dev+inode只能保證同一時(shí)刻文件的唯一性,當(dāng)涉及文件快速刪除創(chuàng)建的時(shí)候,前后兩個(gè)文件的dev+inode很可能是相同的。因此純粹通過dev+inode判斷輪轉(zhuǎn)并不可行,iLogtail引入了文件簽名(signature)的概念,使用日志文件的前1024字節(jié)的hash作為文件的signature,只有當(dāng)dev+inode+signature一致的情況下才會(huì)認(rèn)為該文件是輪轉(zhuǎn)的文件。此外,iLogtail內(nèi)部也引入了文件輪轉(zhuǎn)隊(duì)列,保證了文件的順序采集。
采集可靠性
iLogtail作為一個(gè)可觀測數(shù)據(jù)基礎(chǔ)采集組件,除了資源、性能外,可靠性也是一項(xiàng)關(guān)鍵指標(biāo)。對(duì)于一些異常場景,iLogtail也有充分的設(shè)計(jì)考慮,保證了在網(wǎng)絡(luò)異常、流量突增、進(jìn)程重啟等場景下依然能夠完成正常的采集任務(wù)。
日志處理阻塞
問題描述:iLogtail需要大量部署在不同的業(yè)務(wù)機(jī)器上,運(yùn)行環(huán)境是復(fù)雜多變的,應(yīng)用日志burst寫入、網(wǎng)絡(luò)暫時(shí)性阻塞、服務(wù)端Quota不足、CPU/磁盤負(fù)載較高等情況在所難免,當(dāng)這些情況發(fā)生時(shí),很容易造成日志采集進(jìn)度落后于日志產(chǎn)生進(jìn)度,此時(shí),iLogtail需要在合理的資源限制下盡可能保留住這些日志,等待網(wǎng)絡(luò)恢復(fù)或系統(tǒng)負(fù)載下降時(shí)將這些日志采集到服務(wù)器,并且保證日志采集順序不會(huì)因?yàn)椴杉枞靵y。
解決思路:
iLogtail內(nèi)部通過保持輪轉(zhuǎn)日志file descriptor的打開狀態(tài)來防止日志采集阻塞時(shí)未采集完成的日志文件被file system回收(在文件輪轉(zhuǎn)隊(duì)列中的file descriptor一直保持打開狀態(tài),保證文件引用計(jì)數(shù)至少為1)。同時(shí),通過文件輪轉(zhuǎn)隊(duì)列的順序讀取保證日志采集順序與日志產(chǎn)生順序一致。
若日志采集進(jìn)度長時(shí)間持續(xù)落后于日志產(chǎn)生進(jìn)度,完全的不回收機(jī)制,則很有可能出現(xiàn)文件輪轉(zhuǎn)隊(duì)列會(huì)無限增長的情況,進(jìn)而導(dǎo)致磁盤被寫爆,因此iLogtail內(nèi)部對(duì)于文件輪轉(zhuǎn)隊(duì)列設(shè)置了上限,當(dāng)size超過上限時(shí)禁止后續(xù)Reader的創(chuàng)建,只有這種持續(xù)的極端情況出現(xiàn)時(shí),才會(huì)出現(xiàn)丟日志采集的情況。當(dāng)然,在問題被放大之前,iLogtail也會(huì)通過報(bào)警的方式,通知用戶及時(shí)介入修復(fù)問題。
采集配置更新/進(jìn)程升級(jí)
問題描述:配置更新或進(jìn)行升級(jí)時(shí)需要中斷采集并重新初始化采集上下文,iLogtail需要保證在配置更新/進(jìn)程升級(jí)時(shí),即使日志發(fā)生輪轉(zhuǎn)也不會(huì)丟失日志。
解決思路:
為保證配置更新/升級(jí)過程中日志數(shù)據(jù)不丟失,在iLogtail在配置重新加載前或進(jìn)程主動(dòng)退出前,會(huì)將當(dāng)前所有采集的狀態(tài)保存到本地的checkpoint文件中;當(dāng)新配置應(yīng)用/進(jìn)程啟動(dòng)后,會(huì)加載上一次保存的checkpoint,并通過checkpoint恢復(fù)之前的采集狀態(tài)。
然而在老版本checkpoint保存完畢到新版本采集Reader創(chuàng)建完成的時(shí)間段內(nèi),很有可能出現(xiàn)日志輪轉(zhuǎn)的情況,因此新版本在加載checkpoint時(shí),會(huì)檢查對(duì)應(yīng)checkpoint的文件名、dev+inode有無變化。
若文件名與dev+inode未變且signature未變,則直接根據(jù)該checkpoint創(chuàng)建Reader即可。
若文件名與dev+inode變化則從當(dāng)前目錄查找對(duì)應(yīng)的dev+inode,若查找到則對(duì)比signature是否變化。若signature未變則認(rèn)為是文件輪轉(zhuǎn),根據(jù)新文件名創(chuàng)建Reader;若signature變化則認(rèn)為是該文件被刪除后重新創(chuàng)建,忽略該checkpoint。
進(jìn)程crash、宕機(jī)等異常情況
問題描述:在進(jìn)程crash或宕機(jī)時(shí),iLogtail需要提供容錯(cuò)機(jī)制,不丟數(shù)據(jù),盡可能的少重復(fù)采集。解決思路:
進(jìn)程crash或宕機(jī)沒有退出前記錄checkpoint的時(shí)機(jī),因此iLogtail還會(huì)定期將采集進(jìn)度dump到本地:除了恢復(fù)正常日志文件狀態(tài)外,還會(huì)查找輪轉(zhuǎn)后的日志,盡可能降低日志丟失風(fēng)險(xiǎn)。
核心優(yōu)勢 -- 性能及隔離性
無鎖化設(shè)計(jì)及時(shí)間片調(diào)度
業(yè)界主流的Agent對(duì)于每個(gè)配置會(huì)分配獨(dú)立的線程/go runtime來進(jìn)行數(shù)據(jù)讀取,而iLogtail數(shù)據(jù)的讀取只配置了一個(gè)線程,主要原因是:
數(shù)據(jù)讀取的瓶頸并不在于計(jì)算而是磁盤,單線程足以完成所有配置的事件處理以及數(shù)據(jù)讀取。
單線程的另一個(gè)優(yōu)勢是可以使事件處理和數(shù)據(jù)讀取在無鎖環(huán)境下運(yùn)行,相對(duì)多線程處理性價(jià)比較高。
iLogtail數(shù)據(jù)讀取線程可完成每秒200MB以上的數(shù)據(jù)讀取(SSD速率可以更高)。
但單線程的情況下會(huì)存在多個(gè)配置間資源分配不均的問題,如果使用簡單的FCFS( First Come First Serve)方式,一旦一個(gè)寫入速度極高的文件占據(jù)了處理單元,它就一直運(yùn)行下去,直到該文件被處理完成并主動(dòng)釋放資源,此方式很有可能造成其他采集的文件被餓死。
因此我們采用了基于時(shí)間片的采集調(diào)度方案,使各個(gè)配置間盡可能公平的調(diào)度,防止采集文件餓死的現(xiàn)象發(fā)生。iLogtail將Polling以及Inotify事件合并到無鎖的事件隊(duì)列中,每個(gè)文件的修改事件會(huì)觸發(fā)日志讀取。每次讀取從上次記錄的偏移位置開始,并嘗試在固定的時(shí)間片內(nèi)將文讀取到EOF處。如果時(shí)間片內(nèi)讀取完畢,則表示事件處理完成,刪除事件;否則,將事件重新Push到隊(duì)列尾部,等待下一次調(diào)用。
通過以上設(shè)計(jì),保證了iLogtail可以高性能的進(jìn)行數(shù)據(jù)采集。對(duì)比數(shù)據(jù)可以詳見:https://developer.aliyun.com/article/850614
多租戶隔離
基于時(shí)間片的采集調(diào)度保證了各個(gè)配置的日志在數(shù)據(jù)讀取時(shí)得到公平的調(diào)度,滿足了多租戶隔離中基本的公平性,但對(duì)于隔離性并未起到幫助作用。例如當(dāng)部分采集配置因處理復(fù)雜或網(wǎng)絡(luò)異常等原因阻塞時(shí),阻塞配置依然會(huì)進(jìn)行處理,最終會(huì)導(dǎo)致隊(duì)列到達(dá)上限而阻塞數(shù)據(jù)讀取線程,影響其他正常配置。為此我們設(shè)計(jì)了一套多級(jí)高低水位反饋隊(duì)列用以在不同采集配置間實(shí)現(xiàn)讀取、解析、發(fā)送各個(gè)步驟的有效的協(xié)調(diào),為了更好的實(shí)現(xiàn)不同配置間隔離性,所以iLogtail會(huì)為每個(gè)配置創(chuàng)建一組隊(duì)列。
多級(jí):iLogtail從采集到輸出總體要經(jīng)過讀取->解析->發(fā)送三個(gè)步驟,iLogtail在相鄰步驟間分別設(shè)置一個(gè)隊(duì)列。
高低水位:每個(gè)隊(duì)列設(shè)置高低兩個(gè)水位,高水位時(shí)停止非緊急數(shù)據(jù)寫入,只有恢復(fù)到低水位時(shí)才允許再次寫入。
反饋:在準(zhǔn)備讀取當(dāng)前隊(duì)列數(shù)據(jù)時(shí)會(huì)同步檢查下一級(jí)隊(duì)列狀態(tài),下一級(jí)隊(duì)列高水位則跳過讀取;當(dāng)前隊(duì)列從高水位消費(fèi)到低水位時(shí),異步通知關(guān)聯(lián)的前一級(jí)隊(duì)列。
極端場景處理
對(duì)于一些阻塞場景的可靠性也需要考慮,主要包括事件處理、數(shù)據(jù)讀取邏輯以及數(shù)據(jù)發(fā)送控制三個(gè)方面:
事件處理與數(shù)據(jù)讀取無關(guān),即使讀取關(guān)聯(lián)的隊(duì)列滿也照常處理,這里的處理主要是更新文件meta、將輪轉(zhuǎn)文件放入輪轉(zhuǎn)隊(duì)列,可保證在配置阻塞的情況下,即使文件輪轉(zhuǎn)也不會(huì)丟失數(shù)據(jù)。
當(dāng)配置關(guān)聯(lián)的解析隊(duì)列滿時(shí),如果將事件重新放回隊(duì)列尾,則會(huì)造成較多的無效調(diào)度,使CPU空轉(zhuǎn)。因此iLogtail在遇到解析隊(duì)列滿時(shí),將該事件放到一個(gè)專門的blocked隊(duì)列中,當(dāng)解析隊(duì)列異步反饋時(shí)重新將blocked隊(duì)列中的數(shù)據(jù)放回事件隊(duì)列。
Sender中每個(gè)配置的隊(duì)列關(guān)聯(lián)一個(gè)SenderInfo,SenderInfo中記錄該配置當(dāng)前網(wǎng)絡(luò)是否正常、Quota是否正常以及最大允許的發(fā)送速率。每次Sender會(huì)根據(jù)SenderInfo中的狀從隊(duì)列中取數(shù)據(jù),這里包括:網(wǎng)絡(luò)失敗重試、Quota超限重試、狀態(tài)更新、流控等邏輯。
核心優(yōu)勢 -- 插件化擴(kuò)展能力
iLogtail進(jìn)程由兩部分組成,一是C++編寫的主體二進(jìn)制進(jìn)程,提供了管控、文件采集、C++加速處理的功能;二是Golang編寫的插件部分,通過插件系統(tǒng)實(shí)現(xiàn)了處理能力的擴(kuò)展以及更豐富的上下游生態(tài)支持。
上下游生態(tài):通過插件系統(tǒng)的擴(kuò)展,目前iLogtail已經(jīng)支持了眾多數(shù)據(jù)源的接入,數(shù)據(jù)源類型覆蓋Log、Metric、Trace,數(shù)據(jù)源除了文件的采集,還包括了標(biāo)準(zhǔn)協(xié)議的支持,例如HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。數(shù)據(jù)輸出生態(tài)也從SLS逐步擴(kuò)展到Kafka、gPRC等,未來也會(huì)支持ClickHouse、ElasticSearch等。
處理能力擴(kuò)展:iLogtail采用PipeLine的設(shè)計(jì),通過Input插件采集到數(shù)據(jù),會(huì)經(jīng)過采集配置中設(shè)定的Processor處理,之后經(jīng)過Aggregator插件打包,最終通過Flusher發(fā)送到日志存儲(chǔ)系統(tǒng)。數(shù)據(jù)處理環(huán)境包含數(shù)據(jù)切分、字段提取、過濾、數(shù)據(jù)增強(qiáng)等環(huán)節(jié),所有插件可以自由組合。此外,針對(duì)于正則、Json、分隔符等特定格式,iLogtail還提供了C++加速能力。
快速迭代:開發(fā)者也可以根據(jù)自己的需求,定制開發(fā)相應(yīng)的插件。因?yàn)槊總(gè)插件相互獨(dú)立,所以開發(fā)者只需要按照接口規(guī)范開發(fā)即可,入手門檻較低。以Processor插件接口為例,只需要實(shí)現(xiàn)以下接口,即可快速提供一個(gè)處理插件。
復(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)域的標(biāo)準(zhǔn),Kubernetes(K8s)應(yīng)用的場景越來越廣泛,iLogtail 在K8s下也提供了完備的采集能力。
部署模式
在Kubernetes場景下,iLogtail主要常用的有3種工作模式:
DaemonSet方式
模式:在K8s的每個(gè)node上部署一個(gè)iLogtail,由該iLogtail采集節(jié)點(diǎn)上所有容器的日志到日志系統(tǒng)。
優(yōu)點(diǎn):運(yùn)維簡單、資源占用少、支持采集容器的標(biāo)準(zhǔn)輸出和文本文件、配置方式靈活。
缺點(diǎn):iLogtail需要采集節(jié)點(diǎn)上所有容器的日志,各個(gè)容器之間的隔離性較弱,且對(duì)于業(yè)務(wù)超級(jí)多的集群可能存在一定的性能瓶頸。
Sidecar方式:
模式:一個(gè)POD中伴隨業(yè)務(wù)容器運(yùn)行一個(gè)iLogtail容器,用于采集該P(yáng)OD中業(yè)務(wù)容器產(chǎn)生的日志。
優(yōu)點(diǎn):Sidecar方式為每個(gè)需要采集日志的容器創(chuàng)建一個(gè)Sidecar容器,多租戶隔離性好、性能好。
缺點(diǎn):資源占用較多。
Deployment方式:
模式:當(dāng)業(yè)務(wù)容器用PVC掛載日志目錄或者需要全局連接API Server獲取K8s元數(shù)據(jù)等場景,可以選擇在集群中部署一個(gè)單副本的iLogtail Deployment進(jìn)行數(shù)據(jù)采集。
采集原理
自K8s問世以來,docker運(yùn)行時(shí)一直是主流,但是隨著K8s將dockershim移除,K8s官方推薦優(yōu)先選擇containerd 或 CRI-O作為容器運(yùn)行時(shí)。docker份額目前雖然還是主流但是已經(jīng)在呈逐年下降的趨勢,contailerd、cri-o地位逐年都在快速上升。因此,從K8s支持全面性上,iLogtail需要支持主流的運(yùn)行時(shí),目前已經(jīng)支持Docker和Containerd兩種容器引擎的數(shù)據(jù)采集。K8s提供了強(qiáng)大的運(yùn)維部署、彈性伸縮、故障恢復(fù)能力,極大地便利了分布式系統(tǒng)的開發(fā)和管理,然而這也帶來了可觀測數(shù)據(jù)采集難度的增大。特別是一些短Job場景,比如一些機(jī)器學(xué)習(xí)的訓(xùn)練任務(wù),生命周期只有幾分鐘甚至幾秒,如何快速準(zhǔn)確地發(fā)現(xiàn)所需要采集的容器至關(guān)重要。
容器自動(dòng)發(fā)現(xiàn)與釋放
iLogtail通過訪問位于宿主機(jī)上容器運(yùn)行時(shí)(Docker Engine/ContainerD)的sock獲取容器信息。
通過監(jiān)聽Docker Event及增量獲取機(jī)制,及時(shí)感知容器新增與釋放。
容器上下文信息獲取
容器層級(jí)信息:容器名、ID、掛載點(diǎn)、環(huán)境變量、Label
K8s層級(jí)信息:Pod、命名空間、Labels。
容器過濾及隔離性:基于容器上下文信息,提供采集容器過濾能力,可以將不同采集配置應(yīng)用到不同的采集容器上,既可以保證采集的隔離性,也可以減少不必要的資源浪費(fèi)。
元信息關(guān)聯(lián):基于容器上下文信息和容器環(huán)境變量,提供在日志中富化K8s元信息的能力。
采集路徑發(fā)現(xiàn)
標(biāo)準(zhǔn)輸出:iLogtail可以根據(jù)容器元信息自動(dòng)識(shí)別不同運(yùn)行時(shí)的標(biāo)準(zhǔn)輸出格式和日志路徑,不需要額外手動(dòng)配置。
容器內(nèi)文件:對(duì)于overlay、overlay2的存儲(chǔ)驅(qū)動(dòng),iLogtail可以根據(jù)日志類型及容器運(yùn)行時(shí)自動(dòng)拼接出采集路徑,簡單高效。
此外,對(duì)于CICD自動(dòng)化部署和運(yùn)維程度要求較高的用戶,iLogtail還提供了K8s原生支持,支持通過CRD的方式進(jìn)行采集配置管理。目前該功能僅企業(yè)版可用,后續(xù)會(huì)逐步開源。該方案中,iLogtail K8s新增了一個(gè)CustomResourceDefinition擴(kuò)展,名為AliyunLogConfig。同時(shí)開發(fā)了alibaba-log-controller用于監(jiān)聽AliyunLogConfig事件并自動(dòng)創(chuàng)建iLogtail的采集配置,進(jìn)而完成日志采集工作。
企業(yè)版與社區(qū)版
差異比較
iLogtail開源后,目前會(huì)有兩個(gè)版本分支。
企業(yè)版:可以從阿里云SLS官方下載到。主要服務(wù)于SLS。
社區(qū)版:從GitHub倉庫,release頁下載。
iLogtail開源,秉承技術(shù)共享與開發(fā)者共建的原則,所以核心功能是完全開源的,因此可以認(rèn)為在核心采集能力上(包括采集處理功能、性能、可靠性等)與企業(yè)版是完全對(duì)標(biāo)的。企業(yè)版相對(duì)于社區(qū)版的優(yōu)勢主要在于阿里云基礎(chǔ)能力的集成上。
作為阿里云SLS官方標(biāo)配采集器,與SLS無縫集成
SLS平臺(tái)為iLogtail提供了強(qiáng)大的管控能力,及豐富的API支持。
SLS提供了對(duì)于Log、Metric、Trace的統(tǒng)一存儲(chǔ)分析能力,使用iLogtail企業(yè)版將數(shù)據(jù)采集到SLS,可以更好的構(gòu)建各類上層應(yīng)用。借助SLS可以實(shí)現(xiàn)日志上下文預(yù)覽、Exactly Once等高級(jí)特性。
借助SLS平臺(tái),可以實(shí)現(xiàn)第三方Agent的管控能力。例如,未來SLS也會(huì)跟DeepFlow進(jìn)行深度集成。
SLS作為可觀測平臺(tái),既可以承載可觀測數(shù)據(jù)存儲(chǔ)分析的功能,也可以承載流量管道的作用,可以簡化架構(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ù)加持
自動(dòng)化安裝部署能力更高,借助阿里云的運(yùn)維服務(wù),可以實(shí)現(xiàn)iLogtail批量自動(dòng)安裝。
與阿里云ECS、ACK、ASK、EMR等高度集成,可以一鍵安裝部署,采集數(shù)據(jù)可以快速接入,內(nèi)置分析。
企業(yè)版服務(wù)上的保證
SLS官方提供企業(yè)應(yīng)用場景下最全最及時(shí)的文檔/最佳實(shí)踐支持
及時(shí)的專家服務(wù)(工單、群支持)與需求承接。
大規(guī)模/復(fù)雜場景專業(yè)化支持:比如K8s短job,單節(jié)點(diǎn)大流量日志、大規(guī)模采集配置等。
基于SLS的云原生可觀測平臺(tái)
SLS提供了對(duì)于Log、Metric、Trace的統(tǒng)一存儲(chǔ)分析能力,并且也可以承載流量管道作用,具備強(qiáng)大的數(shù)據(jù)加工能力,基于SLS可以快速構(gòu)建出一套云原生可觀測平臺(tái)。智能告警中樞、智能算法服務(wù)近一步增強(qiáng)了該平臺(tái)的智能化水平。用戶可以基于此平臺(tái),便捷高效的構(gòu)建各類ITOps、DevOps、SecOps、BusinessOps上層應(yīng)用。iLogtail企業(yè)版作為SLS官方標(biāo)配官方標(biāo)配采集器,在SLS數(shù)據(jù)接入領(lǐng)域充當(dāng)著排頭兵的指責(zé),承載了大量的接入流量。
開源社區(qū)展望
技術(shù)共享一直是iLogtail秉承的理念,我們期望和歡迎更多開發(fā)者參與共建。我們希望跟開發(fā)者一起,將iLogtail的上下游生態(tài)建的更豐富。為了提升開發(fā)者的體驗(yàn),我們也會(huì)持續(xù)的改善iLogtail核心能力跟框架能力,進(jìn)一步降低開發(fā)門檻,豐富測試體系建設(shè),為開發(fā)者提供必要的技術(shù)支持。如何高效管理采集配置一直是可觀測采集器的痛點(diǎn),為此我們也會(huì)在不久將來開源服務(wù)端全局管控方案及iLogtail監(jiān)控方案,也歡迎開發(fā)者參與共建,一起打造統(tǒng)一的管控生態(tài)。最后,OpenTelemetry作為可觀測領(lǐng)域的標(biāo)準(zhǔn),iLogtail也將積極擁抱。K8s原生體驗(yàn)也是我們追求的方向,我們也有計(jì)劃推出iLogtail Operator。
關(guān)于iLogtail
iLogtail作為阿里云SLS提供的可觀測數(shù)據(jù)采集器,可以運(yùn)行在服務(wù)器、容器、K8s、嵌入式等多種環(huán)境,支持采集數(shù)百種可觀測數(shù)據(jù)(日志、監(jiān)控、Trace、事件等),已經(jīng)有千萬級(jí)的安裝量。目前,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
文章內(nèi)容僅供閱讀,不構(gòu)成投資建議,請(qǐng)謹(jǐn)慎對(duì)待。投資者據(jù)此操作,風(fēng)險(xiǎn)自擔(dān)。
2024年的Adobe MAX 2024發(fā)布會(huì)上,Adobe推出了最新版本的Adobe Creative Cloud。
奧維云網(wǎng)(AVC)推總數(shù)據(jù)顯示,2024年1-9月明火炊具線上零售額94.2億元,同比增加3.1%,其中抖音渠道表現(xiàn)優(yōu)異,同比有14%的漲幅,傳統(tǒng)電商略有下滑,同比降低2.3%。
“以前都要去窗口辦,一套流程下來都要半個(gè)月了,現(xiàn)在方便多了!”打開“重慶公積金”微信小程序,按照提示流程提交相關(guān)材料,僅幾秒鐘,重慶市民曾某的賬戶就打進(jìn)了21600元。
華碩ProArt創(chuàng)藝27 Pro PA279CRV顯示器,憑借其優(yōu)秀的性能配置和精準(zhǔn)的色彩呈現(xiàn)能力,為您的創(chuàng)作工作帶來實(shí)質(zhì)性的幫助,雙十一期間低至2799元,性價(jià)比很高,簡直是創(chuàng)作者們的首選。
9月14日,2024全球工業(yè)互聯(lián)網(wǎng)大會(huì)——工業(yè)互聯(lián)網(wǎng)標(biāo)識(shí)解析專題論壇在沈陽成功舉辦。