一体化智能可观测平台探索与实践

【摘要】面向商业银行运维管理的迫切需求，本文分享了利用开源工具将企业运维数据上下游、存储打通，实现监控、分析、优化的整体故障视图，建设一体化智能可观测平台的探索实践。

前言

随着新质生产力的发展以及数值化转型的纵深推进，商业银行在运维过程中建设了不少运维工具，比如基础监控平台、交易监控平台、APP端性能监控、后端APM、业务拨测等不同工具，数据比较分散，给运维人员分析问题、定位问题带来了不少麻烦，如何将这些工具整合起来，数据集成起来，打通数据之间的关联关系，实现端到端故障处理能力，做到故障1分钟发现，5分钟定位，10分钟快速解决问题，是当下亟待解决的问题。

痛点

1、运维系统界面多，风险不可控：运维人员在日常巡检、服务请求和问题查询时，需要登录不同的运维平台进行操作，这增加了误操作的风险。

2、在运维事故发生时，如何准确地定位出故障的根因常常是一个具有挑战性的任务。特别是在以下场景中，比如：在复杂的系统架构中，故障可能发生在不同的组件或层级上，例如数据库、网络、应用程序等。这些组件的故障可能是由环境状态的变化引起的，例如配置错误、资源瓶颈等，也有可能是因为代码内部错误，或者是调用的第三方服务发生异常，或者数据库连接超时导致报错等。在分布式系统中，可能会有多台服务器、多个组件以及各种各样的服务之间的通信。在这种环境下，定位问题可能会涉及到多个层面和组件之间的相互作用，这可能会导致跨越不同服务器的调试、日志收集和跟踪成为具有挑战性的任务。在微服务架构中，应用程序通常由许多小型服务组成。当一个事故发生时，可能需要同时检查许多微服务，以确定哪些服务可能会对问题负责。此外，这些微服务可能分布在不同的服务器上，对诊断和修复造成困难。

故而，对故障进行根因定位，往往面临着如下几个难点：数据孤岛现象严重，数据体量太大，排障往往是多团队协助进行，信息同步慢，团队协作困难；排障过程严重依赖运维专家知识，无法形成标准化的排障知识库；系统架构复杂庞大，所用技术栈越来越多，拓扑关联复杂等。

3、运维缺乏统一标准，工作规范性差：不同运维系统存在不同的操作流程，不同人员对应用系统的运维管理工作细致程度存在差异，缺乏统一标准，导致运维复杂度增加。

4、经验不少，知识不多，过度依赖核心人员：许多有价值的经验仅存在于个别人员的头脑中，没有得到有效的传播和继承，导致运维团队过度依赖少数核心人员，降低了整体的处理效率。

5、特别是在云原生环境下，也经常会遇到一些典型的故障，举例说明：

单实例故障：假设有一个服务，这个服务有三十个实例，其中只有一个实例出现了问题。此时，它可能会影响到上游的很多关联服务，导致这些服务变得不可用。例如，服务的JVM出现问题，或者由于一条链路的数据出现问题，导致服务实例异常。这样的问题如何发现和定位？

下游组件故障：有时候，