阿里云产品经理吴华剑：SLS 的产品功能与发展历程

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 等数据分析平台或运维、运营分析系统。（正文完）
阿里云产品经理吴华剑：SLS 的产品功能与发展历程