作者：荆磊
背景
ELK (Elasticsearch、Logstash、Kibana)是当下开源范畴干流的日志处理计划，在可观测场景下有比较广泛的应用。
跟着数字化进程加快，机器数据日志添加，自建 ELK 在面临大规模数据、查询功用等方面有较多问题和挑战。怎么处理可观测数据的低成本、高可用是一个新的论题。
SLS 是由阿里云推出的云上可观测 Serverless 产品，在功用层面临标 ELK，而且供给了高可用、高功用、低成本的计划。现在 SLS 推出了开源兼容（Elasticsearch、Kafka 等）才能，可协助自建 ELK 场景平滑切换到 SLS 上来，在保存开源运用习气的一起，享受到云上日志的便捷和低成本。
SLS 与 Elasticsearch 的宿世今生
Elasticsearch 是从 2010 年开端写下榜首行代码，全体运用 Java 言语，在 2012 年开端正式建立公司运作。它的底层是 Lucene 全文索引引擎，早期 ES 的首要场景是做企业搜索（比方文档搜素、商品搜索等）。近几年可观测场景数据日益添加，Elasticsearch 正式进入可观测范畴。
SLS 自 2012 年开端就面向可观测场景，从阿里云内部开端孵化，依托于阿里云飞天的底座构建，运用的是 C 言语，以其高功用、高可靠等特性赢得了大量内部客户认可。于 2017 年开端在阿里云上正式对外供给服务。
能够看到，Elasticsearch 和 SLS 的产品进程都超过 10 年。其间，SLS 一直在可观测范畴深耕，经过底层优化持续在可观测范畴供给高质量服务。
阿里云 SLS中心功用架构
SLS 底层运用阿里云飞天盘古分布文件体系存储，支撑各类可观测数据（Log/Metric/Trace）的存储格式，默认运用多副本备份确保高可用，一起也支撑多种存储规格（热存、冷存、归档）。在存储层之上供给各类查询和核算的才能，包含：
- SQL剖析标准SQL92支撑
- 索引查询和SPL，索引查询供给和Lucene相似的查询才能
- 数据加工便利对上报后的日志进行二次加工
- 数据管道供给相似Kafka的消费、写入才能
在基础的存储、核算才能之前也供给了各类言语 SDK，便利事务集成。一起 SLS 也供给了垂直场景开箱即用的功用，包含 AIOps（反常检测、根因剖析）、Copilot（支撑用自然言语的方法查询数据）、告警、移动端监控、Flink、Spark 的消费 lib 等。别的，SLS 供给开源兼容的才能，能够很便利地和现有的开源生态进行集成，包含 Elasticsearch、Kafka 等，经过运用 SLS 兼容才能，能够很便利地将自建体系搬迁到 SLS 上来。
SLS 与 Elasticsearch 功用比照
| 比照项 | SLS | 开源自建 ELK |
|---|---|---|
| 收集才能 | iLogtail（C 完结、高功用、开源） | Beats 系列、Logstash（功用较低） |
| 存储才能 | 单Logstore支撑 PB 级 | 单Index百 GB 级数据量大需求拆分Index |
| 查询才能 | 支撑 | 支撑 |
| 无索引查询 | 支撑SPL方法做无索引查询 | 不支撑 |
| SQL剖析 | 支撑标准SQL92语法 | 不完整的SQL支撑 |
| 流式消费 | 支撑（支撑Kafka协议、SLS 原生协议）Flink/Spark消费 | 不支撑 |
| 告警 | 原生支撑告警 | 需求XPack启用KibanaWatch或许第三方（Grafana告警、ElasticAlert等） |
| 可视化 | SLS 原生控制台/Grafana/Kibana | Kibana、Grafana |
| DevOps 渠道集成 | SLS控制台页面可直接嵌入到 DevOps渠道 | Kibana有限的嵌入才能，首要依靠SDKAPI做二次开发 |
| AIOps | SLS原生支撑AIOps | 需XPack启用 |
SLS 原生供给了丰富的功用，根据 Serverless 的特性，这些在云上能够做到一键启用。
SLS 与 Elasticsearch 的可运维性比照
| 比照项 | SLS | 开源自建 ELK |
|---|---|---|
| 容量规划 | Serverless无需重视 | 需重视容量•假如磁盘满将直接影响可用性•ES 写入功用差，需求为顶峰预留足够多的资源 |
| 机器运维 | Serverless无需重视 | 需求重视机器可用性，假如批量宕机将影响可用性 |
| 功用调优 | 只需扩LogstoreShard即可 | 需求专业的 Elasticsearch 范畴支撑，或许需求社区支撑 |
| 版本晋级 | Serverless无需重视(SLS 后台持续迭代，提升功用) | 开源ELK不确保版本兼容性，或许因为晋级导致不可用 |
| 数据可靠性 | 底层运用业界抢先的飞天盘古存储，默认 3 副本存储 | 按需设置副本数；假如是单副本，遇意外数据损坏，可恢复概率低 |
| 服务 SLA | SLS确保 | 专人或专门团队确保，或许因为大的Query导致集群不可用 |
因为 SLS 是云上 Serverless 服务，无需购买实例即可运用，免除了运维层面的烦恼。而自建 ELK 需求重视许多运维层面的问题。关于运用量较大的场景，比方数据量到 10TB 以上，往往需求专业的人来做 Elasticsearch 的保护和调优。
SLS 与 Elasticsearch 的功用比照
这儿在实验室环境中做了一下简略的查询剖析才能的测验。在 10 亿级别的数据量中做查询和剖析，SLS 响应时间在秒级，而 Elasticsearch 跟着并发增大，响应时间有显着上升，而且在全体延时上比 SLS 高。这儿还需求说到 Elasticsearch 的写入功用问题，测下来单核才能在 2MB/s 左右，而 SLS 单 Shard 写入能能够支撑到 10MB/s ，经过扩展 Logstore 的 Shard 数能够轻松地提升写入功用。
SLS 与Elasticsearch 的成本比照
上面是一张成本比照图，Elasticsearch 的机器数基本上是由峰值的写入量决议的。关于 Elasticsearch 而言，写入是最大的瓶颈；Elasticsearch 存储空间需求考虑索引膨胀率和必定的空间预留。否则或许因为磁盘满导致服务不可用。
关于 SLS 而言，作为 Serverless 服务，它供给按写入量计费的方法，依照现在 0.4 元/GB 的写入费用预算，在 10TB 每天的场景下，30、90、180 全国的成本相对 Elasticsearch 有显着优势。其间，SLS 费用预估时依照下面的方法测算：
- SLS按流量计费0.4 元/GB（送 30 天存储）
- 90天存储依照30天热 60天低频
- 180天存储依照30天热 60天低频 90天归档
那么是不是只有数据量大的情况下 SLS 才换算呢？答案是否定的，考虑一个场景，假如每天数据量是 10GB，需求保存 30天，那么每天的费用是 4 元，即每个月 120 元。需求一台 ECS 至少 2core 4g 磁盘空间 400GB（300/0.75 空间预留），每月持有费用是大于 200 的。
SLS 开源兼容才能
SLS 的 Elasticsearch 兼容、Kafka 兼容才能是根据 SLS 底层存储核算才能构建的。本质上是将 Elasticsearch、Kafka 的恳求转换为 SLS 的协议进行恳求，因而一份数据不管用什么方法写入 SLS，都能够用 Elasticsearch 兼容的方法来查询，也能够用 Kafka 兼容的方法来消费。
曾经，关于 Kafka ELK 的架构，往往需求较多机器做数据同步（LogStash、HangOut 等）；现在运用一个 SLS 彻底不需求数据同步，就能够用不同的协议来拜访。简略来说便是一份数据供给了多种协议方法。经过 Kafka 协议写入的数据能够用 ES 协议来立马查询；同样经过 Elasticsearch 协议写入的数据，能够用 Kafka 立马消费。运用 SLS 的开源兼容才能，相当于一起具有一个 Serverless 的 Kafka 和 Elasticsearch，而且是按量付费，无需购买实例。
运用Kibana拜访SLS
用 Kibana 拜访 SLS 需求 3 个组件：
- Kibana
- Proxy用于区分Kibana的元数据恳求和日志数据恳求
- Elasticsearch只用于存Kibana的meta数据，资源占用比较小，用一台小规格ECS即可满意
Kibana 将元数据存在 Elasticsearch 中，会有 meta 更新的操作。当时 SLS 供给的是不可修改的存储，因而 meta 类的数据还需求一个小的 Elasticsearch 来承载。这个 Elasticsearch 只处理 meta 恳求，因而负载和数据存储量非常低，用小规格 ECS 能够满意。
运用Kibana拜访SLS详细能够参阅对接 Kibana [ 1] 。
运用GrafanaElasticsearch插件拜访SLS
除了 Kibana 的方法来做日志可视化，也能够用 Grafana 的 Elasticsearch 插件来拜访 SLS。运用 Grafana Elasticsearch 插件拜访 SLS Elasticsearch 兼容接口，有2个好处：
- 不需求写SQL语句，经过界面操作即可完结图表可视化
- 不需求在Grafana额定装置插件
用Grafana自带的Elasticsearch插件拜访SLS详细能够参阅运用 Grafana ES 插件拜访 SLS [ 2] 。
运用KafkaSDK写入/消费SLS
运用 Kafka 官方的 SDK 能够对接 SLS 的 Kafka 兼容接口。支撑 Kafka 写入和消费两种才能。
推荐运用Kafka官方SDK消费，详细能够参阅KafkaSDK 消费 SLS [ 3] 、各类 Agent 写 SLS Kafka 兼容接口 [ 4] 。
开源 ELK 的平滑搬迁计划
运用双采计划进行搬迁
在原先的机器上布置 SLS 的 iLogtail 收集 Agent，将事务日志运用 iLogtail 收集到 SLS 上（一份日志能够被多个 Agent 收集，不会冲突），然后运用 Elasticsearch 兼容、Kafka 兼容的才能对接原有的运用程序。经过这个计划能够很便利地做功用、数据完整性验证。在充分验证后，移除掉机器上 filebeat 的 Agent，即可完结链路切换。
运用开源Agent直写搬迁
假如是新的事务或许 APP 想要测验 SLS，没有前史包袱。可是又不想在机器上装置 iLogtail。那么能够复用本来的收集 Agent，将收集 Agent 的日志以 Kafka 协议的方法写入到 SLS。参阅运用 Kafka 协议上传日志 [ 5] 。在日志写入 SLS 后，想保存开源运用习气，能够运用 SLS 兼容接口对接 Kibana、Grafana 等可视化东西。
运用Kafka导入搬迁
假如咱们不期望动本来的收集链路，一起又要保存原 Kafka（通常是依靠 Kafka 的前史留传程序较多，不好动），那么能够运用这个计划。运用 SLS 的 Kafka 导入功用，无需布置实例，在页面上装备即可完结 Kafka 数据导入到 SLS （支撑持续导入），参阅 SLS Kafka 导入 [ 6] 。将 Kafka 数据导入到 SLS 后，能够运用 SLS 开源兼容的才能保存开源运用的习气。
运用Elasticsearch导入功用搬迁存量数据
关于Elasticsearch中前史数据期望能够导入到SLS中做保存的场景，能够运用SLS的Elasticsearch导入功用，功用参阅ES 导入 [ 7] 。
总结
本文介绍了 SLS 基本才能，并和开源自建 ELK 做了比照，能够看到 SLS 比较开源 ELK 有较大优势。凭借 SLS Serverless 服务才能协助运维团队有用降低日志体系的运维压力与成本，提升日志运用的体会。现在 SLS 供给了丰富的开源兼容才能，在体会 SLS 许多 Feature 一起，又能够保存开源运用习气；在 ELK 日志体系切换便利又能够做到平滑搬迁。综上，欢迎咱们运用 SLS ，有任何问题能够经过客户群、工单来联络咱们。
参阅链接：
[1]对接 Kibana
[2]运用 Grafana ES 插件拜访 SLS
[3]KafkaSDK 消费 SLS
[4]各类 Agent 写 SLS Kafka 兼容接口
[5]运用 Kafka 协议上传日志
[6]SLS Kafka 导入
[7]ES 导入
相关链接：
-
SLS 服务介绍
-
SLS 的 ES 兼容运用文档
-
SLS 的 Kafka 兼容运用文档
