华为云 LTS 日志服务实践：日志采集、检索与告警的落地

一、背景与痛点

微服务架构下，一次用户请求可能横跨网关、几十个服务实例和多个可用区。当线上出现偶发超时时，最痛苦的不是修 bug，而是找日志：登录一台台 ECS 翻 tail -f、在跳板机上 grep 多个目录、再手动拼出时间线。日志散落、格式不统一、单机日志随容器销毁而丢失——这是大多数团队从"能跑"走向"稳定运行"时必须跨过去的坎。

华为云 LTS（Log Tank Service，云日志）的定位就是解决这件事：把日志的采集、存储、检索、分析、告警做成一站式服务，让"按 traceId 串起一次请求全链路"从人肉操作变成一次查询。

二、核心概念与组件

理解 LTS 只需要先分清四个概念：

1. 日志组（Log Group）：管理单元，通常按项目或环境划分，如 prod-order、staging-pay，决定权限与配额归属。
2. 日志流（Log Stream）：真正存放日志的容器，保留周期按流配置（1~365 天）。建议一个服务一个流，避免混流后检索条件越来越复杂。
3. 采集方式：主机场景用 LTS Agent（安装后按目录+文件通配采集），容器场景用 CCE 的 iLog 组件采集容器标准输出，已有 Kafka 体系的可以直接走 Kafka 协议写入，还有 SDK/API 直写。
4. 检索与告警：基于类 SQL 的分析语法做过滤聚合，告警策略支持按查询结果命中条数、字段值等条件触发，对接 SMN/CCE 短信邮件或 webhook。

三、实操步骤

1. 建组建流

控制台新建日志组 prod-app，下面建两条流：nginx-access（保留 7 天，量大且价值衰减快）、app-error（保留 30 天，排障回溯用）。保留期不要一刀切设 90 天——存储费用按量计费，访问日志一周足够定位绝大多数问题，省下的钱可以留出来给真正需要长留的业务日志。

2. 部署 Agent 采集

在 ECS 上执行 LTS 控制台生成的一行安装命令，Agent 注册后回到控制台配置采集规则：目录 /var/log/nginx、文件 access-*.log。容器侧在 CCE 工作负载里加 k8s-app-log: true 注解（或 iLog 组件的采集规则），标准输出自动落到对应日志流。

经验点：Agent 采集是按 inode 跟踪文件的，日志切割（logrotate）后一定要用 rename+copytruncate 之外的 rename 模式，否则新文件可能不被跟踪，出现"日志停了"的假象。

3. 结构化与检索

原始访问日志是纯文本，先用日志流里的"解析规则"（正则或分隔符）把 ip / time / status / latency 抽成字段，之后检索就从全文 grep 升级为字段查询：

status >= 500 and latency > 800 | select ip, count(*) as cnt group by ip order by cnt desc limit 20

这条查询 30 秒内能回答"刚才那波 5xx 主要来自哪些客户端 IP"。再配合自定义的 trace_id 字段，trace_id: "a1b2c3..." 一条语句即可拉出该请求在网关和所有后端服务上的完整日志，按时间自动排序——这是 LTS 相比"单机 grep"最直接的收益。

4. 配告警，把被动变主动

建议至少先配两条最小告警：

• app-error 流：1 分钟内 ERROR 级别日志 > 20 条 → 短信+邮件，避免单机偶发 error 刷屏但真故障淹没；
• nginx-access 流：5 分钟内 status:5xx 占比 > 10% → 电话/企微 webhook，这基本是用户可感知故障的前 1 分钟窗口。

阈值宁松勿紧，先让告警"值得信"，再逐步收紧。告警风暴比没有告警更伤士气。

四、踩坑记录

时区问题：LTS 存储时间戳是 UTC，控制台展示可以切时区，但写 SDK 自己算 offset 的同学要特别注意，日志"凭空迟到 8 小时"基本都是这里。

大日志行截断：单条日志过长会被截断，Java 服务把整个堆栈打在一行里的要拆行或压缩输出，否则最关键的 Caused by 被截掉。

费用控制：除了保留期，索引字段数量也影响分析性能与费用；对 99% 查询都用不到的字段别建索引，全文索引+少量字段索引是性价比最高的组合。

五、小结

LTS 的价值不在"日志存得下"，而在把排障路径标准化：Agent/iLog 统一入口、字段化检索统一语言、trace_id 统一视角、告警统一出口。按"日志组按环境、日志流按服务、保留期按价值"的原则规划，再配上两条克制的最小告警，多数团队一周内就能把"登录机器翻日志"的肌肉记忆换成一次查询——这才是它最值得投入的地方。