簡介：11月23日，阿里正式開源可觀測數據采集器iLogtail。作為阿里內部可觀測數據采集的基礎設施，iLogtail承載了阿里巴巴集團、螞蟻的日志、監控、Trace、事件等多種可觀測數據的采集工作。iLogtail運行在服務器、容器、K8s、嵌入式等多種環境，支持采集數百種可觀測數據，目前已經有千萬級的安裝量，每天采集數十PB的可觀測數據，廣泛應用於線上監控、問題分析/定位、運營分析、安全分析等多種場景。
作者 | 元乙
來源 | 阿里技術公眾號
11月23日，阿里正式開源可觀測數據采集器iLogtail。作為阿里內部可觀測數據采集的基礎設施，iLogtail承載了阿里巴巴集團、螞蟻的日志、監控、Trace、事件等多種可觀測數據的采集工作。iLogtail運行在服務器、容器、K8s、嵌入式等多種環境，支持采集數百種可觀測數據，目前已經有千萬級的安裝量，每天采集數十PB的可觀測數據，廣泛應用於線上監控、問題分析/定位、運營分析、安全分析等多種場景。
一 iLogtail與可觀測性
二 阿里可觀測數據采集的挑戰
1、資源消耗：目前阿里內部有數百萬的主機（物理機/虛擬機/容器），每天會產生幾十PB的可觀測數據，每1M的內存減少、每1M/s的性能提升對於我們的資源節省都是巨大的，帶來的成本節約可能是數百萬甚至上千萬。目前眾多開源Agent的設計更多的是偏重功能而非性能，基於現有開源Agent改造基本不可行。例如：
- 開源Agent普遍單核處理性能在2-10M/s左右，而我們希望有一個能達到100M/s的性能
- 在采集目標增加、數據量增加、采集延遲、服務端異常等情況下，開源Agent內存都會呈現爆炸式增長，而我們希望即使在各種環境下，內存也能處在較低的水位
- 開源Agent的資源消耗沒辦法控制，只能通過cgroup強行限制，最終的效果就是不斷OOM，不斷重啟，數據一直采集不上來。而我們希望在指定一個CPU、內存、流量等資源限制后，Agent能一直在這個限制范圍內正常工作
2、穩定性：穩定性是永恆的話題，數據采集的穩定性，除了保證數據本身采集的准確性外，還需要保證采集的Agent不能影響業務應用，否則帶來的影響將是災難性的。而穩定性建設，除了Agent自身的基礎穩定性外，還有很多特性目前開源的Agent還沒有提供：
- Agent自恢復：Agent遇到Critical的事件后能夠自動恢復，並且提供多個維度的自恢復能力，例如進程自身、父子進程、守護進程
- 全局的多維度監控：能夠從全局的角度監控各個不同版本、不同采集配置、不同壓力、不同地域/網絡等屬性的Agent的穩定性問題
- 問題隔離：作為Agent，無論怎樣出現問題，都需要盡可能的隔離問題，例如一個Agent上有多個采集配置，一個配置出問題，不能影響其他配置；Agent自身出現問題，不能影響機器上的應用進程的穩定性
- 回滾能力：版本更新和發布是再所難免的問題，在出現問題的時候如何快速回滾，而且保證出問題和回滾期間的數據采集還是at least once甚至是exactly once。
3、可管控：可觀測數據的應用范圍非常的廣，幾乎所有的業務、運維、BI、安全等部門都會要用，而一台機器上也會產生各種數據，同一台機器產生的數據上也會有多個部門的人要去使用，例如在2018年我們統計，平均一台虛擬機上有100多個不同類型的數據需要采集，設計10多個不同部門的人要去使用這些數據。除了這些之外，還會有其他很多企業級的特性需要支持，例如：
- 配置的遠程管理：在大規模場景下，手工登錄機器修改配置基本沒有可行性，因此需要一套配置的圖形化管理、遠程存儲、自動下發的機制，而且還要能夠區分不同的應用、不同的Region、不同的歸屬方等信息。同時因為涉及到遠程配置的動態加卸載，Agent還需要能夠保證配置Reload期間數據不丟不重
- 采集配置優先級：當一台機器上有多個采集配置在運行時，如果遇到資源不足的情況，需要區分每個不同的配置優先級，資源優先供給高優先級的配置，同時還要確保低優先級的配置不被“餓死”
- 降級與恢復能力：在阿里，大促、秒殺是家常便飯，在這種波峰期間，可能有很多不重要的應用被降級，同樣對應應用的數據也需要降級，降級后，在凌晨波峰過后，還需要有足夠的Burst能力快速追齊數據
- 數據采集齊全度：監控、數據分析等場景都要求數據准確度，數據准確的前提是都能及時采集到服務端，但如何在計算前確定每台機器、每個文件的數據都采集到了對應的時間點，需要一套非常復雜的機制去計算
- 支持多種Logs、Traces、Metrics數據采集，尤其對容器、Kubernetes環境支持非常友好
- 數據采集資源消耗極低，單核采集能力100M/s，相比同類可觀測數據采集的Agent性能好5-20倍
- 高穩定性，在阿里巴巴以及數萬阿里雲客戶生產中使用驗證，部署量近千萬，每天采集數十PB可觀測數據
- 支持插件化擴展，可任意擴充數據采集、處理、聚合、發送模塊
- 支持配置遠程管理，支持以圖形化、SDK、K8s Operator等方式進行配置管理，可輕松管理百萬台機器的數據采集
- 支持自監控、流量控制、資源控制、主動告警、采集統計等多種高級管控特性
三 iLogtail發展歷程
秉承着阿里人簡單的特點，iLogtail的命名也非常簡單，我們最開始期望的就是能夠有一個統一去Tail日志的工具，所以就叫做Logtail，添加上“i”的原因主要當時使用了inotify的技術，能夠讓日志采集的延遲控制在毫秒級，因此最后叫做iLogtail。從2013年開始研發，iLogtail整個發展歷程概括起來大致可以分為三個階段，分別是飛天5K階段、阿里集團階段和雲原生階段。
作為中國雲計算領域的里程碑，2013年8月15日，阿里巴巴集團正式運營服務器規模達到5000（5K）的“飛天”集群，成為中國第一個獨立研發擁有大規模通用計算平台的公司，也是世界上第一個對外提供5K雲計算服務能力的公司。
飛天5K項目從2009年開始，從最開始的30台逐漸發展到5000，不斷解決系統核心的問題，比如說規模、穩定性、運維、容災等等。而iLogtail在這一階段誕生，最開始就是要解決5000台機器的監控、問題分析、定位的工作（如今的詞語叫做“可觀測性”）。從30到5000的躍升中，對於可觀測問題有着諸多的挑戰，包括單機瓶頸、問題復雜度、排查便捷性、管理復雜度等。
- 功能：實時日志、監控采集，日志抓取延遲毫秒級
- 性能：單核處理能力10M/s，5000台集群平均資源占用0.5%CPU核
- 可靠性：自動監聽新文件、新文件夾，支持文件輪轉，處理網絡中斷
- 管理：遠程Web管理，配置文件自動下發
- 運維：加入集團yum源，運行狀態監控，異常自動上報
- 規模：3W+部署規模，上千采集配置項，日10TB數據
2 阿里集團階段
iLogtail在阿里雲飛天5K項目中的應用解決了日志、監控統一收集的問題，而當時阿里巴巴集團、螞蟻等還缺少一套統一、可靠的日志采集系統，因此我們開始推動iLogtail作為集團、螞蟻的日志采集基礎設施。從5K這種相對獨立的項目到全集團應用，不是簡單復制的問題，而我們要面對的是更多的部署量、更高的要求以及更多的部門：
- 百萬規模運維問題：此時整個阿里、螞蟻的物理機、虛擬機超過百萬台，我們希望只用1/3的人力就可以運維管理百萬規模的Logtail
- 更高的穩定性：iLogtail最開始采集的數據主要用於問題排查，集團廣泛的應用場景對於日志可靠性要求越來越高，例如計費計量數據、交易數據，而且還需要滿足雙十一、雙十二等超大數據流量的壓力考驗。
- 多部門、團隊：從服務5K團隊到近千個團隊，會有不同的團隊使用不同的iLogtail，而一個iLogtail也會被多個不同的團隊使用，在租戶隔離上對iLogtail是一個新的挑戰。
經過幾年時間和阿里集團、螞蟻同學的合作打磨，iLogtail在多租戶、穩定性等方面取得了非常大的進步，這一階段iLogtail主要的特點有：
- 功能：支持更多的日志格式，例如正則、分隔符、JSON等，支持多種日志編碼方式，支持數據過濾、脫敏等高級處理
- 性能：極簡模式下提升到單核100M/s，正則、分隔符、JSON等方式20M/s+
- 可靠性：采集可靠性支持Polling、輪轉隊列順序保證、日志清理保護、CheckPoint增強；進程可靠性增加Critical自恢復、Crash自動上報、多級守護
- 多租戶：支持全流程多租戶隔離、多級高低水位隊列、采集優先級、配置級/進程級流量控制、臨時降級機制
- 運維：基於集團StarAgent自動安裝與守護，異常主動通知，提供多種問題自查工具
- 規模：百萬+部署規模，千級別內部租戶，10萬+采集配置，日采集PB級數據
3 雲原生階段
隨着阿里所有IT基礎設施全面雲化，以及iLogtail所屬產品SLS（日志服務）正式在阿里雲上商業化，iLogtail開始全面擁抱雲原生。從阿里內部商業化並對外部各行各業的公司提供服務，對於iLogtail的挑戰的重心已經不是性能和可靠性，而是如何適應雲原生（容器化、K8s，適應雲上環境）、如何兼容開源協議、如何去處理碎片化需求。這一階段是iLogtail發展最快的時期，經歷了非常多重要的變革：
- 統一版本：iLogtail最開始的版本還是基於GCC4.1.2編譯，代碼還依賴飛天基座，為了能適用更多的環境，iLogtail進行了全版本的重構，基於一套代碼實現Windows/Linux、X86/Arm、服務器/嵌入式等多種環境的編譯發版
- 全面支持容器化、K8s：除了支持容器、K8s環境的日志、監控采集外，對於配置管理也進行了升級，支持通過Operator的方式進行擴展，只需要配置一個AliyunLogConfig的K8s自定義資源就可以實現日志、監控的采集
- 插件化擴展：iLogtail增加插件系統，可自由擴展Input、Processor、Aggregator、Flusher插件用以實現各類自定義的功能
iLogtail插件系統整體流程（細節可參考《iLogtail插件系統簡介》）
- 規模：千萬部署規模，數萬內外部客戶，百萬+采集配置項，日采集數十PB數據
四 開源背景與期待
閉源自建的軟件永遠無法緊跟時代潮流，尤其在當今雲原生的時代，我們堅信開源才是iLogtail最優的發展策略，也是釋放其最大價值的方法。iLogtail作為可觀測領域最基礎的軟件，我們將之開源，也希望能夠和開源社區一起共建，持續優化，爭取成為世界一流的可觀測數據采集器。對於未來iLogail的發展，我們期待：
- iLogtail在性能和資源占用上相比其他開源采集軟件具備一定優勢，相比開源軟件，在千萬部署規模、日數十PB數據的規模性下為我們減少了100TB的內存和每年1億的CPU核小時數。我們也希望這款采集軟件可以為更多的企業帶來資源效率的提升，實現可觀測數據采集的“共同富裕”。
- 目前iLogtail還只是在阿里內部以及很小一部分雲上企業（雖然有幾萬家，但是面對全球千萬的企業，這個數字還很小），面對的場景相對還較少，我們希望有更多不同行業、不同特色的公司可以使用iLogtail並對其提出更多的數據源、處理、輸出目標的需求，豐富iLogtail支持的上下游生態。
- 性能、穩定性是iLogtail的最基本追求，我們也希望能夠通過開源社區，吸引更多優秀的開發者，一起共建iLogtail，持續提升這款可觀測數據采集器的性能和穩定性。
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。