2022年1月14日，阿里云用户组（AUG）第六次活动在北京成功举行。阿里云产品经理吴华剑在现场生动讲解 SLS 概念和发展过程，让客户清楚地理解 SLS 定位和场景对客户在业务中使用日志服务非常有帮助。本文是根据现场演讲组织的。 大家好，我是来自阿里云的产品经理吴华剑，目前负责阿里云 SLS 日志服务和Tablestore 表格存储的产品管理。 我以前负责阿里云 OSS 对象存储的产品管理，相对而言，SLS不仅开发学生将代码集成到系统中，日常使用产品 RestFul API ，此外，许多开发和运维学生长期使用它作为最终用户 SLS 、与 SLS 发生交互。 今天，我们的团队有机会在阿里云用户组（AUG）现场分享活动 SLS 一些产品规划设计的想法，可以和你在一起 SLS 用户进行面对面的互动讨论，收集每个人的反馈。 我今天主要和大家分享的是 SLS 产品规划的一些思路和背后的思路，以及下一个发展方向，并与用户互动讨论。
SLS 它是一个统一的可观测数据平台，服务于阿里云客户和阿里集团自用，以及一站式ITOM Data to Insight的方案。SLS 需要支持客户的数据收集、处理、存储和分析需求，应用于日志分析问题调查、业务日志运营分析等，包括运维监控、统一报警等智能运维场景。
当前，SLS 内部服务阿里集团BU大客户，为各类企业客户提供外部服务（包括互联网客户、大量创新客户、企业客户云）。SLS 支持单租户EB存储规模，每天PB级写入数据量、千亿级记录秒级检索能力，服务头部客户的需要。同时，SLS 也提供一站式、弹性灵活、高稳定、高性能等的可观测解决方案，支持大量创新客户，灵活迭代、快速创新、持续发展。
那SLS 产品是如何演变成当前形式的？
2012年，SLS 其前身是内部产品，其设计目标是满足阿里巴巴集团和蚂蚁海量日志实时收集和分发的需要。它主要解决了几个问题：
- 如何支持大规模采集分发；
- 包括日志采集的实时性、日志采集后可见的实时性(可立即查询)和分发速度的实时性；
- 如何做大量的数据管道？当时阿里也在调查开源方案，但发现不适合我们的需求。
当时，SLS 主要服务内部，主要包括以下部分：
- agent ，以及后端的configserver等（agent分发、配置管理、流程控制等)。SLS 商业版agent logtail、以及开源的ilogtail 都来自这里；
- 包括实时消费组、离线数据投递等；
- 后期根据内部客户的需求，结合阿里云存储盘古的技术优势（SLS 在阿里云存储团队)，我们还为内部客户提供日志存储。
虽然是内部产品，但阿里集团的各种产品BU在使用时，对稳定性要求很高。因此，我们也做了大量的高可用性建设和可用性保证。
到2015年，随着服务内部更实际的业务需求，该产品的能力演变为阿里巴巴集团和蚂蚁集团的统一、日志数据收集和存储分析平台。产品能力包括以下几个方面：
- 单个用户可以支持PB日志数据可，日志数据1秒即可见；
- 单个用户可以支持EB级存储比开源自建方案具有更高的性价比和可用性SLA 保证；
- 千亿日志秒级检索。
各种互联网应用业务的快速发展和产品的快速迭代需要一个具有成本效益、高性能、灵活性和强大功能的业务日志和系统日志的收集和存储分析系统，以满足业务日志运营分析和日志错误的定位。我们发现，这些需求在阿里巴巴云的客户中也很常见。 在这个时候，我们正在酝酿和准备这个产品的商业化，以便为阿里云的客户服务。2016年，经过准备等阶段，SLS对外商业化正式发布。
在客户需求的驱动下，从商业化到2019年，SLS 从日志存储平台到一站式日志和监控平台，变化很大。主要变化如下：
- 客户需要日志，Metric统一存储和分析数据，满足日志分析、问题调查、指标监控、运维管理等场景；
- 在服务客户的过程中，我们对接了上下游数据开源生态；
- 从数据采集、分发、存储、处理、查询分析、可视化、报警等方面支持客户日志， Metric全周期数据管理和洞察分析需要。
在这一演变时期，开源生态Log、Trace、Metric许多其他项目在百花齐放，但也面临着不同的数据源，需要使用不同的收集agent或协议，不同的存储和分析系统。 开源生态，OpenTelemetry 项目解决了数据采集协议中数据采集水平的统一，但在存储和分析系统中，虽然有些项目正在探索，但这些不同数据的存储后端仍然不统一，仍然需要多个存储和分析系统。
2020年，在内外客户需求和技术发展的背景下，SLS 针对Log、Metic、Trace 统一了数据采集、存储和分析，与可观测数据相关的开源生态相兼容。同时，SLS 还支持三方开放报警Alert接入信息，支持阿里云的云监控数据，ActionTrail/ConfigTrail/innerTrail接入数据。 SLS 基于各种可观测数据的全面访问、统一存储和相关分析，支持客户SLS 构建可观测数据的存储和洞察分析平台。 SLS 提供数据平台对接上下游生态的能力，支持客户进行二次集成开发和自定义洞察分析。SLS 还提供了数据洞察应用demo”，如Trace分析中心、移动应用诊断监控、全栈监控等应用。 这里的应用demo，指的是一个通用场景的应用，客户可以直接即用，也可以基于SLS 数据平台的查询分析和可视化能力，加上这些demo构建自己的可观测运维系统。
如今，数字业务迭代越来越快，技术架构也在发生变化。例如，多云架构和微服务带来了架构和迭代的灵活性，但组件越来越多。那么我们如何管理如此复杂的呢？IT系统呢？我们需要考虑如何避免将整个数据平台变成独立的烟囱和孤岛。
在服务客户的过程中，发现类似的需求需要在不同的场景中解决。
- 许多客户在安全事件和威胁检测场景中使用日志。该方案包括日志采集、规则引擎、触发事件报警；
- 客户点击日志收集和清洁，包括操作日志和提取指标、用户保留数据等，然后形成报告，监控这些操作指标的异常情况；
- 解决如何实时、统一地拿到Metric数据，日志数据管理，通过引擎规则或机器学习能力推测一些报警事件；
- 如何定位一些突发问题，如性能诊断，需要Trace、通过日志数据等关联，分析性能的瓶颈点。
对于这些不同的客户场景，我们总结了需求：
- 统一收集和清理数据；
- 如何利用分析和建模的能力，提供不同数据的统一和相关分析能力，获得分析结果，并提供多种呈现方式。如何总结这些分析结果并形成处理？Action。
面对复杂的管理IT我们主要解决系统挑战的三个问题：
- 在构建可观测数据的分析系统时，我们会遇到工具过于分散的问题。例如，不同的监控指标、日志数据的收集和存储需要不同的工具，整个方案也非常复杂；
- 如何提高这些数据不同流程的链接、可扩展性和分析性能，具有大规模、实时的秒级能力； li> 面对系统需要监控的对象、分析的数据越来越多的情况下，我们怎么利用一些算法，降低复杂度、减少噪声，解决人工规则无法覆盖的问题，减少整个分析的过程。
总结下来，我们设计时，需要解决“系统的构建问题”与“算力+算法的问题”。
- 解决工具碎片化导致的数据接入、流转、分析等系统构建的复杂性与孤岛问题；
- 提供大规模、实时、智能化的分析能力。
针对这些设计目的，SLS产品大图架构，主要分为几个部分：
- 海量数据的采集、加工、分发管道，也是SLS 最先服务客户的场景。SLS 对接了各类数据源上游系统，包括log、metric、 trace可观测“三大支柱”的开源与云产品数据源、以及开放告警、审计数据源；
- SLS 提供可观测数据统一存储、关联查询分析能力，解决不同类的可观测数据散落不同的存储分析系统，形成数据孤岛难以关联的问题；
- 面对运维场景客户需要，SLS 提供了基于机器学习的AIOps 巡检能力、告警管理中心。AIOps 巡检能力，解决人工阈值规则，无法完全覆盖的问题，通过智能巡检发现隐患。告警管理中心，解决告警风暴降低噪声，并支持对接三方告警，提供告警分派、升级，支持排版表等能力，支撑客户进行告警事件的统一管理；
- 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 算子等能力，提供高性能、智能的关联查询分析。
- 通过一套系统，即可支持多种数据的检索、统计分析需要，无需来回切换，效率更高；
- 支持多种可观测数据的关联分析，获得更多洞察；
- 实时分析、百亿级记录秒级检索；
- 内置各类算子，支持自动聚类等，提升分析效率。
我们基于机器学习，提供AIOps 能力，支撑客户构建智能运维系统。SLS 智能巡检，对于Metric、Log等数据都可以进行智能巡检发现隐患，解决人工设置阈值无法覆盖的问题。同时，智能巡检支持反馈优化，通过客户对于巡检结果的点击与处理反馈，模型会自动适配客户的数据与场景。
刚才的讨论中有很多客户也提到，需要解决不同系统产生的告警事件的统一管理与处理问题。2021年，SLS 也发布了一站式的智能告警中心。它是开放的告警中枢，不只是对接SLS 中各类数据产生的告警，也可以对接阿里云上其他系统触发的告警、客户已有系统的告警（比如Zabbix 告警事件等）。 同时，SLS 告警中心提供：
- 多告警源的全局监控；
- 包括去重、抑制、合并等提升处理效率；
- 多条件、升级、分派，并结合排班表等，完成告警的动态分配。
2022年，SLS 的产品更新计划会继续围绕上文提及的几块来发展。SLS 会继续支持客户采用不同的方式来集成SLS ，客户可以使用SLS 或基于SLS 开发构建自己的日志/Metric /Trace 等数据分析平台或运维、运营分析系统。（正文完） 若有收获，就点个赞吧！