线上出故障时，修复本身往往不慢，最耗时间的是找日志。几十台服务器各存一份，来回 grep，半天也拼不出完整过程。阿里云日志服务（Simple Log Service，简称 SLS）就是为这种场景准备的。采集、存储、查询、分析和告警都在同一个平台里完成，团队不用再自己搭一套 ELK 集群。
阿里云日志服务覆盖哪些环节
从日志产生到告警触发，大致要经过五段：
- 采集靠主机或容器里安装的 Logtail 客户端完成，另外也支持 SDK、Syslog 等接入方式。
- 存储按 Logstore 分类保存，保存周期可以按需设置。
- 查询分析中，关键词检索适合找具体报错，SQL 适合做聚合统计，比如按接口计算错误率。
- 告警与可视化是把查询结果配置成告警规则，再用仪表盘观察趋势。
- 投递与消费指数据可以投递到 OSS、MaxCompute 等服务，也能通过消费组交给自研程序读取。
一个电商站点的排查思路
下面这个场景是假设的，用来说明操作顺序。设想某中型电商团队有 20 台 Nginx 服务器，每逢大促就出现接口超时，但没人说得清是哪个接口、哪个地区的用户受影响。这时候，先把日志接进来，再让数据说话。
第一步 把日志采到同一个地方
每台服务器装上 Logtail，把 Nginx 的 access.log 和 error.log 分别采集到同一个 Project 下的两个 Logstore。采集前一定要配好日志格式，格式对不上，字段就解析不出来，后面的 SQL 写得再好也用不上。
接好之后，先到控制台确认 Logstore 里有数据，字段也齐全，再开始写查询。
第二步 用 SQL 聚合找出异常接口
团队先跑了一条查询，统计近 15 分钟内各接口的平均响应时间和 5xx 错误比例。
* | SELECT request_uri, avg(request_time) AS avg_rt, count_if(status >= 500) * 100.0 / count(*) AS err_rate FROM log GROUP BY request_uri ORDER BY err_rate DESC LIMIT 10
结果里下单接口的错误率排在最前，比其他接口高出一截。排查范围因此从整个站点缩小到了这一个接口。
第三步 把查询变成告警
确认问题接口后，把这条查询保存为定时任务。下单接口的 5xx 比例一旦超过阈值，系统就通过短信和钉钉群通知值班人员。
阈值怎么定，要看平时的基线。定得太敏感，夜里会被频繁吵醒；定得太松，告警就形同虚设。上线前可以用过去几天的数据手动跑一遍查询，看看这个阈值会触发几次。按这个设定，大促时告警有机会早于用户投诉出现，值班人员就能及时扩容下单服务。
接入前后要注意的几件事
- 先规划 Project 和 Logstore，按业务或环境划分，不要把所有日志堆在一起。后期做查询和权限管理会省很多事。
- 控制日志量，生产环境里调试日志要关闭或调低采样率。否则存储和查询费用涨得很快，而且大部分内容没人会看。
- 统一日志格式，JSON 这类结构化日志比自由文本好解析。字段名在团队内提前定好，写查询时就不用反复猜。
- 最小化权限，通过 RAM 子账号只授予所需 Logstore 的读取权限。日志里常会有用户信息和请求参数，不要让人随意翻看。
什么团队适合用
如果业务已经跑在阿里云上，想快速搭起日志监控，阿里云日志服务是省心的选择。它按量计费，不用维护底层集群。如果团队日志量很大，又已经有成熟的 Elasticsearch 体系，可以先用它做采集和告警，再决定要不要迁移。
