阿里云 SLS 日志服务：千里达票务系统全链路可观测实践
多景区共用一个票务平台，日志分散在数十台服务器上，排查一次线上问题往往要登录十几台机器 grep。千里达票务系统接入阿里云 SLS 日志服务后，实现了全链路的日志采集、检索与分析，本文分享实践路径与踩坑经验。
一、业务场景与痛点
- 日志分散：订单服务、支付回调、验票闸机日志分散在不同节点，问题定位靠猜；
- 高峰期故障：节假日订单量骤增时，接口报错、慢请求需要分钟级定位；
- 审计合规：退票、验票等关键操作需要留痕可追溯。
二、方案设计
业务日志 → Logtail采集 → SLS日志库(索引) → 检索/告警/报表
- 采集：ECS 上安装 Logtail，按应用划分 Project/Logstore；
- 索引：为关键字段（订单号、景区ID、手机号、接口路径）建立索引，支持秒级检索；
- 告警：错误率、慢请求数超阈值触发钉钉/短信告警；
- 审计：退票、验票等关键操作单独一个 Logstore，永久保存。
三、关键实现
3.1 关键检索语句
-- 查某景区国庆当天下单失败 TOP 接口
SELECT api, COUNT(*) AS cnt
FROM ticket_app_log
WHERE 景区id = 'SC1001' AND time >= '2026-10-01 00:00:00' AND status = 'FAIL'
GROUP BY api ORDER BY cnt DESC LIMIT 10
3.2 结构化日志规范
统一日志格式为 JSON，包含 order_id、scene_id、api、cost_ms、status、trace_id 等字段，检索效率大幅提升。
3.3 告警配置
错误率连续 3 个周期超过 1%，或 P99 延迟超过 500ms 时触发告警，通知值班群。
四、踩坑复盘
- 索引不全导致查不到：订单号字段未建索引，检索直接报错。解决：上线前统一规划索引字段；
- 日志量膨胀费用失控：debug 日志全量采集，月账单翻倍。解决：按环境分级采集，生产只采集 info 以上，debug 按需临时开启；
- 时区与时间字段混乱：应用打印本地时间，SLS 按 UTC 存储，检索窗口错位。解决：统一时间戳字段为毫秒级 epoch；
- 采集端抖动丢日志：高峰期 Logtail 网络抖动导致部分日志缺失。解决：开启本地缓存 + 设置采集端限流保护。
五、效果与总结
接入 SLS 后，线上问题定位从"小时级"缩短到"分钟级"，退票审计全链路留痕。对千里达票务系统这类分布式业务，日志平台是稳定运维的"眼睛"：先有全链路可观测，才能谈 7×24 稳定保障。SLS 的检索分析能力也让团队告别了"上服务器 grep"的传统模式。
