服务器每天产生的日志量很大，访问记录、报错信息和数据库慢查询混在一起。靠人工一行行翻，很难在出事时及时找到原因。阿里云日志服务（SLS，Simple Log Service）可以采集、存储、检索和分析日志，把原始文本变成能统计、告警和做成图表的数据。下面用一个电商大促的案例，说明阿里云日志分析在实际排障中怎么用。
日志分析解决什么问题
很多团队的日志平时没人看，等用户投诉到客服，才登录机器用 grep 去找。这时通常已经错过最关键的时间窗口。日志分析主要做两件事：出问题时能快速找到原因，平时能提前发现异常趋势。
常见用法有四类：
- 故障排查：查某个时间段内 5xx 错误集中在哪些接口、哪些机器上。
- 性能分析：统计接口耗时的分位数（P95、P99），找出拖慢整体响应的那部分请求。
- 业务监控：统计下单成功率、支付回调数量，确认业务指标是否正常。
- 安全审计：检查异常登录、短时间内高频访问的 IP。
案例：大促期间下单接口变慢
某电商团队在大促第一天晚上八点收到告警。下单接口的平均响应时间从 200 毫秒涨到 1.8 秒，部分用户看到“提交失败，请重试”。团队用阿里云日志服务按下面的顺序排查。
第一步：确认错误集中在哪里
团队先在 SLS 查询界面筛选最近一小时的网关日志，条件是 HTTP 状态码大于等于 500。统计显示，超过 80% 的错误请求都落在 /api/order/submit 这一个接口上。原本要查的几十个接口，一下子缩小到一个。
如果你的日志字段名不同，可以用类似下面的写法做分组统计（字段名需要换成你自己的）：
status >= 500 | SELECT request_uri, COUNT(*) AS cnt GROUP BY request_uri ORDER BY cnt DESC
第二步：按机器拆开看耗时
接着团队统计这个接口在各台后端实例上的耗时分布。八台机器里有两台的 P99 超过 5 秒，其余机器基本正常。这两台机器的日志字段里都带着同一个数据库连接池地址。问题很可能出在数据库连接上，而不是接口代码本身。
这一步的提醒是：统计时一定要按实例分组。如果只看整体平均值，两台慢机器会被另外六台拉平，问题就看不见了。
第三步：和数据库慢查询对齐时间
团队把数据库审计日志也接入同一个日志项目，然后按时间窗口对齐两边的记录。同一时段里出现大量对订单表的查询，而且都没有走索引。原因是营销活动上线时，运营人员新增了一个按“优惠券编码”查询的条件，但没有给这个字段建索引。
团队当晚加了索引，并把那两台异常机器的连接池上限调到合理值。十分钟后，下单接口的 P99 回到 300 毫秒以内，错误率恢复正常。
线上给大表加索引要留意锁表和执行时间。如果表很大，最好用在线变更工具或者在低峰期执行，并先在测试库确认执行计划。
复盘时，团队在 SLS 里配了两条告警。下单接口 5xx 比例超过 1% 时通知值班人员；五分钟内慢查询数量超过阈值时发送提醒。另外做了一块仪表盘，显示接口耗时、错误分布和慢查询趋势。下次再出现类似情况，值班人员几分钟内就能看到异常。
上手阿里云日志分析的几条建议
- 先统一日志格式。各服务的字段名和时间格式不一致，查询会很费劲。打印日志时就固定字段，例如 request_id、status、latency_ms、user_id。已经上线的老服务不必一次全改，先改核心链路。
- 给关键请求带上 request_id。网关、应用和数据库的日志用同一个 ID 串起来，排查时才能按一个请求看完整路径。跨服务调用时，要确认 ID 会被透传下去。
- 先建少量高价值告警。告警太多，值班人员很快就会麻木。先盯住核心接口的错误率和耗时，确认误报少了以后再扩展到其他接口。
- 控制日志量和保存时长。线上打开 DEBUG 级别会迅速增加存储费用，也会让有用的信息被淹没。一般只保留 INFO 及以上级别，保存周期按审计和排障需要来定。
- 把常用查询存成模板。“5xx 按接口分组”“按实例看耗时”这类查询，保存下来新人也能直接用。排障经验不该只留在某一个人的脑子里。
结语
阿里云日志分析的作用，是把分散在各台机器上的日志集中起来，让问题能被搜索、被统计、被预警。上手不难，先想清楚要回答什么问题，再去设计日志字段和查询条件。从最痛的一个场景开始，逐步扩展，通常比一开始就追求大而全更稳妥。
