基于OpenTelemetry+Jaeger的分布式系统调用链路监控方案

2023-09-06张爱华白金峰

软件工程 2023年9期

张爱华　白金峰

关键词：分布式系统;链路监控;OpenTelemetry;Jaeger

中图分类号：TP391 文献标志码：A

0 引言（Introduction）

随着互联网移动应用的兴起，一种新的计算机应用系统服务架构-分布式架构应运而生。但是，随着分布式架构方案的使用越来越多，该架构的缺点慢慢显现出来，首当其冲的就是调用链路的问题[1]。随着分布式系统中服务数量的增加，其相互调用的关系网络也变得错综复杂，无论是系统的开发人员，还是维护人员，都因为无法追踪一个请求的调用链路而犯难。

本文针对这一情况，提供了一种通用的调用链路监控方案，细化每一个服务接口的粒度。在本方案中，既可以通过可视化界面的方式查询应用接口的调用流程、错误率、负载强度，又可以通过图示的方式查看系统的调用结构。

通过使用本文中提供的监控方案，系统开发人员可以快速追踪系统中任意服务的调用步骤、执行的命令或者参数，方便快速排查问题;运维人员可以实时查看系统中每一个服务接口的负载压力与错误率，可以提前预判服务状态。

1 系统需求（System requirements）

分布式链路监控系统的主要用户为系统的开发人员和维护人员。图1为系统开发人员的需求。系统开发人员希望使用该系统查看应用的调用链路、接口耗时、调用步骤中的应用信息、参数、环境信息等，还需要查看系统的整体调用网络。

2 系统设计（System design）

2.1 技術路线

系统服务端采用B/S架构，前端和后端基于HTTP协议进行通信，数据格式使用JSON。前端使用的是NodeJS+React技术，通过NodeJS查询Server端数据，然后结合React构造的模块化页面展示实现动态响应。

系统后端使用的是Golang语言，该语言自身的协程设计使其非常适合应用在处理高并发请求环境中，并且构建后的可执行产物体积小、启动方便。

服务埋点以Java应用为例，使用的是Java语言本身支持的JavaAgent方案，通过JavaAgent挂载到应用本身的Java虚拟机（Java Virtual Machine，JVM）中。该方案对应用本身没有任何的代码侵入，业务应用不需要任何改造即可轻松集成Agent。

ElasticSearch是一款分布式的搜索和分析引擎，该引擎可以使链路监控的数据搜集部分与展示部分解耦[1]。Agent在应用层面搜集到的应用运行数据和日志等信息上报给ElasticSearch引擎，引擎对数据进行存储和索引，页面展示部分从ElasticSearch中读取并分析数据，然后展示到页面上。

OpenTelemetry Collector是一款设备无关性的新兴采集器。在以往的分布式系统度量数据采集方案中使用的采集器一般与技术栈绑定，一旦选择了某个技术栈中的一个工具，则后续拓展必须使用该技术栈下的其他工具。例如，在搜集应用日志时，一旦选择了使用filebeat，则后续的日志存储只能选择ElasticSearch，日志展示与分析也只能选择Kibana。OpenTelemetry Collector的出现打破了这一局限性，它支持从多个输入端采集数据，然后通过自定义的Processor处理，处理后又可以从多个输出端输出数据，方便随时替换度量数据的搜集器和分析器。

Jaeger是一款新型的链路分析工具，它包含Agent、Analyzer、QueryUI等组件。本文使用Jaeger的Analyzer和QueryUI组件，其中Analyzer用来分析链路数据和服务的网络结构，QueryUI用来查询和展示分析后的链路和调用网络。

Prometheus是一款存储应用度量数据的工具，它提供了一种基于时间轴的新型数据存储和管理方案，可以很好地记录某一指标随着时间变化而变化的值[2];同时，它还提供一套类似于结构化查询语言（Structured Query Language，SQL），通过使用其提供的查询语言可以方便地从各个维度查询度量数据。

2.2 系统架构

2.2.1 整体架构

系统的整体架构如图 3所示，系统中存在多个业务应用（Business Application），并且每一个业务应用都挂载了一个Agent用来收集应用的度量数据和运行时的状态数据[3]。Agent收集数据后会发送给OpenTelemetry Collector，Collector对数据进行处理后，根据不同的数据类型分别发送给Jaeger Collector 搜集器和Prometheus 数据库。JaegerCollector对数据做筛选，加标签处理后存入ElasticSearch中等待分析和展示，ElasticSearch中的数据会定时由Spark Job获取并计算调用网络，计算后的结果会再次存储至ElasticSearch中。Jaeger Query 服务负责根据用户的需求将数据从ElasticSearch和Prometheus中取出并通过用户界面（UserInterface，UI）进行相应的展示。

2.2.2 高可用节点集群方案

为保证系统处于高可用状态（如图 4所示），系统中的OpenTelemetry Collector、Jaeger Collector和Jaeger Query等组件都可以使用集群化部署，根据系统压力进行水平扩容[4]。

同时，开源组件ElasticSearch和Prometheus也支持高可用的集群化部署，多节点通过访问单一存储系统实现数据一致性，开源组件高可用方案如图 5所示[5]。

3 系统实现（System implementation）

3.1 节点分配

如表1所示，搭建一个最小集群共需要6台机器，可以选择在虚拟机中创建这些机器并分配为固定IP。其中，用来部署ElasticSearch的机器需要分配足够的内存（建议不小于8 GB）和存储（不小于50 GB）;用来部署Prometheus的机器需要分配足够的存储（不小于50 GB）;用来部署Collector的两台机器需要分配足够的CPU（不小于双核），以满足运算需要。

3.2 应用的配置与部署

由于开源组件ElasticSearch和Prometheus的部署方案在官网或者网络上有很多相关资料，故在此不做赘述。OpenTelemetry Collector的部署重点是配置文件的编写，需要配置Collector的输入监听、数据处理器和输出监听。输入监听使用的是Jaeger格式数据的监听方案，数据处理器使用SpanMetrics方案将度量数据与链路数据进行拆分，输出监听分别需要Prometheus 和Jaeger Collector。配置文件的具体内容如图 6所示。

Jaeger Collector可以使用官网上的二进制文件，然后通过命令行参数的方式直接启动该应用即可，主要的命令行参数包括指定存储类型、索引前缀名称等。将下载好的二进制文件放在/opt/app/jaeger/jaeger-collector中，则可以使用图7中的命令启动Jaeger Collector。Jaeger Query 和Jaeger UI的启动方式与Jaeger Collector的启动方案类似，这里不再赘述。

3.3 业务服务Agent配置

以Java应用为例，使用Java Agent的方案进行配置[6]。该方案需要准备收集数据的Agent.jar和应用相关的参数配置文件，应用配置文件内容详解如图 8所示。

更新参数配置文件后，需要对业务服务的启动命令进行改造，将agent和agent使用的应用参数配置文件加入启动命令中，应用启动参数的修改如图 9所示。

4 系统测试（System testing）

4.1 服务应用Agent测试

系统采用的是Agent挂载到业务应用上的启动方案，所以对Agent的测试可通过应用打印的启动日志进行查看[7]。在应用启动的过程中，可以通过观察应用的输出日志判断Agent是否成功挂载到应用上。经测试，Agent已经成功挂载到应用上。

4.2 链路监控系统测试

对链路监控系统的测试，可以通过访问应用接口和提升应用接口压力的方案实现。通过访问业务应用的接口，然后在本系统中查看追踪到的链路即可确认链路上报与监控功能是否可用[8]。经测试，系统的链路监控功能可用，链路监控页面测试结果如图10所示。

4.3 指标展示测试

对系统的指标展示的测试，可以通过给指定应用增加访问压力迫使指标数据出现波动的方案实现。经测试，系统指标展示功能可用。系统指标数据页面测试结果如图11所示。

4.4 其他测试

除了上述几项重要功能测试，本文还对系统的其他分支功能如链路步骤查询、链路标签查询、链路中某一步骤参数与结果分析、链路对比、服务网络分析等进行测试，测试结果均正常，各项功能均可用。