11月23日，阿里正式開源可觀測資料採集器iLogtail。作為阿里內部可觀測資料採集的基礎設施，iLogtail承載了阿里巴巴集團、螞蟻的日誌、監控、Trace、事件等多種可觀測資料的採集工作。iLogtail執行在伺服器、容器、K8s、嵌入式等多種環境，支援採集數百種可觀測資料，目前已經有千萬級的安裝量，每天採集數十PB的可觀測資料，廣泛應用於線上監控、問題分析/定位、運營分析、安全分析等多種場景。

一 iLogtail與可觀測性

可觀測性並不是一個全新的概念，而是從IT系統中的監控、問題排查、穩定性建設、運營分析、BI、安全分析等逐漸演化而來，可觀測性相比傳統監控，最核心的演進是儘可能多的收集各類可觀測資料，來實現目標的白盒化。而iLogtail的核心定位就是可觀測資料的採集器，能夠儘可能多的採集各類可觀測性資料，助力可觀測平臺打造各種上層的應用場景。

二阿里可觀測資料採集的挑戰

對於可觀測資料的採集，有很多開源的Agent，例如Logstash、Filebeats、Fluentd、Collectd、Telegraf等。這些Agent的功能非常豐富，使用這些Agent的組合再進行一定的擴充套件，基本可以滿足內部各類資料的採集需求。但由於一些效能、穩定性、管控能力等關鍵性的挑戰無法滿足，最終我們還是選擇自研：

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能力快速追齊資料
資料採集齊全度：監控、資料分析等場景都要求資料準確度，資料準確的前提是都能及時採集到服務端，但如何在計算前確定每臺機器、每個檔案的資料都採集到了對應的時間點，需要一套非常複雜的機制去計算

基於以上的背景和挑戰下，我們從2013年開始，不斷逐漸最佳化和改進iLogtail來解決效能、穩定性、可管控等問題，並經歷了阿里多次雙十一、雙十二、春晚紅包等專案的考驗。目前iLogtail支援包括Logs、Traces、Metrics多種型別資料的統一收集，核心的特點主要如下：

支援多種Logs、Traces、Metrics資料採集，尤其對容器、Kubernetes環境支援非常友好

資料採集資源消耗極低，單核採集能力100M/s，相比同類可觀測資料採集的Agent效能好5-20倍

高穩定性，在阿里巴巴以及數萬阿里雲客戶生產中使用驗證，部署量近千萬，每天採集數十PB可觀測資料

支援外掛化擴充套件，可任意擴充資料採集、處理、聚合、傳送模組

支援配置遠端管理，支援以圖形化、SDK、K8s Operator等方式進行配置管理，可輕鬆管理百萬臺機器的資料採集

支援自監控、流量控制、資源控制、主動告警、採集統計等多種高階管控特性

三 iLogtail發展歷程

秉承著阿里人簡單的特點，iLogtail的命名也非常簡單，我們最開始期望的就是能夠有一個統一去Tail日誌的工具，所以就叫做Logtail，新增上“i”的原因主要當時使用了inotify的技術，能夠讓日誌採集的延遲控制在毫秒級，因此最後叫做iLogtail。從2013年開始研發，iLogtail整個發展歷程概括起來大致可以分為三個階段，分別是飛天5K階段、阿里集團階段和雲原生階段。

1 飛天5K階段

作為中國雲計算領域的里程碑，2013年8月15日，阿里巴巴集團正式運營伺服器規模達到5000（5K）的“飛天”叢集，成為中國第一個獨立研發擁有大規模通用計算平臺的公司，也是世界上第一個對外提供5K雲計算服務能力的公司。

飛天5K專案從2009年開始，從最開始的30臺逐漸發展到5000，不斷解決系統核心的問題，比如說規模、穩定性、運維、容災等等。而iLogtail在這一階段誕生，最開始就是要解決5000臺機器的監控、問題分析、定位的工作（如今的詞語叫做“可觀測性”）。從30到5000的躍升中，對於可觀測問題有著諸多的挑戰，包括單機瓶頸、問題複雜度、排查便捷性、管理複雜度等。

5K之前	5K（2013年）
監控指標	透過單機飛天神農來匯聚系統的狀態。只能支援1000臺內的指標匯聚。	資料在本地產生，由iLogtail統一收集到SLS服務端，包括：指標資料：Metrics（神農指標）日誌資料：Logs（飛天日誌、系統日誌等）鏈路資料：Traces（飛天Trace） SLS根據日誌處理需求提供三類處理：即時指標計算與展示（分散式版神農）索引資料提供即時查詢（Logs、Traces）資料透過匯入到ODPS（如今叫做MaxCompute）離線分析
日誌查詢	登入機器grep，或者用pssh工具批次grep。速度慢，日誌可能被清理，影響機器效能，存在誤操作/安全風險。
鏈路排查	只能透過一個JobID在全部機器grep。
離線分析	利用指令碼rsync每臺機器上的日誌，匯入到離線系統進行計算。效能差、運維管理複雜。

在5K階段，iLogtail本質上解決的是從單機、小規模叢集到大規模的運維監控挑戰，這一階段iLogtail主要的特點有：

功能：即時日誌、監控採集，日誌抓取延遲毫秒級
效能：單核處理能力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自動上報、多級守護

日誌保序採集方案原理（細節可參考《iLogtail技術分享(一) : Polling + Inotify 組合下的日誌保序採集方案》）

多租戶：支援全流程多租戶隔離、多級高低水位佇列、採集優先順序、配置級/程序級流量控制、臨時降級機制

多租戶隔離整體流程（細節可參考《iLogtail技術分享(二)：多租戶隔離技術+雙十一實戰效果》）

運維：基於集團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 Kubernetes日誌採集原理（細節可參考《Kubernetes日誌採集原理剖析》）

外掛化擴充套件：iLogtail增加外掛系統，可自由擴充套件Input、Processor、Aggregator、Flusher外掛用以實現各類自定義的功能

iLogtail外掛系統整體流程（細節可參考《iLogtail外掛系統簡介》）

規模：千萬部署規模，數萬內外部客戶，百萬+採集配置項，日採集數十PB資料

四開源背景與期待

閉源自建的軟體永遠無法緊跟時代潮流，尤其在當今雲原生的時代，我們堅信開源才是iLogtail最優的發展策略，也是釋放其最大價值的方法。iLogtail作為可觀測領域最基礎的軟體，我們將之開源，也希望能夠和開源社群一起共建，持續最佳化，爭取成為世界一流的可觀測資料採集器。對於未來iLogail的發展，我們期待：

iLogtail在效能和資源佔用上相比其他開源採集軟體具備一定優勢，相比開源軟體，在千萬部署規模、日數十PB資料的規模性下為我們減少了100TB的記憶體和每年1億的CPU核小時數。我們也希望這款採集軟體可以為更多的企業帶來資源效率的提升，實現可觀測資料採集的“共同富裕”。
目前iLogtail還只是在阿里內部以及很小一部分雲上企業（雖然有幾萬家，但是面對全球千萬的企業，這個數字還很小），面對的場景相對還較少，我們希望有更多不同行業、不同特色的公司可以使用iLogtail並對其提出更多的資料來源、處理、輸出目標的需求，豐富iLogtail支援的上下游生態。
效能、穩定性是iLogtail的最基本追求，我們也希望能夠透過開源社群，吸引更多優秀的開發者，一起共建iLogtail，持續提升這款可觀測資料採集器的效能和穩定性。

連結彙總：

1）阿里正式開源可觀測資料採集器iLogtail：https://github.com/alibaba/ilogtail

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

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

4）《Kubernetes日誌採集原理剖析》：https://developer.aliyun.com/article/806369

5）《iLogtail外掛系統簡介》：https://github.com/alibaba/ilogtail/blob/main/docs/zh/concept%26designs/Overview.md

大資料Impala教程

Impala是用於處理儲存在Hadoop叢集中的大量資料的MPP（大規模並行處理）SQL查詢引擎。它是一個用C ++和Java編寫的開源軟體。與其他Hadoop的SQL引擎相比，它提供了高效能和低延遲。Impala透過使用標準組件（如HDFS，HBase，Metastore，YARN和Sentry）將傳統分析資料庫的SQL支援和多使用者效能與Hadoop的可擴充套件性和靈活性相結合。

本課程講解了大資料分散式計算的發展及Impala的應用場景，對比Hive、MapReduce、Spark等類似框架講解了記憶體式計算原理，以及如何基於Impala構建高效能互動式SQL分析平臺。點選閱讀原文檢視詳情。

關鍵詞

問題

日誌採集

雲原生

能力

可觀測性