共计 5634 个字符，预计需要花费 15 分钟才能阅读完成。
简介： 作为阿里经济体基础设施的阿里云日志服务（SLS），服务了上万级的用户，每天解决 20PB 日志 /Metric/Trace 数据，为 AIOps、大数据分析、经营服务、大数据安全等场景提供撑持，解决工程师可察看性的问题。通过几年的锻炼和演进，正在向对立的可察看性中台倒退。本文分享阿里云存储团队构建 SLS 中台的背景和设计中的 Trade Off，并通过两个最佳实际介绍如何通过中台构建智能的应用程序。
笔者是飞天最早的研发人员之一，已经参加从 0 到 5000 台飞天集群和操作系统的构建。飞天是一个宏大的软件系统，既有十分多的模块，也要跑在几万台物理机上，如何让分布式软件高效地运行离不开监控、性能剖析等环节，因而在飞天研发的第一天咱们就同时开始研发飞天监控零碎“神农”。神农通过采集大量的零碎数据，帮忙咱们更好地了解零碎、软件合作复杂性背地的关系。同时神农也在随同着越来越大、越来越多海内外集群的飞天操作系统成长，撑持阿里巴巴团体和阿里云的业务。在 2015 年，经验过一番思考，咱们决定把神农形象成一个更底层的服务——SLS（日志服务，第一天次要 focus 在日志场景中），心愿通过 SLS 可能服务撑持更多的 Ops 场景，包含 AIOps（智能剖析引擎）。
一 构建可察看性中台的背景
先说说从一个工程师的角度看到的变动：对一个工程师而言，5 年前的工作是十分细分的，研发的工作就是把代码开发好。但随着互联网的倒退，业务零碎 Scope 越来越大，须要在品质、可用性和可运维性上有更高的要求。并且为了保障咱们的业务是继续改良的，必须在工作中波及到更多经营的因素，例如统计零碎拜访、留存和体验等状况。
从集体视角转化到行业视角也能发现一个趋势：在十几年前，研发的工夫会花在三个局部：翻新（编码），部署 + 上线，察看 + 剖析，并且部署 + 上线会破费大量的工夫。近几年云计算和云原生的衰亡解放了开发运维在部署、上线和环境标准化上的精力。但业务的高要求须要在各个环节中承当更大的 Scope，从多个视角来对待问题。背地就会有大量、碎片化的数据分析工作。
如果咱们把具体的数据分析工作进行拆分，能够拆解成一个简略的黑盒。黑盒的右边是数据源，左边是咱们对数据源观测判断后的口头。例如：
- 在平安场景中，平安经营工程师会采集防火墙、主机、零碎等日志、依据教训对日志进行建模，辨认其中的高危操作，生成关键性事件，零碎依据多个事件进行告警。
- 在监控和经营场景中，这个过程是相似的。无非是把数据源和建模的办法做了替换。
所以咱们能够看到，尽管各个场景角色不同，数据源不同，但在机制上咱们是能够建设一套系统性剖析框架来承载这类可察看性的需要的。
二 中台的技术挑战
构建中台的思路看起来很间接，要做这件事件有哪些挑战呢？
咱们能够从数据源、剖析和判断这三个过程来剖析：
- 第一大挑战来自于数据源接入。以监控场景为例，业界有不同的可视化、采集、剖析工具针对不同的数据源。为了能建设监控可察看性体系，须要引入大量的垂直零碎。这些零碎之间有不同的存储格局，接口不对立，有不同的软件体验，往往难以造成合力。
- 第二大挑战来自于性能与速度。数据分析的过程实际上是把专家教训（Domain Knowledge）积淀的过程，而 Ops 场景个别都是 Mission Critical 过程，因而须要十分快地剖析速度和所见即所得能力。
- 第三大挑战来自于剖析能力。在接入足够多的数据后，往往会面临监控项太多，数据量太多，线索太多等问题，咱们须要有成套的办法帮忙咱们去降维、去发现、去关联、去推理。AIOps 算法目前聚焦在这一层上。
前两个问题实质上是一个零碎问题，而前面两个问题和算法与算力相干。中台的推出能够解决第 1 和第 2 个问题。
三 阿里云 SLS，自研自用可察看性中台
2015 年咱们研发了 SLS，通过几年的锻炼和演进，正在向对立的可察看性中台倒退。SLS 向下对接各种开源的协定与数据源，向上对各种场景提供撑持能力。外围能力在于围绕可察看性的各种监控数据，提供对立的存储与计算能力，平台能够用“1、2、3、4”四个词来概括。
- “1”代表一个中台。
- “2”代表提供两种根本的存储模型：Logstore 与 MetricStore，别离面向适宜 Trace/Log 类型的日志存储（Logstore），适宜监控数据 Metric 类型的时序存储（MetricStore）。这两种存储并不是孤立的，建设在对立的存储概念上，并且能够非常灵活的互相转化。
- “3”代表三类剖析引擎：数据加工引擎（DSL）、SQL 查问剖析引擎（SQL）、智能剖析引擎（AIOps）。DSL 次要面向数据加工和与预处理场景，解决格局多样化的问题；SQL 查问剖析引擎面向存储数据提供荡涤、计算能力；而内嵌的 AIOps 能够给特定问题提供智能算法。
- “4”代表四类典型场景：例如 ITOps、DevOps、SecOps、BusinessOps 等。波及到运维、研发、经营和黑客增长等畛域。阿里团体 80% 以上相似场景都基于 SLS 来构建。
平台始终向用户提供撑持能力，兼容各种数据源与协定，撑持业务但不做业务产品。
1 存储设计
为了构建可察看性的中台，咱们先看看目前存储系统的现状。在运维畛域 AIOps 零碎的构建过程中，长期并存四种类型的存储系统，别离是：
- Hadoop/Hive：寄存历史日志，Metric 等数据，存储老本便宜，剖析能力较强，但延时较高。
- ElasticSearch：寄存须要实时拜访的 Trace，Log 信息，检索速度快，但老本较高，适宜近线的热数据，剖析能力中等。
- NoSQL：用来存储通过聚合的指标类数据，TSDB 类是 NoSQL 存储扩大，检索聚合后的指标速度快，老本较便宜，毛病是剖析能力较弱。
- Kafka：用来导入导出路由各种数据，次要存储长期数据，上下游接口丰盛，没有剖析能力。
这四类独立的存储系统较好地解决了四种不同类型的需要，但存在两大挑战：
数据流动性
数据存储后可能撑持某个场景的服务能力，但随之而来的问题就是流动性。数据存在于多个零碎中，做数据关联、比照、整合时就须要去搬数据，这往往须要破费十分多的工夫。
接口易用性
面对不同的存储对象的接口不对立，例如 Log 个别应用 ES 的 API 来包装，而 Metric 个别会用 Prometheus 协定或通过 NoSQL 接口间接调用等等。为了集成数据往往须要波及到不同的 API 与交互方式，减少了零碎的整体复杂性。
目前四种存储系统的现状导致数据应用须要较长的周期及肯定的开发量，限度了 AIOps，DataOps 等场景施展更大的作用。
2 如何形象存储
如果咱们把监控数据的生成过程做一个形象，能够发现个别会由两个过程组成：变动 + 状态。所有的事物都是一个待续变动的过程，例如数据库的一张表在某一个时刻（例如 2 点）的状态实际上是由历史上所有变动累计的后果。在监控畛域中也是一样，咱们能够通过 Log、Trace 等形式把零碎状态的变动尽可能保留（或采样）下来。例如用户在 1 小时内做了 5 次操作，咱们能够把这 5 次操作的日志或 Trace 捕获下来。当咱们须要一个状态值时（比方 2 点的零碎状态是什么），咱们能够对这些所有的操作日志做一个回放，造成某一个工夫点的一个汇总值，例如在窗口大小为 1 小时的区间内，操作 QPS 为 5。这里就是一个简略的 Log 转为 Metric 的关系，咱们能够应用其余逻辑，例如对 Log 中的 Latency 字段做一个 Avg 来取得该窗口的 Latency。
在 SLS 存储设计的过程中，咱们也遵循了这样的客观规律：
- 底层提供了一个 FIFO Binlog 队列，数据写入和读取都是程序的，以严格的写入工夫（Arrival Time）作为排序。
- 在 Binlog 之上，咱们能够筛选某些字段生成一个 Logstore，Logstore 能够认为是数据库的一个表：是带 Schema 的，至多有 EventTime 这个字段（事件产生的原始工夫），能够指定列的类型和名字。这样咱们就能够通过关键词和 SQL 检索 Logstore 中的内容。
- 除此之外，咱们能够依据需要对 Logstore 中的某些列生成多个 Metric 存储，例如依据 Host+Method+Time 构建一个以 Host+Method 作为 Instance 的监控数据存储表，从而能够依据时间段把数据捞出。
让咱们来看一个例子：以下是一个站点的拜访记录，在 1 秒内经验了 4 次访问。
time, host, method, latency, uid, status
[2020-08-10 17:00:00, Site1, UserLogin, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 25ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 1ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserLogout, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site2, UserLogin, 45ms,1002, Fail]当这些数据写入 Logstore 后，相当于写入了一张寄存日志的数据库，能够通过 SQL 对其中任意字段进行查问与剖析。例如“select count(1) as qps”，取得以后汇总的 QPS。
也能够通过预约义好一些维度，例如心愿通过 host+method 组合来构建最小监控粒度，每隔 1 秒钟取得 QPS，Latency 等数据，那咱们能够定义如下的 MetricStore，当数据写入后，可能主动依据规定生成如下后果：
[host, method, time], [qps, latency]
[site1, userLogin, 2020-08-10 17:00:00], [1, 45]
[site1, userBuy, 2020-08-10 17:00:01], [2, 15]
[site1, userLogout, 2020-08-10 17:00:01], [1, 25]通过这种形式，咱们就能够在一种存储中通过原始数据的存储、聚合造成日志与 Metric 转移。
3 计算设计
依据平时遇到的场景，咱们把监控数据的计算形象成三类问题：
- 非结构化数据如何变为结构化数据
- 面对简单零碎，是否设计一套所见即所得低门槛语言进行数据分析
- 面对海量信息，是否有降维算法来升高问题复杂度
咱们构建了三类计算方法别离来解决以上问题：
第一个问题实际上一个业务复杂度的问题，本源来自产生数据的人和应用数据的人之间的 GAP。在大部分开发流程中打日志的往往是开发者，但剖析日志的往往是运维和经营，在写日志过程中没有足够预见性导致数据无奈间接被应用。这里须要有一套低代码开发的语言来做各种各样的数据转化、分派、富化，把多个业务零碎不同格局的数据进行简化。为此咱们设计了一套面向数据加工（ETL）场景的语言（DSL)，该语言提供了 300 多个罕用算子，独裁日志格局的各种疑难杂症。
例如在原始日志中，只有一个 project_id 字段在拜访 url 参数里，ip 这个字段对应的设计咱们无奈拿到。在 SLS 的 DSL 语言中，咱们只须要写 3 行代码，从 url 中提取参数，与数据库中字段进行富化。原来看起来无用的拜访日志就立刻盘活，能够剖析出主机和使用者之间的拜访关系了。
第二个问题是一个多语言交融的问题，咱们的抉择是以 SQL 作为查问和剖析框架，在框架中融入 PromQL 及各种机器学习函数。这样就能够通过子查问 + 主查问进行嵌套，对后果进行计算并预测。
SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ... 以下就是一个简单剖析的例子：
- 先通过调用 promql 算子拿到主机每分钟的监控值
- 通过窗口函数对原始数据进行降采样，例如变为每秒的数值
- 通过外层的预测函数对查问后果进行预测
第三个问题是算法的问题，咱们内置了大量基于 AI 的巡检、预测、聚类、根因剖析等算法，能够在人工剖析和主动巡检告警中间接应用到。这些算法通过 SQL/DSL 函数向用户提供，能够在各种场景中用到。
四 中台撑持案例
SLS 在阿里团体内外有万级的用户，大量使用到 AIOps 各种数据分析场景中，这里列举两个比拟有意思的案例。
案例 1：流量解决方案
流量日志是最常见的拜访日志类型，无论是 Ingress，Nginx 还是 CDN Access Log 都能够形象成拜访日志类型，在 SLS 解决方案中：
- 采集一份原始日志保留 7 天工夫（LogStore）进行查问，更长时间备份到对象存储（OSS）。
- 通过 SLS 原生的 SQL 对日志进行数据加工 + 各维度聚合，例如依据微服务接口进行 Group By。
- 对聚合后的数据进行时序类型存储（MetricStore）。
- 通过 AIOps 巡检函数对数以千计的接口进行智能巡检，生成告警事件。
整个过程从采集到配置到运行只须要花 5 分钟，满足多样性需要。
案例 2：云老本监控与剖析
阿里云的用户每天会面临大量的账单数据，云老本核心就利用 SLS 采集、剖析、可视化与 AIOps 性能开发了一款老本管家利用，智能帮忙用户剖析云产品成本，预测老本的趋势，找到账单中异样的起因。
五 写在最初
尽管过来几年咱们没有间接做 AIOps 利用，但通过把数据能力、AI 能力中台化，反而撑持了更多的用户与场景。最初简略总结下过来两年做可察看性中台的心得体会：
AIOps = AI + DevOps/ITOps/SecOps/BusinessOps…
目前大部分人感觉 AIOps 解决的是运维的问题，实际上该套办法能够无缝地切换到各种 OPs 场景中，例如 DevOps，SecOps（Bigdata Security），以及通过 AI 来进行运维与用户增长，办法都是通用的。和 AI 所在的任何一个畛域一样，数据是基本、算力是根底、算法是外围，缺一不可。
Domain Knowledge 是 AIOps 落地要害
一个有教训的运维或分析师，对系统有粗浅的见解和建模教训。因而 AIOps 要落地，咱们必须尊重专家系统的教训积淀，例如通过模板化、常识示意与推理、或在一些场景中应用迁徙学习等。
