一、为什么需要日志服务？
在做智慧票务系统的过程中，我们踩过一个很大的坑：早期所有应用日志都存在每台ECS服务器本地磁盘上。
问题很快就暴露出来了：
- 节假日高峰期出问题，登录到某台服务器看日志，发现请求被负载均衡分到了其他机器上
- 一台一台服务器翻日志，排查一个问题要半小时以上
- 服务器重启或者扩容缩容，历史日志直接丢失
- 想统计一下今天有多少个500错误，得写脚本去每台机器grep
后来我们接入了阿里云日志服务SLS，整个排障效率提升了一个数量级。
二、SLS接入方案
2.1 基础架构
我们的日志采集架构很简单：
- 每台ECS上安装Logtail采集器
- 配置采集规则，自动收集Nginx访问日志、Java应用日志、错误日志
- 所有日志统一发送到SLS的Project和Logstore
- 在SLS控制台做查询、分析、告警
整个接入过程非常顺利，Logtail安装脚本一条命令就搞定了，不需要改应用代码。
2.2 日志规范
我们定义了统一的日志格式：
- 时间戳
- TraceId（全链路追踪ID）
- 请求路径
- 响应状态码
- 响应耗时
- 用户ID
- 错误信息
这样做的好处是，只要拿到一个TraceId，就能在SLS里把整个请求链路的所有日志都串起来。
三、实际排障案例
3.1 案例一：高峰期接口突然变慢
现象：国庆假期某天上午10点，监控告警显示购票接口平均响应时间从80ms涨到了800ms。
用SLS排查过程：
- 在SLS里筛选状态码200、耗时大于500ms的请求
- 发现慢请求都集中在某个特定的票种查询接口
- 按TraceId分组，发现这个接口每次都要查3次数据库
- 进一步查RDS慢查询日志，发现是某个索引失效了
解决：重建索引后，接口响应时间立刻恢复正常。整个排查过程只用了10分钟，要是以前翻本地日志，至少要半小时。
3.2 案例二：偶发的500错误
现象：系统每天零星出现几个500错误，量不大但用户体验不好。
用SLS排查过程：
- 在SLS里筛选状态码500的日志
- 按错误信息分组统计，发现80%的错误都是同一个空指针异常
- 定位到是某个边界条件没处理：用户没选身份证号就提交了订单
- 加了参数校验后，错误率直接降到0
3.3 案例三：闸机离线问题
现象：景区反馈某几台闸机偶尔刷不开票，过几分钟又自己好了。
用SLS排查过程：
- 按闸机设备ID筛选日志
- 发现这几台闸机的请求经常超时
- 结合网络监控，发现是闸机所在的景区地下室WiFi信号不稳定，偶尔断网
- 给闸机加了本地缓存和离线模式，断网时也能正常检票
四、SLS高级用法
4.1 实时告警
我们配置了几个关键告警规则：
- 5分钟内500错误超过10个，发钉钉告警
- 接口平均响应时间超过500ms，发短信告警
- 日志采集中断超过10分钟，发告警
这样问题刚出现我们就知道了，不用等用户投诉。
4.2 日志可视化
我们用SLS自带的仪表盘做了几个监控看板：
- 实时QPS和响应时间趋势
- 各接口错误率排行
- 每日售票量统计
- 闸机检票量热力图
运营和运维同学打开浏览器就能看到全局情况，不用每次都找开发查数据。
4.3 日志归档
我们把超过30天的历史日志自动转存到OSS归档存储，成本只有热存储的1/10。需要查历史数据的时候再从OSS加载回来，非常方便。
五、成本和收益
用了一年SLS，我们算了一笔账：
- 每月日志服务费用：大概200-300元
- 排障时间：从平均30分钟降到5分钟
- 故障发现时间：从用户投诉后才知道，变成主动告警
- 历史日志留存：从只能存7天，变成可以存1年以上
这个投入产出比非常高，对于任何上云的业务系统来说，日志服务都是必选项。
六、总结
阿里云日志服务SLS是我们用过的最省心的云产品之一：
- 接入简单：Logtail一键安装，不用改代码
- 查询快：亿级日志秒级查询，比自己搭ELK集群稳定多了
- 功能全：查询、分析、告警、可视化、归档一条龙
- 成本低：按量付费，小业务一个月也就几百块
做技术运维，最怕的不是出问题，而是出了问题找不到原因。SLS给了我们一双"眼睛"，让系统里发生的所有事情都看得见。后续我们还计划把前端JS错误、小程序日志也都接入SLS，做全链路的可观测性。
