突击完成链路可观测的建设任务

从单体架构到集群架构再到微服务架构，业务越来越庞大，也越来越复杂。加之云原生时代背景下，ServiceMesh、Serverless(FaaS)等新技术的出现，业务的复杂度远远超越了个人的人力极限，大规模应用更是需要成百上千专业的人协作才能完成。应用稳定性链路中的影响因素也越来越多，一个应用相关的稳定性指标从基础设施到中间件，再到应用自身的模块、组件、配置、网关等，每个环节都会有致命的因素导致应用无法正常提供服务。

依赖传统的稳定性体系建设，通过日志服务查看业务日志，通过各个中间件去感知中间件的运行状态，再通过网络、存储、操作系统层面的监控来查看基础监控信息，这些信息每一个都只能片面的代表业务链路中的某一个节点的状态，且每个状态与其他节点之间都是割裂且毫无联系的。

基于如上背景，科技公司提出为现代化应用打造全链路统一可观测体系，将原本独立的三大资源（链路、监控、日志）贯通，从而提供完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析、应用监控关联、应用日志关联、基础设施拓扑关联等服务，可以带来如下方面的收益：

• 故障排查和问题解决：云原生可观测系统可以帮助快速定位和解决故障。通过实时监控和日志记录，可以追踪系统中的问题，并及时采取措施解决它们，从而减少停机时间和用户体验的影响。

• 性能优化：可观测系统提供了对应用程序和基础设施的全面监控。通过收集和分析指标，可以了解系统的性能瓶颈，并优化资源分配和代码结构，以提高应用程序的性能和可伸缩性。

• 自动化和自愈能力：云原生可观测系统与自动化工具和流程集成，可以帮助实现自动化的故障恢复和扩展。通过设置警报和自动化脚本，可以根据预定义的条件自动触发响应操作，从而减少人工干预的需要，并提高系统的稳定性和可靠性。

• 安全监控：可观测系统可以帮助监控和检测潜在的安全漏洞和入侵行为。通过分析日志、审计和网络流量等数据，可以及时发现异常活动，并采取相应的措施保护系统和数据的安全。

• 性能分析和趋势预测：云原生可观测系统可以提供对应用程序和基础设施的历史性能数据和趋势分析。这些数据可以用于预测未来的需求和行为，帮助做出更好的决策并规划资源分配。

综上所述，建设统一可观测系统可以提高系统的稳定性、可靠性和安全性，减少故障和停机时间，优化性能和资源利用，同时提供更好的用户体验和运营效率。

整体分层架构设计如下图：

目前许多基础设施软件都已存在内部集成或内部定制化的SDK，导致传统的闭源很难继续发挥应用的效果，因此我们选择拥抱集成开源，使用Jaeger Agent、SkyWalking、普罗米修斯、OpenTelemetry、OTEL Agent、Log Agent，以及一些内部传统Agent等进行数据采集，并将采集到的数据汇总到具有良好扩展性设计的OpenTelemetry收集器中，通过鉴权路由把数据分发到Kafka，由两路消费；一路用于日志分析、数据提取，将指标保存于Clickhouse（可选择ES）后，闭环到数据清洗和计算，从而完成其他告警和监测工作。另外一路则相对简单，将数据按照是否存在问题进行分离存储ES（或Clickhouse）中，统一挂载查询引擎，允许用户使用类似SQL查询的形式对数据进行查找日志、指标、链路等等。

整个架构的设计，可以做到从业务和用户的视角出发，依循请求链条、调用链条、关联链条、模拟用户访问行为及系统内部调用逻辑进行深度监控，并映射联动基础设施架构资源进行异常故障排查，精准定位问题根源。

1、全栈覆盖统一接入

目前金融行业大多在监控领域的建设已相对成熟完善，科技公司根据自有建设经验，总结可观测领域要更好地发挥作用，需要能覆盖以下对象类型：

可见可观测指标需要包含基础设施到中间件，再到应用自身的模块、组件、网关等，存在覆盖范围广，对接集成多的特点，针对这种情况，全栈统一接入环节采取如下设计：

OpenTelemetry是一组API、SDK、工具和集成，旨在创建和管理遥测数据，例如Trace、Metrics和Logs。它通过分布式链路追踪技术，记录请求链路的信息，并将这些信息发送到中央存储系统中进行分析和可视化。

OpenTelemetry的原理包括以下几个关键步骤：

• 客户端向服务器发送请求，服务器生成一个Trace ID，并将该ID返回给客户端。

• 客户端接收到TraceID后，将其加入到请求头中，并将请求发送给服务器。

• 服务器接收到请求后，生成一个Span ID，并将它和Trace ID一起记录到日志中。

• 当请求通过多个服务节点时，每个服务节点都会生成一个Span ID，并将其和Trace ID一起传递下去。

• 最终，所有的Span都会被发送到中央存储系统中，可以通过该系统进行分析和可视化。

OpenTelemetry的优势在于它提供了一个与供应商无关的统一实现，可以将其配置为将遥测数据发送到选择的后端。它支持各种流行的开源项目，包括Jaeger和Prometheus。使用OpenTelemetry可以解决观测性领域模型的统一、观测性数据收集的统一、观测性数据输出的统一等问题，这些统一性主要体现在API规范、SDK实现规范、接口规范等。是解决云原生技术堆栈中分布式和多语言架构的可观察性问题的有效工具。

在统一接入采集阶段，可以根据银行实际业务需求进行改造和扩展，将要对接的所有Receiver中的异构数据转换为统一的开源OpenTelemetry协议进行存储。第三方集成服务中的鉴权、采样、限流/限频方面，以及较重要的路由，即提前根据租户、服务类型，以及监控场景分类数据，将分类后同类型数据进行简单合并，从而方便后续操作并减轻网络传输压力。为保证监控数据的时效性，延时数据不会对后续造成影响，采用本地加内存的缓存机制，一份存储数据可被多人消费，类似于一个本地的简单Kafka；将最新的数据保存至内存，历史数据保存至本地磁盘，日志消费等则由Kafka负责。后续过程转化为兼容OpenTelemetry协议的数据结构，并在其中进行标准化的工作，确保数据的统一性。

2、观测数据建模

该阶段为处理海量数据和提供高并发服务，采用分布式、高可用、高性能的设计原则，引入了分布式流式处理工具Flink。该阶段主要包括以下关键功能：

3、可观测数据存储

可观测数据存储主要分为三部分数据，Log、Trace、Metrics。

通过抽象数据ID化，以类似数据库组件的形式，为每个数据添加或编辑标签信息，标签可用于数据的分类、检索和过滤，同样有助于提高数据处理和分析的效率，数据ID也可方便的针对不同项目应用观测的需求进行补打标和补算。

其中数据读写统一管控架构设计如下：

统一数据读写的方式，主要涉及到异构存储的上层查询、ES动态分片、监控时序数据及时间的计算。

针对大范围数据查询的自动分页，在查询时按时间分片聚合，将告警等静态数据缓存等等。沿用流处理的思路，可以限制分片上限，并基于数据的周期性进行动态分片调整。

整个过程在采集接入和存储阶段确保输入输出数据的标准化，计算阶段通用化，再面对银行需求场景时，可以实现简单通过POC写SQL等来快速响应可观测方面的需求。

1、全链路故障根因分析

云原生容器业务场景的根因分析如下图举例所示：

可将问题根据异常类型或Error级别进行简单的分类统计，让DBA和应用项目组关注自身类别的告警，直观地通过拓扑中指标情况，找到下方Trace链路和环节的问题点，继而根据Trace ID对日志关联，查找具体日志内容。整体排查过程基本不涉及任何关键字查找，仅仅通过图示和鼠标操作上游便可轻松定位问题模块。我司推荐常见三大类型问题的排查路径如下：

依赖服务异常排查路径：可在拓扑视图中根据节点异常颜色标识，以数据库为例，点击节点进入详情，以服务请求视角分析组件异常SQL语句、慢SQL、错误类型，分析数据库组件指定时间范围指标，分析组件指定时间范围明细日志。

接口异常排查路径：拓扑视图中线条有异常颜色显示，即表示接口异常，点击对应组件，可以查看该服务接口的黄金监控指标，聚焦时间范围分析错误请求，通过查找链路TraceID详情，并关联日志明细，若项目组日志不规范，亦可通过同一时间范围关联日志明细。

实例异常排查路径：同依赖服务排查，可以进入拓扑中节点详情，查看服务实例的黄金指标、JVM、线程堆栈指标，通过标签，可查看在同一时间范围内的日志关联明细，若实例日志无异常，可通过服务实例IP查询所在IaaS资源同一时间范围的指标和主机操作系统日志明细。

总结，可以通过三步走践行故障根因分析，找关系（调用链），看指标（Trace ID或时间范围），钻明细（Trace ID或条件检索），基于以上关键步骤，基本可以快速定位依赖服务异常、接口异常、实例异常等常见的典型问题场景。

2、运维持续观测改进

在云原生背景下，可观测能力是运维团队的核心能力，包括对系统状态、性能指标的持续观测和分析，观测能力的强弱直接影响团队发现和解决问题的能力。以应用为中心将性能指标、运行日志、服务事件、请求链路进行统计聚合、关联分析、建立服务全景观测中枢，实现服务性能度量、预测，提供故障根因及性能分析依据。

持续观测优化改进的整体流程示意图如下：

运维团队的工作流程和关键指标对于确保系统的稳定性和可靠性具有重要意义。当发生故障时，运维团队需要快速、准确地定位和解决问题。这需要团队具备丰富的经验和技能，以及有效的工具和技术。结合下文的混沌韧性工程，可以构建清洗运维决策链路，联动应用发布、故障处置、容灾演练、服务治理构建持续观测、优化改进的闭环反馈机制，主动保障系统连续稳定，为金融行业的容器领域运维数字化转型发展提供有力支持。

–