阿里云日志服务（Simple Log Service，简称 SLS）是云原生观测与分析平台，统一处理 Log（应用日志）、Metric（系统指标）和 Trace（链路追踪）三类可观测数据，提供从数据采集、实时处理、存储、查询分析到告警通知的完整链路。它不是单纯的日志存储工具，而是可以替代自建 ELK（Elasticsearch + Logstash + Kibana）的全托管观测平台。
SLS 是阿里巴巴集团内部的日志与监控基础设施，历经多次双十一高峰考验，每天处理数百万服务器上 PB 级别的日志数据。对出海业务和企业生产环境来说，SLS 的价值在于：不需要维护任何 Elasticsearch 集群，日志写入后实时可查，存储可以分层降成本，告警配置门槛低且可靠。
核心数据结构：Project、LogStore 与 Shard
理解 SLS 的资源组织方式，是配置日志采集和控制成本的前提。
Project 是 SLS 最顶层的资源管理单元，也是访问控制和计费隔离的边界。不同的项目（业务线、产品模块）应该分别创建独立的 Project，方便权限管理和账单分类。Project 是地域级资源，创建时选定地域后不能修改，建议选择与 ECS 实例相同的地域，避免跨地域写入日志产生额外流量费用。
LogStore 是 Project 下存储日志数据的容器，每个 LogStore 独立配置日志保留时长（1 天到 3650 天）、Shard 数量、索引规则。一个 Project 下可以创建多个 LogStore，按业务模块、日志类型或重要程度分开存储，例如将 Nginx 访问日志和应用错误日志分别存入不同的 LogStore，查询时互不干扰。
Shard 是 LogStore 内的数据分区，每个 Shard 提供固定的读写吞吐量（写入 5MB/s 或 500 条/s，读取 10MB/s）。日志写入速率超过 Shard 的处理能力时，会出现写入限流报错，此时需要扩容 Shard 数量。
一个重要的成本注意事项： 只要 LogStore 存在，其中的活跃 Shard 就持续产生租用费，无论是否有日志写入。业务下线或测试完成后，如果不再需要某个 LogStore 或 Project，应及时删除整个 Project，而不是仅删除其中的 LogStore。在快速入门教程中创建了大量 Project 和 LogStore 的用户，经常因为忘记清理而产生持续的 Shard 租用费。
数据采集方式
SLS 支持多种数据采集方式，覆盖服务器日志、云产品日志、前端日志和自定义程序日志。
LoongCollector（服务器日志采集）
LoongCollector 是 SLS 提供的服务器端日志采集 Agent，是 Logtail 的升级版本，新增了对 OpenTelemetry 协议的支持，向后兼容已有的 Logtail 配置。LoongCollector 安装在需要采集日志的 ECS 实例上，根据控制台配置的采集规则，实时监听指定路径下的日志文件，将新写入的日志内容批量发送到 SLS 对应的 LogStore。
在 Linux ECS 实例上安装 LoongCollector：
# 下载安装脚本（选择和 ECS 相同的地域，减少传输延迟和流量费）
wget https://logtail-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/linux64/logtail.sh
# 执行安装（替换 cn-hangzhou 为实际地域）
chmod 755 logtail.sh && ./logtail.sh install ap-southeast-1
# 检查安装状态
/etc/init.d/ilogtaild status
安装完成后，在 SLS 控制台完成两项配置：创建机器组（Machine Group），将安装了 LoongCollector 的 ECS IP 加入机器组；创建采集配置（Logtail Config），指定日志文件路径、解析方式（单行文本、多行、JSON、Nginx 格式等），并将采集配置应用到机器组。配置生效后，LoongCollector 自动开始采集并上传日志，不需要重启服务或修改应用代码。
关于 ECS 实例的 IP 配置和安全组设置，可以参考 阿里云 ECS 完整教程。
阿里云产品日志直接接入
阿里云的主要云产品（RDS、SLB、OSS、WAF、DDoS 高防等）都支持将访问日志、错误日志直接投递到 SLS，不需要在服务器上安装任何 Agent。在对应产品的控制台找到日志配置页面，选择目标 Project 和 LogStore，开启日志投递后日志自动写入 SLS。
这类日志对安全审计、访问分析和问题排查价值很高。RDS 的慢查询日志写入 SLS 后，可以用 SQL 语句统计哪些查询最耗时；WAF 的访问日志写入 SLS 后，可以实时分析攻击特征和攻击来源。
SDK 写入自定义日志
应用程序可以通过 SLS SDK 直接将业务日志写入 SLS，不经过文件系统落盘，适合日志量大、对写入延迟敏感的场景：
import aliyun.log as log
# 初始化 SLS 客户端
client = log.LogClient(
endpoint=’ap-southeast-1.log.aliyuncs.com’,
accessKeyId=’your_access_key_id’,
accessKey=’your_access_key_secret’
)
# 构建日志条目
log_item = log.LogItem()
log_item.set_time(int(time.time()))
log_item.set_contents([
(‘level’, ‘ERROR’),
(‘module’, ‘payment’),
(‘user_id’, ‘123456’),
(‘message’, ‘Payment failed: insufficient balance’),
(‘order_id’, ‘order-789’)
])
# 写入 LogStore
request = log.PutLogsRequest(
project=’my-project’,
logstore=’app-errors’,
topic=’payment-service’,
source=’server-01′,
logitems=[log_item]
)
client.put_logs(request)
ACK 容器环境的日志采集配置方式不同，容器内的 stdout/stderr 日志可以通过 SLS 的 DaemonSet 采集模式统一收集，不需要在每个容器内单独安装 Agent。关于 ACK 集群的日志采集配置，可以参考 阿里云 ACK 容器服务指南的运维部分。
查询与分析
SLS 的查询语法将搜索和 SQL 分析结合在一个语句中，格式为 [搜索条件] | [SQL 分析语句]，搜索条件筛选日志范围，SQL 分析对筛选后的日志做统计和聚合。
查询指定时间范围内所有 HTTP 500 错误：
status:500
统计各 HTTP 状态码的出现次数，按数量降序排列：
* | SELECT status, COUNT(*) as count GROUP BY status ORDER BY count DESC
分析最近 1 小时的 Nginx 访问日志，找出响应时间最长的 10 个 URL：
* | SELECT request_uri,
avg(request_time) as avg_time,
max(request_time) as max_time,
COUNT(*) as request_count
FROM log
GROUP BY request_uri
ORDER BY avg_time DESC
LIMIT 10
统计错误日志在过去 24 小时内的时间分布（每小时汇总）：
level:ERROR | SELECT
date_trunc(‘hour’, from_unixtime(__time__)) as hour_bucket,
COUNT(*) as error_count
FROM log
GROUP BY hour_bucket
ORDER BY hour_bucket
SLS 的查询语法兼容标准 SQL，支持 GROUP BY、ORDER BY、LIMIT、JOIN（跨 LogStore 联合查询）和近百种内置分析函数，包括数学函数、字符串函数、日期函数、地理位置函数、机器学习函数等。
2026 年 SLS 新增了 AI Copilot 功能，用自然语言描述查询需求，系统自动生成对应的查询语句。对于不熟悉 SLS 查询语法的用户，Copilot 可以显著降低上手门槛。
告警配置
SLS 的告警基于查询结果触发，当某个查询在指定时间范围内返回的数据满足设定条件时，发送告警通知。
配置告警的基本步骤：在 LogStore 的查询分析页面写好查询语句，点击「另存为告警」；配置检查频率（告警系统多久执行一次查询，最短 1 分钟）；设置触发条件（查询结果的某个字段满足大于、小于或等于某个值）；配置告警通知渠道（钉钉、企业微信、短信、邮件、Webhook）。
以监控应用错误率为例，每 5 分钟检查一次最近 5 分钟内的错误日志数量：
查询语句：
level:ERROR | SELECT COUNT(*) as error_count
触发条件：error_count > 50（5 分钟内错误超过 50 条时告警）
告警通知可以通过 Webhook 发送到 Slack、PagerDuty 等外部系统，也可以通过阿里云的短信和邮件渠道直接通知运维人员。
计费方式
SLS 提供两种计费模式，2026 年新增了按写入数据量计费模式，计费逻辑更简单。
标准计费模式按多个维度独立计费：活跃 Shard 租用费（每个 Shard 每天固定费用，无论是否有数据）、写入流量费（写入 SLS 的原始日志量）、索引存储费（建立了索引的日志占用的存储量）、读取流量费（查询时读取的数据量）。标准模式的计费项较多，需要提前规划 Shard 数量和索引策略，不合理的索引配置会显著增加成本。
按写入数据量计费模式是 2026 年新推出的简化模式，核心费用只按写入的原始数据量计费，适合查询分析频繁、希望成本结构更简单的场景。这个模式减少了对 Shard 数量规划的要求，对不擅长 SLS 资源配置的用户更友好。
降低 SLS 成本的几个直接方式：
合理设置日志保留时长，不是所有日志都需要保留 180 天。应用访问日志一般保留 30 天足够日常排查，安全审计日志可能需要保留 1 年以上。SLS 支持为 LogStore 设置热存储（默认 7 天）和冷存储（更低单价），过期后自动转为冷存储，整体存储成本降低。
只对需要搜索和分析的字段建立索引，不必要的全文索引会大幅增加索引存储费用。对于只需要存档备份的日志，可以关闭索引，只保留原始日志数据，等需要分析时再临时开启索引。
测试结束后及时删除 Project 而不只是 LogStore，彻底停止 Shard 租用费。
SLS vs 自建 ELK
SLS 和 ELK 是同一类问题的两种解决方案，选择依据是运维能力和成本结构。
自建 ELK 的核心优势是开源、可完全自定义，数据存储在自己的服务器上，没有数据出境的顾虑，且 Kibana 的可视化配置灵活度更高。代价是需要维护 Elasticsearch 集群：配置 JVM 内存、处理集群分片不均衡、处理 Elasticsearch 的 GC 问题、定期清理旧索引以控制磁盘用量，这些运维工作在日志量增长后会变得繁重。自建 ELK 在 10 亿条以上的数据规模下，查询性能和稳定性明显不如 SLS。
SLS 的优势是完全托管，没有集群需要维护，写入后立即可查，弹性伸缩由平台自动处理。阿里云的数据显示，同等日志规模下 SLS 的总持有成本（TCO）比自建 ELK 低 50% 以上，主要节省来自不需要为 Elasticsearch 节点付费和不需要 ELK 运维人力。
适合选 SLS 的场景：在阿里云上运行业务、团队没有专职的 ELK 运维人员、日志量有可能快速增长。适合坚持自建 ELK 的场景：有强烈的数据主权要求、已经有成熟的 ELK 运维体系、需要 Elasticsearch 特有的全文搜索功能。
账号开通与代理充值
使用阿里云 SLS 需要有效的阿里云国际版账号，SLS 在控制台直接开通，不需要额外审批，有一定的免费额度可供初期测试使用。通过 阿里云账号出售 渠道获取的高权重账号，可以直接用于生产环境的日志采集配置，1 分钟交付，免实名免绑卡。
对于同时运行 ECS、ACK 和 SLS 的团队，月均阿里云消耗通常在 $300 以上，通过 阿里云国际合作伙伴 充值可以获得赠金返点（$100 到账 $110，$500 到账 $600，$1000 到账 $1250），赠金适用于 SLS 的 Shard 租用费、存储费和读写流量费，付款支持 USDT 和对公转账，年度实际成本明显低于官网直充。
