从日志到告警：用华为云 LTS 搭建低成本应用可观测闭环

很多小型应用并不是缺少日志，而是日志散落在各台服务器、各条流水线里：出问题时先花半小时找日志，再花半小时拼时间线，最后才开始真正定位。本文介绍一种低成本做法：把应用日志统一接入华为云云日志服务 LTS，再用查询、告警和归档把“找日志”变成“看结论”，形成从日志到告警的可观测闭环。

一、先定规范，再谈工具

日志好不好用，一半取决于格式。建议在应用层面先约定三条规范：

1. 结构化输出：优先输出 JSON，而不是自由拼字符串。关键字段至少包括时间、服务名、请求 ID、用户标识（脱敏后）、耗时和结果码。
2. 统一时间与级别：时间使用统一时区和毫秒精度；级别只保留 DEBUG、INFO、WARN、ERROR 四档，避免每个模块自造级别。
3. 请求 ID 全链路透传：入口生成一个请求 ID，内部调用、数据库操作和下游请求都带上它。这样一次慢请求的所有日志可以用一个关键词串起来。

示例日志（字段为示意）：

{"time":"2026-11-05T09:00:00.123+08:00","service":"order-api","request_id":"req-20261105-0001","level":"ERROR","code":"DB_TIMEOUT","cost_ms":3120,"msg":"查询订单超时"}

二、接入 LTS：只做三件事

第一，创建日志组和日志流，按服务或环境划分，例如生产环境一个日志组，订单服务、支付服务各一个日志流，避免不同服务互相干扰。第二，在主机或容器侧配置日志采集，把应用日志文件或标准输出采集到对应日志流。第三，做一次端到端验证：触发一条带唯一请求 ID 的测试日志，在 LTS 控制台确认能按请求 ID 查到，再继续往下做。

接入阶段最常见的坑是“采到了但查不到”：多半是日志流选错、采集路径与应用实际输出路径不一致，或者时间字段解析失败导致日志时间错位。先用一条可识别的测试日志验证，比一次性接入十个服务更省时间。

三、用查询把排查变成固定套路

日志接入后，排查不应该每次都从头翻。建议把三类查询固定下来：

• 按请求 ID 查全链路：输入请求 ID，查看同一次请求的入口、调用和错误日志，确认耗时集中在哪个环节。
• 按错误码聚合：统计一段时间内 ERROR 日志按错误码、服务名的分布，先看占比最高的错误，而不是先看最新的一条。
• 按耗时分段：查看耗时超过阈值的请求分布，区分是偶发毛刺还是持续变慢。偶发毛刺优先看依赖和资源抖动，持续变慢优先看 SQL、缓存命中率和下游接口。

查询时注意时间范围：范围过大容易被无关日志淹没，范围过小又可能错过前置异常。一般先以故障时间点前后各扩展一段时间为起点，再逐步收窄。

四、告警只报“需要人处理”的事

告警的价值不在于多，而在于收到就值得处理。建议从少量规则起步：

告警通知里至少带上时间范围、服务名、错误码和一条示例请求 ID，收到告警的人不用再问“查哪条日志”。同时要定期复盘：长期无人处理的告警要调阈值或降级，避免告警疲劳让真正的问题被淹没。

五、成本与留存：热查与冷归档分开

日志量随业务增长很快，成本控制的关键是分层。近期日志保留在 LTS 中用于快速查询和告警；超过排查窗口的历史日志可以转存到对象存储归档，需要时再按需取回。这样既保留了审计和复盘能力，又不用为很少被查的历史日志长期支付高频查询的成本。

另外，DEBUG 日志默认不要全量采集到生产日志流。可以在出问题时对特定服务临时放开详细级别，排查结束再收回。日志字段也要做脱敏：密码、令牌、完整手机号和身份证号等敏感信息不应该出现在日志里，宁可在采集前过滤，也不要事后清理。

六、上线前检查清单

• 每个服务都有独立日志流，测试日志能按请求 ID 查到
• 时间、级别、请求 ID 字段齐全，敏感字段已脱敏
• 三类固定查询已保存，团队成员都知道入口
• 告警规则不超过一屏，通知带时间、服务、错误码和示例请求 ID
• 日志留存和归档策略已确认，DEBUG 级别默认关闭

可观测性不是工具堆得越多越好，而是出问题时能最快回答三个问题：影响了谁、错在哪一步、下一步该查什么。先把日志格式、统一接入和少量高质量告警做扎实，再根据实际故障复盘逐步扩展，往往比一开始就搭建复杂大盘更有效。