服务器上的访问记录、应用报错、用户点击轨迹、数据库慢查询，日志每天都在产生。日志多了之后麻烦也跟着来：文件散落在十几台机器上，出故障时运维得一台台登录，用 grep 翻找，既慢又容易漏掉关键的那一行。
阿里云日志服务（Simple Log Service，简称 SLS）就是为这个场景准备的。它是全托管的日志和时序数据服务，采集、存储、检索、分析、可视化到告警都在一个平台里完成。你不用自己搭 Elasticsearch 集群，也不用为扩容和日常维护操心。
它能做什么
用一个工具之前，先搞清楚它每一段负责什么。日志服务大致可以按四段来看：
- 采集：通过 Logtail 采集代理收集主机、容器的日志，移动端也可以用 SDK 上报。在 Kubernetes 环境里能自动发现采集目标，新起的 Pod 不用手动加配置。
- 存储：日志按 Logstore 组织。保存周期可以按数据类型单独设定，老数据可以转为冷存储，既控制成本，也不影响近期查询。
- 查询与分析：支持 SQL 语法，可以直接对大量日志做聚合、多条件过滤和时间序列统计，不必先导出再处理。
- 告警与可视化：把关键指标放到仪表盘上，再配合告警规则和通知渠道，异常能直接推给对应的负责人。
实际用起来，变化最明显的是排查速度。以前要在几台机器之间来回切换，现在在控制台输入条件就能看到结果。前提是关键字段要提前建好索引，否则查询会慢下来。
几个常见用法
应用故障排查
微服务下一次请求可能穿过十几个节点。每个节点的日志单独看，很难拼出完整过程。把所有服务的日志统一采集后，用请求 ID 把它们串起来，就能看到这次请求在哪一步变慢或报错。
安全审计与合规
登录日志、操作日志、访问日志是审计时最先被要求提供的材料。日志服务支持长期留存，还可以设置规则盯住异常登录、短时间内大量失败请求这类风险行为。等保等合规要求里对日志留存和可追溯性的规定，可以靠这套配置来对应，具体条款还是要和合规团队核对。
业务数据分析
日志不只给运维看。页面访问和交易相关的日志里，有用户从哪里来、在哪一步离开、哪类商品点击多这些信息。业务同学用 SQL 直接查原始日志，就能先看个大概，不必每次都等离线任务跑完。
一个电商大促的例子
这里用一家中型电商平台做例子。它每年大促时，订单请求量会在短时间内涨到平时的好几倍。以前靠日志文件加脚本分析，大促当晚支付接口超时，排查花了将近两个小时，最后才发现是下游库存服务的连接池配置偏小。
后来，他们把网关、订单、支付、库存四个系统的日志都接入了日志服务，主要做了三件事：
- 在 Logtail 里配置多行合并，保证 Java 异常堆栈完整采集，否则一段堆栈会被拆成很多条互不相干的记录。
- 给 status、latency、trace_id 等字段建索引，再写 SQL 统计每分钟各接口的错误率和 P99 耗时。
- 按错误率和耗时设定阈值告警，超过时自动发到钉钉群，并短信通知值班同学。
第二年大促，类似问题又出现了。这次告警在耗时超过阈值后两分钟内就响了。值班同学在仪表盘上看到库存接口延迟在往上走，再用 trace_id 检索，十分钟内定位并扩容了连接池。主要交易链路没有受影响，故障持续时间从将近两小时降到十五分钟左右。
这个例子里起作用的，是日志从出事后才翻的文件，变成了随时能查的数据，同时告警会主动找人。工具本身倒在其次。
上线前可以先注意的几点
- 挑最常出问题的一个系统先接入，把采集、查询、告警跑通，再推广到其他系统。一开始就全量接入，出了问题很难判断是哪一环的毛病。
- 统一时间戳格式、请求 ID 和服务名这几个字段。各服务字段名不一致，后面做关联分析时会花大量时间做字段映射。
- 按用途分开设置保存周期。调试日志保留几天通常够用，审计类日志则要按合规要求长期保存，两者混在一起会浪费存储。
- 索引只建在真正会用来检索的字段上。字段越多，存储和查询成本越高，有些字段只是打印出来看看，并不需要索引。
日志服务能做的事情很多，但用起来顺不顺，多半取决于日志格式是否统一，以及团队有没有认真去看告警和仪表盘。
