华为云LTS云日志服务实战：结构化采集、SQL分析与告警联动

一、为什么需要云上统一日志

传统架构中，日志是散的：应用日志落在 ECS 本地 /var/log，中间件日志混在容器标准输出里，云服务日志又各自躺在控制台。排障时要在多台机器上 grep，日志还会被轮转覆盖，事故复盘往往只剩碎片。华为云 LTS（Log Tank Service）把分散日志统一采集、集中存储，再配合类 SQL 检索与告警，可以把"事后 grep"变成"事前感知"。

二、采集接入：Agent 与 SDK 两条路

一是 ICAgent 路径。在 ECS 上安装采集器后，可自动上报主机系统日志与容器标准输出，适合存量应用零改造接入。配置顺序为：创建日志组（按业务线，如 app-order）→ 创建日志流（按日志类型，如 access、error）→ 在主机管理安装 Agent → 配置路径采集规则，支持 /var/log/nginx/*.log 这类通配符与多行合并。

二是 SDK/API 直传。业务代码通过华为云 SDK 直接写入日志流，适合函数工作流、跨 VPC 等无法装 Agent 的场景。

三个易踩的坑：日志流是检索与告警的最小单位，按"应用-环境-日志类型"三级划分最稳妥，划分过粗会导致检索慢、告警互相干扰；采集路径要排除正在轮转的压缩包，否则出现重复采集；多行日志必须配置行首正则（如以时间戳开头），否则一段 Java 异常堆栈会被拆成几十条，后续统计全部失真。

三、结构化：让日志可以被查询

LTS 支持对 JSON 日志自动结构化。若业务输出的是纯文本，可在采集规则中配置正则提取，把 time、level、traceId、cost_ms、uri、status 抽成独立字段。以 Nginx 访问日志为例，按 remote_addr - remote_user [time_local] "request" status body_bytes_sent request_time 的顺序配置正则提取后，status 与 request_time 成为可过滤字段，检索从全文匹配变成字段条件，性能和可读性同时提升。实践经验是：日志中必须带 traceId 并与 APM 打通，否则跨服务排障只能靠时间戳对齐，效率极低。

四、检索与分析：用 SQL 替代 grep

结构化之后，日志就能用类 SQL 聚合，几个高频写法：

1. 错误趋势：level:ERROR | select count(*) as cnt group by time(1m)，出现尖峰时可定位到分钟级。

2. 慢接口 Top N：uri:/api/order | select uri, avg(cost_ms) as avg_ms, count(*) as pv group by uri order by avg_ms desc limit 20。

3. 状态码分布：status >= 500 | select status, count(*) group by status。

4. 阈值统计：* | select count(*) where cost_ms > 1000。

相比 grep，SQL 能在秒级完成百万级日志的聚合，代价是必须先把字段结构化，否则只能退回全文匹配。

五、告警联动：从被动查到主动通知

在日志流上创建告警规则，典型配置为：检索条件 level:ERROR，统计周期 5 分钟，触发条件为结果数大于 10，动作选择对接 SMN 发邮件或短信；也可以推到函数工作流做自动处置，例如触发扩容、回滚或清理缓存。

这里有三点需要注意：日志入库存在分钟级延迟，告警周期要预留延迟，否则会出现虚假恢复；规则过宽会造成告警风暴，应配合静默期与告警抑制；不要把每条 ERROR 都当故障，先按业务影响分级，只对影响核心链路的关键字告警。

六、成本控制

LTS 按写入流量与存储量计费，成本优化有三个动作：采集端过滤 DEBUG 与健康检查日志，通常能砍掉一半以上写入量；把冷数据转储到 OBS，LTS 内只保留 7 天热数据；对高频但无用的字段关闭索引，仅保留排障所需字段。

七、小结

LTS 的价值不在于"存日志"，而在于把非结构化文本变成可聚合、可告警的数据资产。落地顺序建议为：先统一采集，再做字段结构化，然后编写 SQL 与告警规则，最后按成本优化保留策略。跳过结构化直接上告警，很容易在字段混乱中被误报淹没。