指标、日志、链路是服务可观测性的三大支柱，在服务稳定性保障中，通常指标侧重于发现故障和问题，日志和链路分析侧重于定位和分析问题，其中日志实际上是串联这三大维度的一个良好桥梁。
但日志分析往往面临成本和效果之间的权衡问题，没有完美的方案只有适合的方案，本文将结合实战经验，介绍一种日志分析的实现，分析如何在稳定性保障中用好日志这个维度，以及日志如何与指标、链路相互配合形成故障定位的最佳实践。
核心要点
- 日志分析的关键不是“把所有日志都做复杂计算”，而是在成本可控的前提下，把最有价值的日志转成可观测信号。
- 网关日志通常格式更统一、离用户更近，适合提取流量、成功率、延迟等全局服务指标。
- 程序模块日志的价值更多在原文证据和异常细节，不一定适合全部做高成本分析计算。
- 好的日志分析路径应该能从指标异常下钻到日志原文，再从日志里的 traceid 或模块信息关联到链路追踪。
日志分析方案概览
| 环节 | 输入 | 输出 | 价值 |
|---|---|---|---|
| 日志到指标 | 网关日志 | 流量、成功率、延迟等维度指标 | 构建全局服务大盘和业务健康视图 |
| 指标到日志 | 指标异常时间窗口 | 对应日志原文 | 快速确认异常请求特征 |
| 日志到链路 | traceid、接口、模块信息 | 请求调用链路 | 定位异常发生在哪个下游或模块 |
| 链路到日志 | trace 异常点 | 模块详细日志 | 复核底层错误和上下文 |
| 日志到特征 | 网关日志维度 | IP、实例、upstream 等聚集特征 | 支持止损和进一步追查 |
日志分析难点
日志分析在企业落地时，通常会遇到三个问题：
- 规范问题：服务模块的语言和框架各异，日志格式不规范，分析困难。
- 管理问题：微服务模块众多，日志收集、权限、保留周期和查询入口都需要统一管理。
- 成本问题：日志保存和计算分析会消耗大量存储与计算资源，使用成本高。
日志分析方案
本文推荐一种在稳定性保障中，经过考量和实战的日志分析方案。故障处理场景中日志分析的核心思路：
- 日志到指标：基于网关日志分析接口、域名、渠道、端等维度的关键指标，包括流量、成功率和延迟。
- 指标到大盘：把网关日志计算出的维度指标用于全局服务大盘或大屏建设，用来观察服务整体状态。
- 指标到日志：这类指标来源于日志计算，天然可以关联到对应时间窗口的日志原文。发现指标趋势异常时，可以快速调出相关日志。
- 日志到链路：日志原文中如果带有 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：日志可以提供异常上下文，链路追踪可以提供请求调用路径。日志中带有 traceid 或模块信息时，就能从日志跳到 trace，再从 trace 异常点回到具体模块日志。
Q3：为什么不建议直接替换所有存量系统？
A：企业常常已经有指标、日志和 trace 的多个存量系统。直接替换风险高、周期长、成本不可控。更稳妥的方式是先做数据源抽象和上层统一分析，再逐步治理底层系统。
