可观测性建设实践之 - 日志分析的权衡取舍

指标、日志、链路是服务可观测性的三大支柱，在服务稳定性保障中，通常指标侧重于发现故障和问题，日志和链路分析侧重于定位和分析问题，其中日志实际上是串联这三大维度的一个良好桥梁。

但日志分析往往面临成本和效果之间的权衡问题，没有完美的方案只有适合的方案，本文将结合实战经验，介绍一种日志分析的实现，分析如何在稳定性保障中用好日志这个维度，以及日志如何与指标、链路相互配合形成故障定位的最佳实践。

日志分析难点

1）规范问题：服务模块的语言和框架各异，日志格式不规范，分析困难；
2）管理问题：微服务模块众多，日志收集和管理困难；
3）成本问题：日志的保存和计算分析需要消耗大量的资源，主要是存储计算资源，使用成本高；

日志分析方案

本文推荐一种在稳定性保障中，经过考量和实战的日志分析方案。故障处理场景中日志分析的核心思路：

日志到指标：基于网关日志分析接口、域名、渠道、端等维度的关键指标（流量、成功率、延迟）；
指标到大盘：网关日志分析计算出的维度指标（流量、成功率、延迟）用作全局服务大盘/大屏的建设，用以观察服务的全局状态；
指标到日志：这类维度指标的生成来源于日志计算，天然可以实现指标到日志的关联，在发现指标趋势异常时，能够方便的调出相应时间的日志原文；
日志到链路：具体的日志原文中带有 traceid，或模块和接口的信息，基于此信息可打通trace系统，调出具体请求或模块的trace信息，展示请求的调用链路，分析调用异常的底层来源；
链路到日志：在trace的异常点下钻查询日志系统，调出对应模块和接口的详细日志，做进一步的异常判断；
日志到特征：另一个分析思路，基于网关日志做异常指标的特征分析，如，下单接口异常，则自动分析异常请求在来源IP、接入层实例分布、upstream分布等等维度上是否有聚集特征或特征变化，如果在某个特征上出现了特征的变化和聚集，则可以针对这类特征确定止损的方案或进一步追查的方向；

问题追查典型路径

优点和权衡

这个方案的优点和权衡点在于：

分析性价比高：网关日志通常较为规范，如Nginx日志，并且也容易治理，同时网关日志也最为靠近用户端，无论从分析和治理的难易度，以及分析的价值上看，都是最佳的选择；
治理性价比高：程序模块日志由于语言格式各异，治理难度高，且分析的价值大打折扣。治理的重点可以转移到落地trace系统上来，程序模块一旦使用了trace的sdk或agent，则可以输出规范的trace信息和有价值的定位信息。落地trace也会有相当的成本，但对类似Java这类语言，成本会低很多，可以使用javaagent方案做到无侵入实现；
扬长避短：程序模块的日志原文格式可能各异也不标准，但异常日志的信息仍然是判断问题原因的重要依据，因此在这个过程中能在合适的分析步骤中查询调出即可，这部分日志的价值优势在于原文信息而不在于分析计算；

该方案以日志为中心，实现了一条日志、指标、trace相互串联的问题发现和分析路径，这条路径也是故障问题分析的典型路径。

同时从方案的落地和推动成本上来讲也是一个比较合适的取舍。如果可观测产品支持好这条路径信息的串联，会大幅提升异常问题定位分析的效率。

方案落地要点

混合云资源、观测系统众多，是目前很典型的企业基础设施现状，在此基础上要实现这个方案可能需要重点解决以下几个问题：

1）存量系统如何打通：指标、日志、trace都可能已经有各自独立的系统，如何串联融合不同系统的数据？
2）云上云下如何打通：很多企业使用了私有化和公有云的混合云方案，日志可能也同时使用了私有化的ELK和云上的日志系统，如阿里云SLS和腾讯云CLS；
3）风险成本如何控制：如果为此要全部推导重建，用一套系统替代原有系统，风险和成本都太高，周期长也不可控；

产品实践

这里介绍快猫星云的 Flashcat 是如何解决这些问题的。

数据源抽象：常见的开源和云上现有的可观测系统都可以作为一个数据源注册到 Flashcat；
数据交互：Flashcat 底层通过 API 和各数据源交互；
统一分析：上层对来自各个数据源的数据，特别是日志数据做统一灵活的配置和分析，生成各类自定义维度的报表和指标数据；
指标建设：日志生成的指标数据可以配置到北极星、灭火图，作为业务健康状态和系统健康状态的观测指标；
下钻关联：从 Flashcat 的北极星（业务健康度量化）和灭火图（系统健康度量化）可以下钻上面描述的问题分析路径，实现从业务异常的发现、到系统异常的范围收敛，到具体问题的分析确认的全链路串联；

Flashcat 统一日志分析平台