传统监控带不动分布式架构，快试试这套可观测性玩法！

随着公司业务系统逐步微服务化，微服务带来的分布式架构下可观测性问题越显突出，传统监控手段已不能满足可观测性需求。本文对分布式系统可观测性解决方案进行探讨，通过引入分布式链路跟踪技术，实现Metrics、Tracing、Logging三者融合，很好地解决了系统和业务的可观测问题，并在财富管理领域进行实践，效果明显。
一、引言
微服务架构是近几年受到各行业广泛追捧的技术之一，微服务架构具有轻型化、便捷化、敏捷化等特点，不仅能够适应业务创新和变化的需要，而且易于维护、变更、升级，契合当前证券业务发展的需要。
2019年6月，东方证券发布了gRPC-Nebula服务治理框架，同年，又公布了“大中台”战略。伴随着公司数字化转型的加快，业务发展的加速，传统后台交易系统已不能满足业务快速上线的需要。
为了快速响应业务需求，提供更为灵活的服务支撑，公司对财富管理领域进行了整体架构规划，按照能力边界，形成账户中心、产品中心、财富销售中心、资产中心、交易汇总中心、行情中心及资讯中心7个核心业务中台。各业务中台均基于gRPC-Nebula微服务框架，并通过服务治理平台进行跨中心的服务调用。
在新的分布式架构下，一个前端渠道系统的业务请求，有可能由多个业务中台、多个服务节点配合完成。分布式系统复杂的网状服务调用关系对业务开发、测试、日常运维和业务分析工作带来了新的挑战：
1）研发人员需要从蜘蛛网般的服务调用关系中梳理出特定业务流程的整条链路拓扑，分析各个服务依赖关系，排序关联服务强弱级别；
2）测试人员需要从多节点的运行日志中分析测试执行状况，按时间顺序梳理请求的源头节点，途经节点及异常节点等情况，对测试人员的要求极高；
3）运维人员需要在业务异常发生时，在分散冗杂的事件日志中，准确地判断故障节点、定位故障原因，且需要人工梳理具体业务的请求耗时和各节点及接口耗时；
4）业务人员想做全面、准确的数据分析，需要从多个业务中台获取理财销售业务数据，并需要人工关联业务数据，数据量大，关联难度也大。
本文针对上述分布式架构让传统监控方法、观测方法失效的问题，提出了一种分布式系统可观测性解决方案，并在财富管理领域取得了良好的效果。
二、相关概念
1、可观测性
可观测性起源于几十年前的控制理论，它是关于描述和理解自我调节系统的, 近年来越来越多地应用于分布式IT系统。可观测性是通过检查其输出来衡量系统内部状态的能力。如果仅使用输出的信息就可以估计当前状态，则系统被认为是“可观测的”。

图1 系统组件间关系
图1采用简化图的形式描述了系统间的组成及交互。 从上述交互图可看出，系统的交互行为有如下几种形态：

• 系统内，单组件功能闭环，或组件之间交互；

• 系统间，系统与系统间相互进行交互。

这样，若想通过系统的外部输出了解系统的内部状态，就需要两种形态的信息：

• 组件闭环的信息

• 组件间或系统间流动的信息

第一种形态通常可通过logging或metrics表征，第二种形态就需要在流动的信息中增加标记通过tracing来表征。
因此，能够对logging、tracing、metrics三种类型的观测数据进行有效融合与表征，即能解决可观测性问题。
2、可观测性的三大支柱
Peter Bourgon在2017 Distributed Tracing Summit发表的一篇博文，简洁扼要地介绍了指标（Metrics）、链路（Tracing）、日志（Logging）三者的定义和关系，这三种数据在可观测性中都有各自重要的作用，并相互促进。

• 指标数据（Metrics Data）

提供量化的系统内/外部各个维度的指标，一般包括分别Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和Summary（概要）等。

• 日志数据 ( Logging Data）

提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。

• 跟踪数据（Tracing Data）

提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。一个Trace有唯一的traceID，且由多个 span组成。
Logging、Tracing、Metrics三者在解决可观测性问题上缺一不可：基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的日志详情定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可以更早发现、预防此类问题。

图2 logging、tracing、metrics关系
3、OpenTelemetry
2019年5月， OpenTracing和OpenCensus共同发起了OpenTelemetry开源项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等标准化问题，管理观测类数据，如trace、metrics、logs等，其终态是作为CNCF技术委员会可观测性的终极解决方案。
OpenTelemetry没有解决可观测性上的所有问题，但对数据标准、SDK、采集模型进行了规范，对于Backend、Visual、Alert等并不涉及，官方目前推荐的是用Prometheus做Metrics的Backend、用Jaeger去做Tracing的Backend，而对Logging还没有好的解决方案。
三、可观测性解决方案
前文介绍了可观测性的相关概念，下面将对本文提出的可观测性解决方案进行阐述，东方证券可观测平台是基于日志数据,指标数据等底层数据并联合链路追踪技术的可观测性解决方案的落地，是Metrics、Tracing，Logging三者融合技术的实现。
1、技术架构
东方证券可观测平台由数据采集Agent、数据处理分析模块、数据展示模块组成，如图3所示。

图3 东方证券可观测平台架构
采集Agent负责业务系统日志数据和调用链数据的实时采集，每笔请求产生的日志数据和调用链数据traceID相同，日志数据和调用链数据分别发送到kafka的Logging主题和Tracing主题。
数据处理分析模块负责从kafka消费Logging主题的日志数据和Tracing主题的调用链数据，并将日志、调用链原始数据以及索引持久化到ElasticSearch。同时，对原始数据进行统计分析，并将汇总后的结果数据批量插入到Mysql数据库。
数据展示模块负责展示关联的系统日志、调用链数据和指标数据。
2、评估分析
我们从系统入侵性、数据采集一致性、可视化与关联、异常检测与诊断几个维度来评估可视测平台的效果，评估结果见表1：

表1 可观测平台评估表
3、关键技术
1）traceID生成和MDC技术
traceID的生成采用UUID技术，保证了traceID的唯一性。
MDC（Mapped Diagnostic Context，映射调试上下文）是 log4j 和 logback 提供的一种方便在多线程条件下记录日志的功能，也可以说是一种轻量级的日志跟踪工具。
采集日志和调用链时，一笔请求接入，会创建全局唯一的标识符traceID，并将traceID放入MDC，后续同一个线程（包含子线程）输出日志和调用链都能从MDC获取相同的traceID。使用MDC技术，保证了一次请求的所有调用的traceID唯一，相同的traceID能将一笔请求的一次调用过程和日志关联上。
2）日志格式与日志采集实现
日志记录采用统一格式："时间戳" + " " + "[日志等级代码]:" + " " + "日志消息体"。
时间戳必须包含年月日时分秒毫秒，同一个系统必须使用统一的时间戳格式，如"yyyy-MM-dd HH:mm:ss SSS"。
日志等级按照严重程度从高到低，代码依次为：FATAL，ERROR，WARNING，INFO，DEBUG。
日志消息体为日志正文，以json格式存储。日志正文可以是采集的离散事件日志，也可以是采集的调用链数据。
当采集事件日志时，日志正文格式如表2所示。

表2 事件日志基本格式
当采集调用链时，日志正文格式参照表3的分布式调用span基本格式。
日志采集通过自定义LogbackAppender和log4j2Appender，并结合Filter以及Converter来实现。
3）调用链模型与采集实现
用户从app发起一次业务请求后，可观测平台应该记录其所有调用的数据。以理财销售业务为例，用户从app发起基金申购请求，会经过6台服务节点：
1）接受用户请求的前端服务（前端服务节点）； 2）封装业务原子服务的中台（能力中心节点）； 3）提供基础服务的后台系统（后台服务节点）。

图4 分布式调用过程
用户发起一次请求到前端服务A，该请求依赖后端服务B与C，因此服务A分别通过发送GRPC请求到服务B和服务C，B处理完A的请求后将响应返回给A，但是服务B还依赖服务D和E，B再发起两个GRPC请求分别到D和E，D和E处理完毕后回到B，B才继续应答到A，最终A将调用结果返回给用户。分布式调用链的目的，就是将用户一个入口请求及相应的其它后续请求进行网络拓扑绘制，最终生成表示调用关系的调用图。
分布式请求调用会触发多个系统的之间的请求和响应，而将两个服务之间的请求/响应过程叫做一次span，一个多层次调用过程由span01+ span01.01+ span01.02+……多个span组合而成，分布式调用链span的报文格式如表3所示。

表3 分布式调用span基本格式
通过分布式调用过程和span格式，我们理解了span什么时候生成以及怎样生成，接下来的问题是：如何将一笔请求的多个离散的span树形化串联起来。
我们知道span是通过traceID串联起来，并通过spanID与pSpanID的父子关系来树形化的，只要让traceID、spanID、pSpanID有序的传递就可以实现span的树形化串联。
单个服务内多次调用传递：如图4中所示，App前端服务A先后调用财富销售中心B的Span01.01和账户中心C的Span01.02，spanID会递增，同时MDC技术保证了两次调用能获取到相同的traceID。
跨GRPC服务调用传递：如图4中所示，App前端服务A通过GRPC微服务接口调用财富销售中心B时，通过HTTP Header传递traceID、spanID、pSpanID，财富销售中心B服务就可以拿到traceID、spanID、pSpanID并生成正确的span了。
最终，用户从app发起基金申购请求的span时间轴调用链树形图如5：

图5 Span时间轴调用链树形图
4）指标模型与采集实现
指标的采集类型分为系统指标和业务指标，采集周期分为当日指标和历史指标。具体指标模型应当从项目实际需求出发自定义，理财销售业务具体指标模型如表4。

表4 理财销售业务具体指标模型
当日指标的采集通过grafana配置metrics，从ElasticSearch中获取数据并展示；
历史指标的采集通过可观测平台定时的跑批，将跑批维度数据写入mysql，并通过grafana配置metrics从mysql获取数据加以展示。
四、可观测性实现效果
1、分布式调用链可视化
东方证券可观测平台实现了分布式调用链的可视化，通过请求列表，查看具体一笔请求的调用链树形结构图，包括调用链中每个span的应用名、方法名、调用时间、耗时、状态码、状态等指标，并且可以看到span的请求入参和应答出参，具体操作步骤见图6。通过可视化的链路跟踪，测试执行跟踪耗时减少90%。

图6 分布式链路可视化
2、异常检测与诊断
传统的模式下，当监控检测到error关键字并告警，技术人员需要对多个服务节点的日志通过用户请求的关键字进行搜索匹配，分布式模式下，一笔请求涉及了多个应用的多个节点，运维人员需要遍历所有相关应用的每个服务节点并逐个排查，耗损大量人力和时间才能定位到异常应用节点的错误日志。可观测平台提供了异常检测和诊断功能（如下图7所示），当业务出现异常，可观测平台根据错误事件日志告警，找到具体的一条事件日志记录，基于日志记录的traceID精准定位到对应的调用链，并展示出链上异常span，通过异常span的请求入参和应答出参，便可以诊断业务异常原因，大大提升了排查问题效率，异常检测诊断的时间总体减少90%。

图7 异常检测和诊断过程图
3、指标与链路关联
图8是指标和链路的关联图，通过当日服务维度的调用量指标，查看该服务当日每个接口的调用量指标，链接具体某个接口所有的请求列表，并跟踪具体一笔请求的调用链树形图。这种指标和链路关联的场景有很多，比如top10接口耗时指标，统计出调用耗时最多的10个接口，根据接口调用链，分析哪个span耗时最大，然后有针对性地进行性能优化。指标也可以和日志关联，比如top10异常调用接口指标，根据ERROR或者WARN事件日志最多的10个接口，梳理接口调用链的span，进而分析并完善span的日志输出、优化监控告警阈值、增强程序健壮性等。

图8 指标、链路关联图
4、指标可视化
图9是财富销售业务grafana实时指标图，包括系统指标和业务指标，很直观地展示财富销售业务的服务状态和业务情况。通过自定义配置grafana的metrics，可以展示更多定制化的实时指标数据和历史指标数据。

图9 财富销售业务指标图
五、总结
针对在分布式技术架构下进行可观测性的难点，本文提出了一种可观测性解决方案，通过引入分布式链路跟踪技术，实现Metrics、Tracing、Logging三者融合，很好地解决了系统和业务的可观测问题。
该方案具有低入侵性，通过将SDK集成在gRPC-Nebula框架让接入方案简单，能快速接入业务系统。该方案实现了分布式系统的调用链跟踪，实现了日志与调用链深度串联，调用链、日志与指标数据的多方位融合，为开发人员进行系统调用拓扑优化、系统性能优化提供良好的分析基础，为测试执行人员推进测试案例执行大大地提高了效率，为运维人员快速精准诊断定位生产问题提供了便捷的方法，一定程度上，也可为业务人员定制个性化的业务报表。
该方案具有可推广性以及一定的参考价值，普遍适用于解决分布式架构下的可观测性问题。
作者丨黄真正、杨子江、王建、胡长春、樊建 来源丨公众号：上交所技术服务（ID：SSE-TechService） dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]