指标、日志、链路是服务可观测性的三大支柱，在服务稳定性保障中，通常指标侧重于发现故障和问题，日志和链路分析侧重于定位和分析问题，其中日志实际上是串联这三大维度的一个良好桥梁。
但日志分析往往面临成本和效果之间的权衡问题，没有完美的方案只有适合的方案，本文将结合实战经验，介绍一种日志分析的实现，分析如何在稳定性保障中用好日志这个维度，以及日志如何与指标、链路相互配合形成故障定位的最佳实践。
核心要点
- 日志分析不能只追求“全量采集、全量计算”，还要考虑规范化、管理成本和存储计算成本。
- 在故障处理场景中，网关日志通常更规范、靠近用户端，适合用于生成流量、成功率、延迟等关键指标。
- 日志、指标和 Trace 需要互相下钻：指标发现异常，日志解释请求细节，Trace 继续定位调用链路中的异常点。
- Flashcat 的实践重点是复用存量数据源，把指标、日志、链路和事件串到北极星、灭火图等故障定位场景里。
日志分析的主要难点
| 难点 | 具体表现 | 对稳定性保障的影响 |
|---|---|---|
| 规范问题 | 服务模块语言和框架各异，日志格式不统一 | 很难直接做统一查询、统计和聚合分析 |
| 管理问题 | 微服务模块众多，日志收集和管理复杂 | 故障时不知道该看哪个模块、哪类日志 |
| 成本问题 | 日志保存和计算分析消耗大量存储与计算资源 | 全量长期保存、全量复杂计算的成本较高 |
日志分析方案
本文推荐一种在稳定性保障中经过考量和实战的日志分析方案。它不是把所有日志都当作同等重要的数据来处理，而是围绕故障处理路径，让日志、指标和 Trace 互相补位。
故障处理场景中，日志分析的核心思路如下：
| 路径 | 做法 | 价值 |
|---|---|---|
| 日志到指标 | 基于网关日志分析接口、域名、渠道、端等维度的流量、成功率、延迟 | 把原始日志转化为可持续观测的健康指标 |
| 指标到大盘 | 将网关日志计算出的维度指标用于全局服务大盘或大屏 | 观察服务全局状态，及时发现异常趋势 |
| 指标到日志 | 指标来自日志计算，发现趋势异常时可调出对应时间日志原文 | 从异常指标回到原始请求细节 |
| 日志到链路 | 日志原文带有 traceid、模块或接口信息，可打通 Trace 系统 | 查看具体请求或模块调用链路，分析底层来源 |
| 链路到日志 | 在 Trace 异常点继续下钻查询日志系统 | 调出对应模块和接口日志，做进一步判断 |
| 日志到特征 | 基于网关日志做来源 IP、接入层实例、upstream 等维度的特征分析 | 判断异常是否在某类特征上聚集，辅助止损和追查 |
优点和权衡
这个方案的优点和权衡点在于：
- 分析性价比高：网关日志通常较为规范，例如 Nginx 日志，也更容易治理。同时网关日志更靠近用户端，从分析价值和治理难度看，适合作为关键入口。
- 治理性价比高：程序模块日志因为语言和格式各异，治理难度高，分析价值也容易打折扣。治理重点可以转向落地 Trace 系统。程序模块使用 Trace SDK 或 Agent 后，可以输出规范的 Trace 信息和有价值的定位信息。落地 Trace 也有成本，但对 Java 这类语言，可以使用 javaagent 方案做到无侵入实现。
- 扬长避短：程序模块日志原文可能格式各异、不够标准，但异常日志仍然是判断问题原因的重要依据。因此这部分日志更适合在合适的分析步骤中查询调出，它的价值在原文信息，而不在统一分析计算。
该方案以日志为中心，实现了一条日志、指标、Trace 相互串联的问题发现和分析路径。这条路径也是故障问题分析的典型路径。
同时从方案的落地和推动成本上来讲也是一个比较合适的取舍。如果可观测产品支持好这条路径信息的串联，会大幅提升异常问题定位分析的效率。
方案落地要点
混合云资源、观测系统众多，是目前很典型的企业基础设施现状，在此基础上要实现这个方案可能需要重点解决以下几个问题：
- 存量系统如何打通：指标、日志、Trace 都可能已经有各自独立的系统，如何串联融合不同系统的数据？
- 云上云下如何打通：很多企业使用私有化和公有云的混合云方案，日志可能同时使用私有化 ELK 和云上日志系统，例如阿里云 SLS 和腾讯云 CLS。
- 风险成本如何控制：如果全部推倒重建，用一套系统替代原有系统，风险和成本都太高，周期也不可控。
产品实践
这里介绍快猫星云的 Flashcat 是如何解决这些问题的。
- 数据源抽象：常见的开源和云上现有可观测系统都可以作为数据源注册到 Flashcat。
- 数据交互：Flashcat 底层通过 API 和各数据源交互。
- 统一分析：上层对来自各个数据源的数据，特别是日志数据，做统一灵活的配置和分析，生成各类自定义维度报表和指标数据。
- 指标建设：日志生成的指标数据可以配置到北极星、灭火图，作为业务健康状态和系统健康状态的观测指标。
- 下钻关联：从 Flashcat 的北极星和灭火图可以下钻到上面描述的问题分析路径，实现从业务异常发现、系统异常范围收敛，到具体问题分析确认的全链路串联。
Flashcat 问题下钻分析路径
FAQ
Q1：为什么推荐从网关日志开始做分析？ A：网关日志通常更规范、更靠近用户端，也更容易治理。它适合提炼流量、成功率、延迟等指标，用作服务全局状态观测入口。
Q2：程序模块日志还需要采集吗？ A：需要，但它更适合在具体排查步骤中查询原文。程序模块日志格式往往不统一，价值主要在异常上下文，而不是统一聚合计算。
Q3：日志、指标和 Trace 应该如何配合？ A：指标用于发现异常，日志用于解释请求细节，Trace 用于定位调用链路中的异常点。三者通过时间、接口、traceid、模块等上下文互相下钻，才能形成有效故障定位路径。
总结
本文介绍了稳定性保障中日志分析系统建设面临的问题、挑战、需求和权衡取舍。核心结论是：日志分析不是越全越好，而是要服务故障定位路径。
围绕网关日志构建关键指标，再把指标、日志、Trace 和特征分析串联起来，可以在成本可控的前提下提升异常发现和问题定位效率。Flashcat 的产品实践，则是通过数据源抽象、统一分析和北极星、灭火图下钻，把这条路径产品化。
