服务器有几十台、容器动辄上百个的时候，日志就不再是调试时顺手打开看一眼的文本文件了。业务日志、访问日志、中间件日志散落在各处，出问题就得一台台登录去翻，光找文件就要花不少时间。日志服务（Simple Log Service，简称阿里云 SLS）是阿里云提供的托管式日志平台，采集、存储、查询分析、可视化和告警都在同一个地方完成。
如果团队不想自己维护一套 ELK 集群，又需要日志能被快速检索和分析，SLS 的好处主要是开箱即用、容量可以按需扩展，运维上的投入比较可控。
先弄清几个基础概念
开始之前，有几个概念最好先搞明白，因为它们直接影响后面的资源怎么规划。
- Project：项目，是资源隔离和权限管理的基本单位。一般按业务线或环境划分，比如生产和测试分开建，权限就不会混在一起。
- Logstore：日志库，用来存放某一类日志。Nginx 访问日志和订单服务日志最好分到不同的 Logstore，查询和保留策略都更好管。
- Shard：分片，决定写入和消费的并发能力。写入量大的 Logstore 要提前评估分片数，否则写入容易成为瓶颈。
- Logtail：采集客户端，部署在服务器或容器里，按规则把日志上传到 SLS。
- Consumer Group：消费组，用来把日志对接到 Flink、Kafka 等下游系统做二次处理。
案例一：大促期间的订单异常排查
某电商团队在大促前发现，部分用户下单后支付回调超时，但应用监控只显示接口耗时偏高，看不出根因。团队把订单服务、支付网关和风控服务的日志统一采集到 SLS 的不同 Logstore 中，再通过 request_id 做关联查询。
用 SLS 的 SQL 语法按时间窗口统计各环节耗时后，问题很快就露出来了：风控服务在高峰期调用外部征信接口时出现大量超时重试，支付链路被连带拖慢。整个定位过程不到半小时，而以前靠人工翻日志，往往要花上好几个小时。
跨服务的关联分析，前提是日志得先集中到一处。
案例二：Nginx 访问日志的流量分析
另一个常见场景是网站访问分析。某内容平台通过 Logtail 把 Nginx 访问日志采集到 SLS，每分钟写入量在数十万条级别。团队用 SQL 聚合各接口的 QPS、状态码分布和响应时间分位数，再放到仪表盘上看趋势。
有一次版本发布后，5xx 比例小幅上升，仪表盘几分钟内就有了变化信号，运维据此及时回滚，没有让影响扩大。
容器环境下的采集
Kubernetes 里的容器随时可能被调度或销毁，容器内的本地日志很容易丢。在集群中部署 Logtail，并按命名空间和标签配置采集规则后，容器日志会自动进入 SLS，业务代码不用改。对扩缩容频繁的微服务来说，这一点省事不少。
告警规则怎么配
SLS 支持基于查询结果设置告警，比如某段时间内错误日志数量超过阈值，就通知值班人员。规则好不好用，主要看下面几点：
- 告警查询尽量精简。时间范围和过滤条件写得越宽，扫描量越大，成本和延迟都会跟着涨。先用关键字段过滤，再做聚合，会更稳。
- 阈值参考历史基线来定。拿最近一两周同一时段的数据看看正常波动区间，再把阈值设在区间外。直接拍一个固定数字，白天可能没问题，到了晚高峰就全是误报。
- 通知要分级。P0 级故障走电话或短信，普通告警进群消息或工单就够了。所有异常都打到同一个人手机上，很快就没人看了。
成本与保留策略
日志量涨得很快，成本控制最好从上线第一天就考虑。常见做法有三类：按业务重要程度设置不同的保留时长；对调试价值低的日志先做过滤或采样，再写入；长期归档的数据转存到成本更低的存储中。具体计费规则以阿里云官方价格页面为准，上线前最好按实际日志量做一次试算。
小结
SLS 的主要价值在于采集集中、查询灵活、告警及时。如果团队有多服务、多环境的排查压力，它能缩短找问题的时间。落地时建议先选一条核心业务线试点，把采集、查询、告警跑通，确认没问题再推广到其他系统。
