CDS技术揭秘系列 02阿里云CDS-SLS大揭秘

Posted 2021-10-19 阿里云开发者

简介：CDS-SLS 作为云化的日志平台，将组件进行高内聚低耦合，线下用户最低可以在6台规模的机器上将上述所有的功能自动化部署，在运维、运营、财务管理、数据分析报表等大数据场景领域以低代码模式有效解决传统软件中的痛点。本文主要进行 CDS-SLS 各功能点概览性的介绍。

前言

本文作为即将发布的混合云产品 CDS-SLS（Cloud Defined Storage-Simple Log Service）一系列文章中的第二篇，主要进行 CDS-SLS 各功能点概览性的介绍。日志作为数字化的载体，里面包含了后台程序的运行信息，业务运营等信息。

日志的查询分析从最早的几台机器的手工 pssh+grep 发展到每个业务的小规模 ELK 或者 EFK（Elasticsearch, Logstash/Filebeat/Fluentd, Kibana），量大的再加上 Kafka，如果有采集 Metric的需求还需要加 Collectd，如果有可视化需求还需要增加 Grafana，对存储备份有需求的还会引入 Ceph，对于基础配置的一致性管理引入 Salt 等，每增加一个组件在高并发场景下硬件成本和运维成本迅速增加。

CDS-SLS 作为云化的日志平台，把这些组件进行了高内聚和低耦合，线下用户最低可以在6台规模的机器上将上述所有的功能自动化部署，在运维、运营、财务管理、数据分析报表等大数据场景领域以低代码模式有效解决传统软件中的痛点。

术语&背景

CDS

CDS(Cloud Defined Storage)云定义存储。属于软件定义存储SDS(Software Defined Storage)的一种输出形式，CDS 具备与公共云统一的存储架构和统一的用户体验，减小底座，提供灵活的部署规模和部署形态，融合多个存储产品，提供企业级存储的运维和管理。

CDS支持各种存储产品的混部组合，例如 CDS-OSS + CDS-SLS ，CDS-EBS + CDS-SLS 等。产品方面会有敏捷版（SLS 最小规模六台，计划推出缩减到四台的更精简版本）和企业版（SLS 6台到数百台）两种输出形式。CDS 一方面提高专有云企业版和敏捷版的产品竞争力和产品成熟度；另一方面，在端、边缘和客户数据中心等环境实现各类数据的接入、备份、分析。

SLS

SLS(Simple Log Service) 阿里云日志服务。SLS 起源于阿里云早期飞天底座中的神农监控服务目前已发展为集采集、查询分析、可视化一体的面向云原生可观测性的 *Ops(DevOps、SecOps、 FinOps) 整体解决方案。

SLS的主要功能概览

SLS 中的日志数据是 AppendOnly，写多读少，对时间敏感但并非要求严格保序，查询频率和热度随时间迅速递减。CDS-SLS 版本继承自阿里云上的 SLS，目前 SLS 已经连续多年支撑阿里双十一/双十二活动，同时支撑众多如新春红包、周年大促等重大活动，在稳定性、功能性以及性能方面得到了充分的验证。

本文着重从运维相关的角度来展开 SLS 的各个功能点。SLS 的主链路包含数据采集-数据查询分析-可视化-智能应用，作为计算和存储并重的产品，为了进一步降低线下用户的硬件成本，会进行一些非通用性的功能的裁剪，将硬件本身的计算资源和存储资源发挥到极致。

上图是公共云用户视角下的 SLS 功能，对于 CDS-SLS 线下用户，可以在天基平台看到 SLS 服务对应的各个子模块，也能完整看到各进程对应的 CPU 和内存占用。从服务的角度分为数据类和调度类两个大类，前者拆分为 34 个服务角色，后者拆分为 10 个服务角色。拆分后服务的升级和扩缩容将会变得更加容易。

SLS内部服务拆分

sls-service-master 主要进行调度相关的服务，它的每个服务角色有多个实例确保高可用。主要的服务功能集中在 sls-backend-server 中，大致的分层结构如下：

CDS-SLS 目前默认底层分布式存储是盘古 2.0 系统。盘古 2.0 作为阿里云的存储底座具备高性能高稳定性的特征。SLS 的内部业务模块也进行了很好的微服务的拆分，底层使用C++自研，以实现极致的性能。

SLS的各模块中有大量的后台参数可以调节，只是我们为了方便客户使用，默认值往往能满足绝大多数客户的需求。很多设计都秉承"提供机制而不是策略（Separation of mechanism and policy）"和“单一职责（Do one thing and do it well）”的经典UNIX思想。

• 用户关心的流控，后台提供多种维度的精确控制，默认的参数可以覆盖绝大部分场景。
• 数据采集Agent（Logtail）经过多年百万机器大规模验证，在性能、稳定性上都有很好保证，相比开源软件，可以大幅降低对机器资源的占用（最高可降低90%）。
• "查询|分析"的管道式的设计就很好的贯彻了单一职责，查询和分析分别对应不同的后台服务。

混合云场景的特殊设计

集群形态

目前的天基中的SLS相关的集群有两个：

• 底座中的 sls-common 集群共享底座的盘古，提供最基本的查询分析，供阿里云底座中各服务进行自运维，限于底座资源保存时间 7 天。在混合云网络隔离不可达的场景下显著提升运维的效率，开发人员通过几个关键词让现场人员查询即可很快定位问题。
• 用户单独购买的 CDS-SLS 集群，独占一套盘古，集群中只运行SLS相关的进程，有效缓解了底座共享资源紧张的问题，所以日志的 TTL 可以永久保存，并且有体验更好的控制台。

本文提到的绝大多数功能都是针对用户单独购买的 CDS-SLS 集群。

国产化信创支持

目前 CDS-SLS 会支持海光，鲲鹏，飞腾等CPU的架构，并会有严格的和 Intel X86 相同的验收测试。之后还会针对线下输出场景更多异构 CPU 和混合场景的测试支持。

针对HTTPS的访问会支持国密 TLS 信道传输，让一些金融或者政企行业的数据访问更合规。

开源ELK方案对比和迁移

ELK的背景

Elastic主要基于Lucene实现，2012 年 Elastic 基于 Lucene 基础库包成了一个更好用的软件，并且在 2015 年推出 ELK Stack（Elastic Logstash Kibana）解决集中式日志采集、存储和查询问题。但是 Lucene 设计场景是 Information Retrial，面对是 Document 类型，因此对于可观测分析（Log/Trace/Metric）数据有一定限制，例如规模、查询能力、以及一些定制化功能（例如智能聚类 LogReduce）。

Elasticsearch	日志服务	说明
index	logstore	允许用户将多个 index 上的数据迁移至一个 logstore。
type	logItem 中的字段 __tag__:_type
document	logItem	Elasticsearch 的文档和日志服务中的日志一一对应。
mapping	logstore 的索引	工具默认情况下会为您自动创建好索引。
field datatypes	logItem 数据类型	具体映射关系参考数据类型映射。

日志采集端功能对比

目前主流开源社区的日志采集端一般是 Logstash 和 Fluentd，早期版本会进行一些功能和性能的比较，测试结果数据参考

功能项	Logstash	Fluentd	Logtail
日志读取	轮询	轮询	事件触发
文件轮转	支持	支持	支持
Failover处理 (本地checkpoint)	支持	支持	支持
通用日志解析	支持grok（基于正则表达式）解析	支持正则表达式解析	支持正则表达式解析
特定日志类型	支持delimiter、key-value、json等主流格式	支持delimiter、key-value、json等主流格式	支持key-value格式
数据发送压缩	插件支持	插件支持	LZ4
数据过滤	支持	支持	支持
数据buffer发送	插件支持	插件支持	支持
发送异常处理	插件支持	插件支持	支持
运行环境	JRuby实现，依赖JVM环境	CRuby、C实现，依赖Ruby环境	C++实现，无特殊要求
线程支持	支持多线程	多线程受GIL限制	支持多线程
热升级	不支持	不支持	支持
中心化配置管理	不支持	不支持	支持
运行状态自检	不支持	不支持	支持cpu/内存阈值保护

用户如果之前是 logstash 采集，也可以很容易迁移到 SLS，可以参考：Logstash数据源接入SLS

Logstash支持所有主流日志类型，插件支持最丰富，可以灵活 DIY，但性能较差，JVM 容易导致内存使用量高，作为最重要的插件之一的 Grok 性能问题导致很多用户从 ELK 变为 EFK。

Fluentd 支持所有主流日志类型，插件支持较多，性能表现较 Logstash 有提升但受限于 Ruby 的 GIL 大锁，性能还需要进一步提高，官方文档也明确了这个缺陷。
Ruby has GIL (Global Interpreter Lock), which allows only one thread to execute at a time. While I/O tasks can be multiplexed, CPU-intensive tasks will block other jobs. One of the CPU-intensive tasks in Fluentd is compression.

Logtail 占用机器 CPU、内存资源最少，结合阿里云日志服务的 E2E 体验良好，目前经过几年的迭代，功能已经比较完善，尤其是针对容器场景进行了大量的性能优化和用户体验的优化，对于 Daemonset 和 Sidecar 模式的支持比较成熟。

查询分析对比

•低门槛：完整 SQL92 标准，JDBC 完整协议，支持 Join

•高性能：查询延迟相比 ES 低、

•智能：支持机器学习AI算法、支持场景化聚合函数

• 场景化函数：通过十余年实战经验沉淀针对数据分析场景的 30+ 聚合计算函数
• 机器学习函数：大数据与机器学习相结合，丰富的机器学习函数
• 多渠道数据源：发挥阿里云平台优势联动更多数据源，如IP地理位置库数据、威胁情报数据、白帽子安全资产库

ELK到SLS的数据一键迁移

目前的很多用户都是在被多个分散的小的 ES 集群水位和消息队列高并发的时候难以运维选择了 SLS，所以从 ES 到SLS 的迁移就变得非常关键，如何能优雅而且容易的把数据迁移到 SLS，目前 SLS 已经给出了比较成熟易用的方案。ELK到SLS的数据一键迁移方案详情

重要特征

• 支持断点续传：调用参数中 cache_path 指定 checkpoint 的存放位置，当迁移程序中断后，重新打开时指定相同的 cache_path 便可以继续迁移任务。
• 迁移速率快：单个 SLS shard， 单个 ES shard，pool_size 为1，可实现接近5M/s的迁移速度。可通过调整 SLS shard 和 pool_size 大小来达到提速。

常用的迁移命令模式

• 将 hosts 为 localhost:9200 的 Elasticsearch 中的所有文档导入日志服务的项目 project1 中。

aliyunlog log es_migration --cache_path=/path/to/cache --hosts=localhost:9200 --project_name=project1 

• 指定将 Elasticsearch 中索引名以 myindex_ 开头的数据写入日志库 logstore1，将索引 index1,index2 中的数据写入日志库 logstore2 中。

aliyunlog log es_migration --cache_path=/path/to/cache --hosts=localhost:9200,other_host:9200 --project_name=project1 --logstore_index_mappings='{"logstore1": "myindex_*", "logstore2": "index1,index2"}}' 

后续

在保证稳定性的前提下为了追求极致性能会持续进行新版本的迭代升级和更多新功能的引入，客户的通用类需求会放在更高的优先级。例如用户比较直观能感受到的硬件机型 SLS 在线下会从单一款计划增加到三款来满足更多类客户的精细化需求，在常规基础上会引入计算门槛相对低一点的硬件和对于日志保存时长有特殊长时间要求的的金融类客户的存储高密机型。

软件层面更快更智能的查询分析作为核心功能会让 CDS-SLS 在一站式的日志平台中给客户更好的体验，SLS 起于日志，不止于日志，其他更多功能后续会持续分享。

原创作品：阿里云存储 禅车

系列文章传递门：

1. 【CDS技术揭秘系列 总篇】阿里云的云定义存储来了https://developer.aliyun.com/article/792044?spm=a2c6h.13148508.0.0.3eef4f0ecyZOjQ
2. 【CDS技术揭秘系列 01】阿里云CDS-OSS容灾大揭秘https://developer.aliyun.com/article/792000?spm=a2c6h.13148508.0.0.3eef4f0ecyZOjQ
   

原文链接：https://developer.aliyun.com/article/792110?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。