一条日志从产生到能被分析，中间要经过采集、传输、存储、索引、查询和投递。每一步都可能出问题，而且问题往往要等到用的时候才暴露。阿里云SLS（Simple Log Service，日志服务）把这些步骤放在同一套服务里管理。按链路顺序看，问题通常集中在采集、索引、查询和投递几处。
采集端：配置和日志格式
采集是最容易先出问题的地方。SLS支持Logtail采集Agent、SDK和API，也兼容Syslog、Fluentd、Logstash等开源协议。Logtail常用来采集文件日志和容器标准输出，配置集中在控制台，在Kubernetes集群里用起来比较省事。但采集规则一旦写错，比如日志路径没有覆盖新挂载的目录，或者容器重建后规则没有生效，数据会悄悄缺失，控制台上通常不报错。上线后要专门核对一次，确认目标日志确实进了对应的Logstore。
日志格式是另一个隐患。纯文本日志只能靠关键词硬匹配，字段一多就很难分析。能输出JSON的服务，最好在源头就写成字段化格式。SDK直写适合埋点和审计这类结构化事件，但字段名要提前约定。否则同一个含义会出现user_id、uid、userId三种写法，统计时数字对不上，排查起来很费劲。
索引与吞吐：不要全字段开索引
索引是查询速度和存储成本之间最主要的权衡。没有索引的字段无法按关键词或字段条件检索，开得太多又会推高费用。常见的做法是图省事全字段开索引，写入量一大，成本明显上涨，而真正用来排障的字段可能只有几个。比较稳妥的方式是先梳理排障和报表常用的字段，只给这些字段建索引。上线后再根据实际查询记录调整。
Shard决定写入和消费的吞吐能力，可以按需扩缩。但流量高峰时如果分区数不够，写入会受影响。估算容量时，别只看日常流量，大促或发版这类高峰要单独评估。
查询与分析：先过滤，再聚合
SLS的查询分两层。排查单个请求时，直接输入关键词或字段条件，比如按请求ID拉出整条链路的日志。涉及统计时，要用类SQL语法配合管道符，先过滤再聚合。常见问题是直接在全量数据上做GROUP BY，查询慢甚至超时。更好的做法是先用状态码、时间范围、接口名等条件缩小数据范围，再统计。比如排查500错误，可以先筛出状态码为500的请求，再按接口统计错误次数和平均耗时，取错误最多的前10个接口。查询语法的细节以官方文档为准。写好的统计语句可以保存为仪表盘图表，或者配置成告警规则。
实际场景中的几个坑
大促期间的接口异常
某电商团队在大促当天收到支付成功率下降的反馈。以往的做法是逐台登录服务器翻日志，耗时很长。接入SLS后，团队设置了按接口统计错误率的查询并配置了告警。告警触发后，几分钟内就定位到某个下游库存接口在高峰期超时，进而引发重试风暴。团队调整了超时阈值并启用限流，问题得到控制。排查能压到几分钟，前提是告警和聚合查询提前配好。如果等问题出现了再写查询，时间会长很多。
埋点分析中的字段混乱
某在线教育平台通过SDK以JSON格式上报课程页面的埋点事件。运营同学可以直接在仪表盘里按页面、时段和用户分层查看漏斗，原本需要数天的需求，半天内就能给出初步结论。但如果埋点字段没有提前约定命名规范，后续分析时同义字段会越来越乱，统计口径对不上，结论也就站不住。
审计日志的长期留存
金融类业务对审计日志的保存周期有明确要求。团队把安全相关的Logstore通过投递功能按日期分区写入OSS归档，近期数据保留在SLS里供在线检索。这样既满足合规要求，也不必让全量数据长期占用高性能存储。归档链路出问题时不容易第一时间发现，建议定期核对OSS中的文件是否连续。
成本与落地提醒
日志服务按量计费，费用主要来自写入量、索引和存储时长。以下几点在落地时最容易被忽略。
- 在采集端过滤无效日志。健康检查的重复输出最常见，在源头去掉，比事后清理更省钱。
- 调试日志设置较短的保留周期，审计日志长期归档。两类日志用同一个保留策略，要么浪费，要么不够用。
- 每条业务线建独立Project。权限边界清楚，费用也好核算，账单有问题时能快速找到对应团队。
SLS能把日志变成可检索、可分析的数据，但链路上的每一步都需要有人负责。采集规则、字段命名、索引范围和投递检查，都应该在上线前定下来。
