简介：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）。

## 日志采集端性能比照

目前支流开源社区的日志采集端个别是 Logstash 和 Fluentd，晚期版本会进行一些性能和性能的比拟，测试后果数据参考

用户如果之前是 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

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