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