线上出问题时，很多团队第一反应还是登录服务器翻日志。服务拆成几十个微服务、分散在多个可用区之后，这种办法很快就不够用了。阿里云日志服务（Log Service，简称 SLS）把采集、存储、查询、分析和告警放在同一个平台里，团队不用在几台机器之间来回切换。采集之后怎么查、怎么告警，决定了这套系统能不能真正帮上忙，下面重点讲这两件事。
先理解 Project 和 Logstore
日志服务用 Project 和 Logstore 组织数据。Project 一般按业务或环境划分，是个管理单元。Logstore 存放一类日志，比如应用日志、访问日志或审计日志。每个 Logstore 的保存期限可以单独设置，范围是 1 天到 3650 天。查询和告警都是围绕 Logstore 展开的，所以建之前要想清楚哪些日志放在一起。
采集端怎么接
采集用 Logtail 采集器，读取 ECS、容器和自建服务器上的日志文件。Kubernetes 集群可以用 DaemonSet 方式部署采集器，新增的 Pod 会自动生效，不用逐个配置。
查询语句怎么写
查询语句由检索和 SQL 两部分组成，格式是 关键词 | select …。竖线前面用关键词先过滤，竖线后面用 SQL 做聚合统计。先把范围缩小，再算数，结果也更容易核对。
查询结果确认无误后，可以保存为图表，再把几张图组合成仪表盘。放在值班大屏上，延迟和错误率的变化一眼就能看出来。
告警怎么设
告警其实就是给查询结果加一个判断条件。写查询时，最好让结果是一个明确的数字，比如某个接口的 P99 延迟或错误数。然后设定阈值，条件满足就触发通知。通知渠道包括短信、邮件和钉钉机器人，值班人员在哪里都能收到。
阈值定得太松，问题已经影响用户才响；定得太紧，半夜总被噪音吵醒，值班的人很快就会习惯性忽略。这个平衡要结合历史数据来调。第一版可以先宽松一点，观察一段时间后再收紧。
案例：订单接口超时的排查过程
下面是一个示意场景，数据和字段名均为虚构。某电商团队在大促期间收到告警，下单接口的 P99 延迟从 200 毫秒涨到了 3 秒。以前遇到这种情况，只能逐台登录服务器用 grep 查，这次直接在日志服务里完成排查。
排查大致分三步：
- 执行 request_uri: /order/create | select date_trunc(‘minute’, __time__) as t, avg(cost) as avg_cost group by t order by t，按分钟看平均耗时，确认延迟从 14:02 开始上升。
- 按 upstream 字段分组，发现延迟集中在调用库存服务的请求上，排查范围一下子缩小了。
- 查库存服务的错误日志，找到连接池耗尽的报错。再对照变更记录，发现一次配置调整把连接池上限从 100 改成了 10。
回滚配置后，延迟几分钟内恢复，整个过程大约二十分钟。之后团队把“库存服务 P99 超过 1 秒”加入告警规则，下次同类问题在用户感知之前，就会有人收到通知。
接入前要先定下来的事
- 日志格式：JSON 最容易解析。文本日志要先配置正则或分隔符解析规则，否则字段无法检索，告警条件也写不出来。
- 索引：只有需要按字段筛选的内容才建索引。全文索引和字段索引都会增加存储和计费，给常用字段建索引就够了。
- 保存期限：排查通常只看最近几天的数据，审计日志则要按规定保留。两类数据最好分到不同的 Logstore，各自设置期限。
- 敏感信息：手机号、令牌和密码应在采集端脱敏。控制台权限也要按角色收紧，别让无关的人看到原始日志。
其他常见用途
- 安全审计：保存登录、权限变更等操作记录，并把保存期限设得足够长，以满足合规要求。
- 业务分析：统计接口调用量、转化路径或地区分布，为产品决策提供参考。
- 数据加工与投递：写入前可以过滤、脱敏或拆分日志，也可以投递到 OSS 或 MaxCompute，供离线分析使用。
成本控制
日志服务按写入量、存储量和索引流量等维度计费。日志量最容易失控的情况，是调试级别的日志长期开着。建议线上默认使用 INFO 级别，排查时临时切到 DEBUG，并约定到期自动恢复。健康检查这类重复请求的日志，可以在数据加工环节过滤掉，没必要全部写入。
从哪里开始
先挑一个最常出问题的服务，接入 Logtail，建好 Logstore 并配置索引，再做一张包含延迟和错误率的仪表盘。这个服务稳定运行后，再逐步推广到其他服务。
