2022年1月14日，阿裡雲用戶組（AUG）第六期活動在北京順利舉辦。阿裡雲産品經理吳華劍在現場生動講解了 SLS 理念及發展曆程，讓客戶清楚地理解了 SLS 的定位以及場景，對客戶在業務上使用日志服務有極大的幫助。本文根據現場演講整理而成。

大家好，我是吳華劍，來自阿裡雲的一位産品經理，目前負責阿裡雲 SLS 日志服務和Tablestore 表格存儲的産品管理。

我之前負責過阿裡雲 OSS 對象存儲的産品管理，相對來說，SLS不隻是被開發同學集成到系統中由“代碼”來日常使用産品的 RestFul API ，而且很多開發、運維同學也作為了最終用戶，長時間地使用 SLS 、與 SLS 發生交互。

很高興，今天我們團隊有機會在阿裡雲用戶組（AUG）的活動現場分享 SLS 産品規劃與設計的一些想法，并能和各位 SLS 的用戶進行面對面的互動讨論，收集大家的反饋。

我今天和大家主要分享的是 SLS 産品規劃的一些思路和背後的思考，以及接下來的發展方向，并與各位用戶進行互動讨論。

SLS是什麼？

SLS 是服務阿裡雲客戶、阿裡集團自用的統一的可觀測數據平台，以及一站式的ITOM Data to Insight的方案。SLS 需要支撐客戶的數據采集、加工、存儲與分析需要，應用在日志分析問題排查、業務日志運營分析等，也包括運維監控、統一告警等智能運維的場景。

當前，SLS 對内服務阿裡集團各個BU的大客戶，對外服務各類的企業客戶（包括頭部的互聯網客戶、海量的創新客戶、企業客戶上雲）。SLS 既支持單租戶EB級的存儲規模、每天PB級寫入數據量、千億級記錄秒級檢索能力，服務頭部客戶的需要。同時，SLS 也提供一站式、彈性靈活、高穩定、高性能等的可觀測解決方案，支持大量創新客戶，靈活叠代、快速創新、持續發展。

SLS 發展曆程

那SLS 産品是怎麼演進到當前的形态呢？

2012年 - 海量日志實時采集與分發

2012年，SLS 的前身是一個内部産品，設計的目标是為了滿足阿裡集團與螞蟻海量日志實時采集與分發的需求。它主要解決幾個問題：

• 海量規模的支持：海量規模的采集分發，如何支撐；
• 實時性：包括日志采集的實時性、采集進來後日志可見的實時性（馬上能夠查詢）、分發速度的實時性；
• 分發能力：怎麼樣做海量的數據管道？在那個時候，其實阿裡内部也在調研開源方案，但發現不合适我們的需求。

當時，SLS 并不是一個對外商業化的産品，主要服務内部，主要包含以下部分：

• 數據采集：agent ，以及後端的configserver等（agent的分發、配置管理、流控等）。今天大家看到的SLS 商業版agent logtail、以及開源的ilogtail 都是來源于此；
• 數據管道：包括實時消費組、離線數據投遞等；
• 日志存儲服務：後期根據内部客戶的需求，并結合阿裡雲存儲盤古的技術優勢（SLS 是在阿裡雲存儲團隊），我們也給内部客戶提供日志存儲。

雖然，是内部産品，但阿裡集團各個BU使用時，都有很高的穩定性要求。因此，我們也做了很多高可用的建設和可用性保障。

2015年 - 日志實時采集與分發

到了2015年，随着服務内部更多實際的業務需求，這個産品能力演進為——服務阿裡集團與螞蟻集團的、統一的、日志數據采集存儲分析平台。産品能力包括以下方面：

• 數據的實時采集、分發：單用戶可支持PB級/天的寫入，日志數據1秒即可見；
• 日志數據的彈性擴展&穩定&高性價比存儲：單用戶可支持EB級存儲，相比開源自建方案更高的性價比、可用性SLA 保證；
• 快速分析的能力：千億日志秒級檢索。

各種互聯網應用業務快速發展、産品快速叠代，需要一個高性價比、高性能、靈活、功能強大的業務日志、系統日志的采集存儲分析系統，滿足業務日志運營分析、日志排錯問題定位。我們發現，這些需求在阿裡雲的客戶中也是普遍存在的。

這個時候，我們就在醞釀和籌備，這個産品的商業化，以便去服務阿裡雲的客戶。經過籌備、公測等階段，2016年，SLS正式對外商業化發布了。

2019年 - 一站式的日志與監控數據平台

從商業化後一直發展到2019年，在客戶的需求驅動下，SLS 有了很大的變化，從日志存儲平台演進到一站式的日志與監控平台。主要變化有：

• 日志與Metric數據的統一存儲與分析平台：客戶需要把日志、Metric（監控）數據進行統一的存儲與分析，滿足日志分析、問題排查、指标監測、運維管理等場景；
• 更多的上下遊對接：服務客戶過程中，我們對接了幾十種數據上下遊開源生态；
• 一站式，覆蓋數據流轉與處理的生命周期：從數據采集、分發、存儲、加工、查詢分析、可視化、告警，支持客戶對于日志、 Metric等數據全周期的管理與洞察分析需要。

在這個演進的時間段，開源生态中Log、Trace、Metric等多個項目在百花齊放，但也面臨不同的數據源，需要使用不同的采集agent或協議，不同的存儲、分析系統。

開源生态中，OpenTelemetry 項目在數據的“采集協議”方面解決了“數據采集”層面的統一，但在存儲與分析系統，雖然有些項目在探索，但是這些不同數據的存儲後端還是沒統一，仍然需要多個存儲、分析系統。

2020年至今 - 一站式可觀測數據的Data to Insight平台

統一的可觀測數據平台

2020年，随着内外部客戶需求的驅動、以及技術發展的背景下，SLS 針對Log、Metic、Trace 的數據采集、存儲、分析進行了統一，兼容了可觀測數據相關開源生态。同時，SLS 也支持三方開放告警Alert信息的接入，并支持阿裡雲的雲監控數據、ActionTrail/ConfigTrail/innerTrail數據的接入。

SLS 支持各類可觀測數據的全面接入、統一存儲與關聯分析，支撐客戶基于SLS 這個數據平台，構建可觀測數據的存儲與洞察分析平台。

Data to Insight

SLS 提供了數據平台對接上下遊生态的能力，支撐客戶進行二次集成開發、自定義洞察分析。在這個基礎上，SLS 也提供了數據洞察應用“demo”，如Trace分析中心、移動應用診斷監控、全棧監控等這些應用。

這裡的應用“demo”，是指它是一個通用場景的應用，客戶可以直接拿去開箱即用，也可以基于SLS 數據平台的查詢分析與可視化能力，加上這些“demo”，去構建一個自己的可觀測運維系統。

業務挑戰與待解決的問題

如何管理一套複雜的IT系統，避免“孤島”

當今數字化業務叠代越來越快，同時技術架構也在變革。比如，多雲架構、微服務等帶來架構、叠代的靈活性，但是組件也越來越多。那我們怎麼去管理一個這麼複雜的IT系統呢？我們需要考慮，如何避免讓整個數據平台變成是一個個獨立的煙囪與孤島。

在服務客戶的過程中發現，不同場景裡，都需要解決類似的需求。

• 安全場景：很多客戶将日志用在安全事件、威脅檢測場景。方案包括日志的采集，規則引擎，觸發事件告警；
• 運營場景：客戶點擊日志采集與清洗，包括運營活動日志與抽取指标、用戶留存數據等，然後形成報表，并監測這些運營指标的異常；
• 監控場景：解決如何實時、統一地拿到Metric數據，進行日志數據管理，并通過引擎規則或機器學習能力去推測一些告警事件；
• 日志分析場景：如何去定位一些突發問題，比如進行性能診斷，需要将Trace、日志數據等關聯打通，去分析性能的一個瓶頸點。

針對這些不同的客戶場景，我們進行了需求的歸納：

• 第一，數據的準備需要統一的方案：提供數據的統一采集、清洗方案；
• 第二，數據的存儲與分析：我們怎麼樣利用分析與建模的能力，提供不同數據的統一與關聯分析能力，得到分析結果，并能夠提供多種方式來呈現。這些呈現的分析結果，如何進行彙總，形成一個處理的Action。

需要解決的問題

在面對管理“複雜的IT系統”的挑戰，我們主要解決三個問題：

• 工具碎片化：構建可觀測數據的分析系統中，我們會遇到工具太碎片化的問題。比如，不同的監控指标、日志數據的采集、存儲，需要不同的工具，整個方案的複雜性也很高；
• 接入與分析過程面臨擴展、性能、不統一的問題：這些數據不同流程的鍊接、可擴展能力、分析性能上如何提升，具備秒級大規模、實時的能力；
• 判斷與處理分析機器學習能力的應用：面對系統需要監控的對象、分析的數據越來越多的情況下，我們怎麼利用一些算法，降低複雜度、減少噪聲，解決人工規則無法覆蓋的問題，減少整個分析的過程。

總結下來，我們設計時，需要解決“系統的構建問題”與“算力 算法的問題”。

• 系統的構建問題：解決工具碎片化導緻的數據接入、流轉、分析等系統構建的複雜性與孤島問題；
• 算力 算法的問題：提供大規模、實時、智能化的分析能力。

SLS 産品功能大圖

針對這些設計目的，SLS産品大圖架構，主要分為幾個部分：

• 數據管道 - 采集與分發：海量數據的采集、加工、分發管道，也是SLS 最先服務客戶的場景。SLS 對接了各類數據源上遊系統，包括log、metric、 trace可觀測“三大支柱”的開源與雲産品數據源、以及開放告警、審計數據源；
• 數據平台-可觀測數據存儲與分析平台：SLS 提供可觀測數據統一存儲、關聯查詢分析能力，解決不同類的可觀測數據散落不同的存儲分析系統，形成數據孤島難以關聯的問題；
• ITOM支持橫向能力：面對運維場景客戶需要，SLS 提供了基于機器學習的AIOps 巡檢能力、告警管理中心。AIOps 巡檢能力，解決人工阈值規則，無法完全覆蓋的問題，通過智能巡檢發現隐患。告警管理中心，解決告警風暴降低噪聲，并支持對接三方告警，提供告警分派、升級，支持排版表等能力，支撐客戶進行告警事件的統一管理；
• 場景應用“Demo”：SLS 支持客戶不同方式的集成，從數據管道、數據存儲分析平台，或者使用開箱即用的應用模闆，如雲産品可觀測應用模闆、開發運維類應用模闆（如Trace服務、移動端診斷監控）、日志審計、成本管家等。這裡的“Demo”指的是客戶是可以參考這些應用模闆，包括其中各個報表的SQL 等，基于SLS 的上下遊生态開發對接、靈活查詢分析能力，二次開發出自己的應用，并将SLS 嵌入到企業自己的日志分析、運維管理等系統中。

接下來，我們簡單介紹下，這幾個部分的能力。

數據管道 - 采集兼容對接各類數據源，并提供海量數據實時采集、加工、分發的能力

兼容對接各類數據源系統

針對于Log、Metric、Trace、三放告警等數據源，SLS提供統一的采集能力，覆蓋各種端，兼容各種開源采集協議。其中，2021年，SLS開源了采集 Agent ilogtail。

同時，SLS 服務也提供了全球加速采集的能力，支持客戶全球化應用，高效地進行數據采集。

海量采集、加工、流轉管道

數據采集後，SLS還提供數據加工、投遞消費。

• 數據加工：客戶對數據加工清洗，比如過濾、脫敏、富化等；
• 投遞與消費：實時消費訂閱，對接Flink 等這種開源的引擎，數據投遞到OSS 數據湖等進行進一步分析等。

可觀測數據平台 - 可觀測數據的統一存儲與關聯分析

統一的可觀測存儲

SLS 可觀測數據平台的設計，其中很重要一點，就是提供統一的“可觀測存儲”，支持不同類型的可觀測數據（Log/Metric/Trace等）統一存儲在SLS。客戶不再需要針對不同的可觀測數據，去建設不同的存儲系統，使用不同的方式去查詢分析。

高效智能的關聯查詢分析

SLS 可觀測數據平台，支持查詢檢索、SQL 統計分析、PromQL、AI 算子等能力，提供高性能、智能的關聯查詢分析。

• 統一分析：通過一套系統，即可支持多種數據的檢索、統計分析需要，無需來回切換，效率更高；
• 數據關聯：支持多種可觀測數據的關聯分析，獲得更多洞察；
• 高性能：實時分析、百億級記錄秒級檢索；
• 内置算子：内置各類算子，支持自動聚類等，提升分析效率。

ITOM橫向支撐 - 智能巡檢與告警中心

AIOps智能巡檢

我們基于機器學習，提供AIOps 能力，支撐客戶構建智能運維系統。SLS 智能巡檢，對于Metric、Log等數據都可以進行智能巡檢發現隐患，解決人工設置阈值無法覆蓋的問題。同時，智能巡檢支持反饋優化，通過客戶對于巡檢結果的點擊與處理反饋，模型會自動适配客戶的數據與場景。

一站式告警中樞

剛才的讨論中有很多客戶也提到，需要解決不同系統産生的告警事件的統一管理與處理問題。2021年，SLS 也發布了一站式的智能告警中心。它是開放的告警中樞，不隻是對接SLS 中各類數據産生的告警，也可以對接阿裡雲上其他系統觸發的告警、客戶已有系統的告警（比如Zabbix 告警事件等）。

同時，SLS 告警中心提供：

• 全局監控：多告警源的全局監控；
• 告警降噪：包括去重、抑制、合并等提升處理效率；
• 動态分配：多條件、升級、分派，并結合排班表等，完成告警的動态分配。

小結

2022年，SLS 的産品更新計劃會繼續圍繞上文提及的幾塊來發展。SLS 會繼續支持客戶采用不同的方式來集成SLS ，客戶可以使用SLS 或基于SLS 開發構建自己的日志/Metric /Trace 等數據分析平台或運維、運營分析系統。（正文完）

,