jason2006xu
作者jason2006xu·2024-05-07 22:23
技术经理·昆仑银行

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

字数 4544阅读 369评论 0赞 0

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

前言:

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

痛点:

  1. 运维系统界面多,风险不可控:运维人员在日常巡检、服务请求和问题查询时,需要登录不同的运维平台进行操作,这增加了误操作的风险 。
    2、 在运维事故发生时,如何准确地定位出故障的根因常常是一个具有挑战性的任务。特别是在以下场景中,比如:在复杂的系统架构中,故障可能发生在不同的组件或层级上,例如数据库、网络、应用程序等。这些组件的故障可能是由环境状态的变化引起的,例如配置错误、资源瓶颈等,也有可能是因为代码内部错误,或者是调用的第三方服务发生异常,或者数据库连接超时导致报错等。在分布式系统中,可能会有多台服务器、多个组件以及各种各样的服务之间的通信。在这种环境下,定位问题可能会涉及到多个层面和组件之间的相互作用,这可能会导致跨越不同服务器的调试、日志收集和跟踪成为具有挑战性的任务。在微服务架构中,应用程序通常由许多小型服务组成。当一个事故发生时,可能需要同时检查许多微服务,以确定哪些服务可能会对问题负责。此外,这些微服务可能分布在不同的服务器上,对诊断和修复造成困难。故而,对故障进行根因定位,往往面临着如下几个难点:
    数据孤岛现象严重,数据体量太大 ; 排障往往是多团队协助进行,信息同步慢,团队协作困难 ; 排障过程严重依赖运维专家知识,无法形成标准化的排障知识库 ; 系统架构复杂庞大,所用技术栈越来越多,拓扑关联复杂等。
  2. 、运维缺乏统一标准,工作规范性差:不同运维系统存在不同的操作流程,不同人员对应用系统的运维管理工作细致程度存在差异,缺乏统一标准,导致运维复杂度增加 。
  3. 、经验不少,知识不多,过度依赖核心人员:许多有价值的经验仅存在于个别人员的头脑中,没有得到有效的传播和继承,导致运维团队过度依赖少数核心人员,降低了整体的处理效率。
    5、特别是 在云原生环境下,也经常会遇到一些典型的故障, 举例说明 :
    单实例故障:假设有一个服务,这个服务有 三 十个实例,其中只有一个实例出现了问题。此时,它可能会影响到上游的很多关联服务,导致这些服务变得不可用。例如,服务的JVM出现问题,或者由于一条链路的数据出现问题,导致服务实例异常。这样的问题如何发现和定位?
    下游组件故障:有时候,服务本身没有问题,但是依赖的下游组件出现了故障。例如,依赖的Redis突然出现了雪崩,或者调用的 数据库 突然查询变慢。这些问题又该如何处理?
    主机故障:还有一些问题可能出在主机上,比如主机突然死机,或者主机出现故障。这将影响到主机上运行的所有组件,甚至导致上层的服务无法提供,进而影响业务,导致业务中断或者业务损失。
    外部接口故障:除了自身系统内部的问题,还可能会遇到外部因素的干扰。例如,依赖的第三方接口出现了问题。这样的问题又该如何快速发现,快速感知,快速排查呢?
    针对这些典型的故障,需要有一套有效的处理和定位机制。

面临的挑战

商业银行的系统架构从传统的IT架构转变为云原生架构,这无疑为运维带来了许多挑战 。

分布式架构运维挑战

原本只需要几个JAR包就可以提供服务的系统,现在已经被解耦为成千个微服务。这意味着我们需要管理和维护的对象数量是几何级增加的,这无疑大大增加了运维的难度。同时,如何梳理这些微服务之间的调用关系也成了一个难题。诸如数据分片、异地存储等这类传统维护模式也难以为继。

运维生态挑战

由于各个系统都会建设自己的运维工具,而这些工具往往是烟囱式的建设,没有进行整体的 打 通,导致运维能力分散,不成体系。另外,各层面的数据(如应用、数据库、中间件、云平台、基础设施等)存在孤岛,没有进行有效的整合,这也给运维带来了困扰。

业务连续性挑战
故障处理过于依赖专家经验,而系统服务之间的调用关系复杂,故障分析和定位困难。此外,端到端的稳定性保障体系仍有一定的缺失 ,在 智能化能力还有待提高。

解决方案

面对这些挑战,传统的运维方式已经无法满足需求。为了保障系统的稳定性和业务的高效 运行 ,我们提出了 一体化智能可观测 平台,用于对系统稳定性和业务连续性进行全面保障。首先,利用开源工具可以将企业运维数据上下游员、存储打通。企业的运维数据通常分散在不同的系统和应用中,包括服务器日志、网络设备数据、应用程序指标等。通过开源工具,可以将这些数据进行集中管理和存储,实现数据的统一性和一致性。同时,还可以提供数据的可视化界面,方便企业运维人员进行数据的查看和分析。其次,可以实现监控、分析和优化的整体故障视图。企业的运维管理需要及时发现和解决故障,以确保系统的稳定性和可靠性。通过开源工具,可以对企业的运维数据进行实时监控,并通过分析和优化来提高系统的性能和效率。整体故障视图可以帮助企业运维人员全面了解系统的运行状态,及时发现潜在的问题,并采取相应的措施进行处理。最后,利用开源工具可以提高企业运维管理的效率和效果。同时,还可以提供丰富的功能和工具,帮助企业运维人员更好地管理和优化系统。

  1. 引入智能运维技术:利用云计算、大数据和人工智能等新技术,实现智能运维,提高运维效率和准确性。智能运维技术 可以实现以下几个 方面 目标 : 1) 自动化运维:智能运维技术可以通过自动化工具和技术,实现对IT基础设施的自动化管理和维护。例如,通过自动化工具可以实现对服务器、存储、网络等设备的自动巡检、故障诊断和维护。自动化运维可以减少人工操作的时间和错误,提高运维效率和准确性。 通过分析监控数据、日志和事件,自动检测和诊断系统故障,并提供相应的修复建议,可以自动化执行诊断步骤、生产运维报告和控制系统的复杂操作。2) 故障预测 和预防 :智能运维技术可以通过运用 大数据、 机器学习等技术, 大模型可以分析大量的系统数据, 对企业的IT基础设施进行故障预测。例如,通过机器学习等技术可以分析历史数据,预测潜在的故障和风险,从而实现故障的预防。故障预测可以帮助运维人员提前采取措施,避免故障的发生,提高准确性和可靠性。 3) 智能优化 :智能运维技术可以通过运用大数据技术,为企业IT基础设施的运维和管理提供数据支持。例如,通过大数据技术可以分析企业IT基础设施的运行数据,优化运维策略,提高 系统实时的性能分析和调优建议,以提高系统的响应性和效率 。
  2. 建立统一标准和规范:制定统一的运维标准和流程,确保不同人员对运维工作的理解和执行方式一致,降低运维复杂度 。
  3. . 建立知识管理系统:将运维人员的经验和知识进行整理和归档,建立知识库或文档,方便团队内部的知识共享和传承。
  4. 利用开源工具将企业运维数据上下游、存储打通,实现监控、分析、优化的整体故障视图是企业运维管理的迫切需求。这是因为企业运维管理面临着日益复杂的挑战,包括庞大的数据量、多样化的系统和应用、快速变化的业务需求等。通过利用开源工具,企业可以将各个环节的运维数据进行整合和分析,从而实现对整个运维过程的全面监控和优化。

实施效果

跨系统分布式追踪

全链路监控 提供全链路应用性能监控能力,涵盖前端监控、应用性能监控,实现前、后端链路的打通,完整还原用户的体验现场,为产品体验优化和问题定位指明方向。丰富问题排查手段,提升问题根因定位的效率,故障处理耗时减少45%。

全流程调用链监控

这是在应用链路复杂的情况下,帮助判断应用是否存在问题的工具。我们采用非侵入式字节码注入方式进行数据采集,只需在启动时添加一个参数,就能采集Java应用的调用量、耗时、异常等黄金指标,并转换成可以使用的指标进行告警。
系统之间调用拓扑图如下:

服务之间调用拓扑如下:

服务趋势/报错异常如下:

接口调用链条图如下:

接口分析:

JVM、GC性能分析:

容器监控:

通过调用链路,我们可以判断应用之间的关系,定位底层故障在哪个应用层面上。调用链路是自动生成的,如果出现问题,应用层面会变红,我们可以立即看到哪里出现了问题。点击有问题的应用,可以看到它的上下游调用以及为什么变红。每分钟都会进行数据聚合,通过这种方式,可以看到整个服务的调控趋势。我们还可以看到有哪些报错,包括业务报错和系统报错,例如连接超时的异常或业务规则限制导致的异常。我们会区分这两种异常,针对系统异常进行告警,业务异常则进行服务治理。
如果一个服务下有多个实例,一个实例出现问题,其他实例没有问题,就可以通过重启该实例解决问题。把调用链路和配置管理关联起来,就能知道实例所在的容器和主机以及占用的端口,然后进行关联。可以采集到云平台的资源情况,如容器的内存和CPU,主机的负载、CPU内存磁盘等,判断是否主机或容器的异常引发了服务异常。另外,还可以看到服务之间是否是因为JVM或者GC的问题导致了实例不可用。
支持多维度告警能力,例如,当调用量降低20%或超过20%就进行告警;或者当超时3秒的比例大于5%或者超时1秒的比例大于10%就进行告警。这种多维度的、可配置的告警规则可帮助应用系统快速地配置监控告警规则并推送到统一的监控告警中,以便快速发现问题并通过调用链路进行问题定位。

RUM监控

采用SDK埋点的方式,采集用户在访问过程中的性能指标,从而获取APP端真实的用户行为。例如,可以在用户访问页面后获取用户的行为数据,包括用户在什么时间访问、使用哪个IP、在什么地点以及使用哪个系统。此外,还可以获取用户的具体操作,如打开页面、访问接口或弹出弹窗等。这样,就可以实时采集并获取用户的真实行为和体验数据,包括加载、点击、弹窗、JS报错等用户全轨迹追踪。一旦发现页面响应时间过长,或者AJAX响应时间过长,或者弹窗数量突然增多,就会及时进行告警,因为这可能表明系统存在问题。同时,还可以进行故障定位。
此外,还可以通过收集工号的行为来进行分析。例如,如果有工号在频繁访问某些页面或进行同样的请求,就像机器人或爬虫一样,就可以判断出它在进行不正常的行为。这样,就可以进行安全分析,并有效地进行安全治理。
全链路监控对前端性能和用户体验数据进行多维度的可视化数据分析,包括页面加载性能、JS错误、API请求、服务流量,全面掌控终端用户的体验。通过全链路监控,页面体验用时可优化至3S以内,被监控页面故障主动发现率从40%提升到90%,大幅降低用户页面体验的投诉率



总结

综上所述,利用开源工具将企业运维数据上下游、存储打通,实现监控、分析、优化的整体故障视图是商业银行运维管理的迫切需求,建设一体化智能可观测平台是当下分布式架构下的运维管理的最好方案。同时,随着人工智能和机器学习技术的融合应用,可观测性平台有望实现更加智能化的故障预测和自愈能力,帮助商业银行提高运维效率、优化系统性能、提升客户体验,从而更好地满足业务需求、助力商业银行数字化转型。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广