银行行业企业级监控产品的建设选型、难点及解决方案探讨?

随着互联网金融业务的快速发展,银行业务互联网化,期望突破传统的存贷业务找到新的利润增长点。为此,银行业新建、重构了大量互联网类的业务系统,给系统、网络和应用各条线的运维带来了巨大压力。然而当前银行业运维监控系统的建设仅完成存在性监控的部署,大多数监控数据采用 AGENT、SNMP 与系统日志等采样方式获取,数据实时性、精度较低且无法站在全行业务系统的统一管理视角进行监控。即使有的行部署了业务层面的应用监控,选用的监控产品也是五花八门,不同团队又有不同的监控方案。一旦业务系统运行出现问题,交易链路上的网络、系统及业务交易指标相互孤立,缺乏统一的全景展示平台,难以及时找出问题环节。在发生业务故障时,时间往往被耗费在低效的排查工作中,其中的主要问题在于:一旦发生问题,多团队同时开始根据各自经验诊断;缺乏统一视角的证据支持,没有入手点;若无法达成共识,则需要进一步线索进行反复排查。

针对这一问题,之前我行使用的一些监控产品(NPM和BPC)在我行使用效果不太理想,有太多局限了。个人觉得对一些中大银行,还是要有企业级的监控产品和配套的规范,这些规范涉及编码、测试、运维各阶段,且应明确各方人员在监控部署、设计方面的职责分工。

因此,特提出此话题,望各位同行能够给本人答疑解惑,能够告知本人银行业企业级监控产品的建设选型、难点及解决方案,不甚感激!!

8回答

jason2006xujason2006xu  技术经理 , 昆仑银行
Mengsystem冯岩zhuhaiqiang等赞同了此回答
监控系统最大的痛点就是故障快速定位,目前很多银行都有网络监控、存储监控、系统监控、数据库监控、中间件监控、交易性能监控。 但是这些专业级的监控基本是孤立的,没有整合再一起,所以当网络、数据库或者中间件发生故障时并不知道这些基础层面的故障会影响哪些业务系统; 或...显示全部

监控系统最大的痛点就是故障快速定位,目前很多银行都有网络监控、存储监控、系统监控、数据库监控、中间件监控、交易性能监控。

但是这些专业级的监控基本是孤立的,没有整合再一起,所以当网络、数据库或者中间件发生故障时并不知道这些基础层面的故障会影响哪些业务系统;

或者业务系统不能正常进行交易时不能准确定位到底是网络问题还是数据库问题、中间件问题。

建议建设一套一体化监控管理系统,将各专业监控的性能数据、告警数据整合在一起,进行统一的管理和实时的关联分析,能够快速有效地定位故障的告警根源

,提高故障诊断的效率,从而构建不同层级,不同部门间协调解决问题的平台,成为应对突发事件、支持领导决策的一种重要手段。

要想建设好这套系统,首先建议采用垂直分层的建模思路设计端到端业务资源模型,按照业务资源对象在业务实现中

的角色不同,把资源分为直接的业务服务、承载系统、组件三个层次,承载系统在端到端流程中是提供直接服务的依托环境,而组件

是以一种透明的方式展示业务完整性所经过的处理环节,承载系统和组件为业务系统提供直接的功能支撑。

另外建议增加可视化监控,给运维人员提供不同视图从业务角度快速定位问题,同时也能从网络、数据库层面知晓受影响的业务系统。

收起
 2019-11-14
浏览886
aixchina 邀答
melody2004melody2004  系统架构师 , 某城市商业银行
zhuhaiqiang冯岩赞同了此回答
我的看法是基于流量抓包的监控系统,首先需搭建一套流量采集平台,现阶段有两种比较流行的方式,一是通过修改硬件网卡驱动对数据包从源头就打上标签,然后做流量收集。这种方式的优点是可以从源头排查故障;缺点是对设备厂商要求较高,一般中小银行难以得到厂商定制。据了解,阿里选择...显示全部

我的看法是基于流量抓包的监控系统,首先需搭建一套流量采集平台,现阶段有两种比较流行的方式,一是通过修改硬件网卡驱动对数据包从源头就打上标签,然后做流量收集。这种方式的优点是可以从源头排查故障;缺点是对设备厂商要求较高,一般中小银行难以得到厂商定制。据了解,阿里选择的这种方式。二是在TAP设备上实现此类功能,并对流量过滤、消重。优点是实现相对简单;缺点是看不到操作系统层面的网络数据包。
基于流量抓包与基于日志的监控系统形成互补,可以帮助发现应用层以下的一些问题,但由于偏底层,展示的内容不能像基于日志中交易信息那么直观,再加上底层相对稳定,问题偏少,此外在行内建设一套此类系统(包含TAP流量采集网)的成本相对较高,因此会给人性价比低的感觉。
我们的NPM系统上线已有3年的时间,期间排查优化网络问题3个,其他时间出一些运行监控报表。

收起
 2019-11-15
  • 您说的是硬件运行状况方面的监控吧?应用层面的监控贵行是如何做的?
    2019-11-15
  • 网络流量层的监控,排查过因备份系统导致内网流量过大问题、服务器IO中断、网银访问慢等问题。 应用层主要在用BPC抓取数据包拆包抽取数据的方式,tap网络设计部署合理的话,数据还是比较精确的。
    2019-11-15
Tie1982Tie1982  项目总监 , 泰康保险集团
冯岩我爱大锅饭赞同了此回答
我解决解决这类问题这类问题的路径: 了解问题; 找到产品; 基于产品自己形成能力; 我选的zabbix加prometheus显示全部

我解决解决这类问题这类问题的路径:

  1. 了解问题;
  2. 找到产品;
  3. 基于产品自己形成能力;

我选的zabbix加prometheus

收起
 2019-11-14
  • zabbix加prometheus是否能覆盖所有的系统?是否适合做业务层面监控?
    2019-11-15
  • 能,我这里zabbix加prometheus之外,还有pinpoint、zipkin、skywalking、apm、elk、splunk... 完整的监控中心可能啥都少不了
    2019-11-15
  • 是的,这其实就是我想向大家请教的,一个完整的企业级监控,到底要如何设计,需要采用哪些组件、产品,需要做哪些改造,有哪些坑之类的
    2019-11-15
匿名用户匿名用户
zhuhaiqiang我爱大锅饭赞同了此回答
工具都有各自的专业领域,围绕业务、应用、网络、系统及基础资源等等几个层面进行监控,理清楚各个层级关注的优先级以及各个层级的关联关系。另外,选用任何一个工具,都先要深度理解工具的价值点,技术先进性,数据开放性,指标可靠性,稳定性等,不应该过于求大而全。各监控产品干各自层...显示全部

工具都有各自的专业领域,围绕业务、应用、网络、系统及基础资源等等几个层面进行监控,理清楚各个层级关注的优先级以及各个层级的关联关系。另外,选用任何一个工具,都先要深度理解工具的价值点,技术先进性,数据开放性,指标可靠性,稳定性等,不应该过于求大而全。各监控产品干各自层级的专业的事情,至于智能化或一体化的监控和定位,则需要包括全行业务系统的运维数据规范化管理以及优秀的AIops工具来打通各个工具的数据关系。

收起
 2019-11-14
  • 非常同意您提到的“运维数据规范化管理”,请教下您在这方面能给一些建议或者学习案例吗?
    2019-11-15
匿名用户匿名用户
zhuhaiqiangzihan524524赞同了此回答
朋友elk了解下,另外zabbix不是也很好么?显示全部

朋友elk了解下,另外zabbix不是也很好么?

收起
 2019-11-14
  • ELK的确是很优秀的开源方案,但 个人认为银行业系统五花八门,各有特点,ELK很难做到全能,ZABBIX对容器的监控就不是很优秀。
    2019-11-15
summitsummit  系统架构师 , 城商行
Mengsystem赞同了此回答
监控做不好出现的问题主要有:1、一个硬件或者一个网络报错,往往会告警出来一片报错,短信量太大,而且总有”狼来了“的假象发生,给运维带来很大困惑。2、CMDB建设不完善,信息没有实现共享,造成业务、网络、基础设施资源没有实现关联,造成故障无法快速定位。3、监控指标颗粒没有细...显示全部

监控做不好出现的问题主要有:
1、一个硬件或者一个网络报错,往往会告警出来一片报错,短信量太大,而且总有”狼来了“的假象发生,给运维带来很大困惑。
2、CMDB建设不完善,信息没有实现共享,造成业务、网络、基础设施资源没有实现关联,造成故障无法快速定位。
3、监控指标颗粒没有细化,存在监控不到位或者无法监控。
4、工具不人性化或者功能不完善,造成各个运维人员搭建各自的监控平台,比如存储使用自己的监控TPC等,数据库使用sql监控等,网络使用自己的网管平台等等,各立门户。
5、NPM和BPC使用效果不好,主要是看BPC是不是通过网络流量镜像的方式实现,其实NPM和BPC通过网络流量镜像的资源可以共享,结合日志分析平台可以完善业务系统的监控(BPC)。主要还的完美结合CMDB平台,要不然业务无法实现关联,最终监控效果也会展现不了。

收起
 2019-11-27
冯岩冯岩  数据库管理员 , 银行
zhuhaiqiang赞同了此回答
其实,您提出的这个问题是普遍存在的问题,各个层面的监控工具杂多,监控数据类型多样(关系型、非关系型等),监控数据很难集中到一起统一关联、 分析、管理。常常业务、系统、存储、网络等各个部门,各管各的,业务系统出现问题时,很难配合到一起, 有效快速地解决问题。 我非常赞同  j...显示全部

其实,您提出的这个问题是普遍存在的问题,各个层面的监控工具杂多,监控数据类型多样(关系型、非关系型等),监控数据很难集中到一起统一关联、 分析、管理。常常业务、系统、存储、网络等各个部门,各管各的,业务系统出现问题时,很难配合到一起, 有效快速地解决问题。

我非常赞同  jason2006xu 大哥的观点!
建设统一的监控管理系统,从业务资源模型的设计入手,采用垂直分层的建模思路建设这个监控平台。
其实,这一步完成后,离 AIOPs 智能化系统就更近一步。

收起
 2019-11-26
浏览138
aixchina 邀答
匿名用户匿名用户
据了解天旦在140家银行客户都用的很好,楼主你用不好,是自身水平问题问,建议你再提高下自己显示全部

据了解天旦在140家银行客户都用的很好,楼主你用不好,是自身水平问题问,建议你再提高下自己

收起
 2019-11-14
浏览765
  • 是吗?我技术水平的确有限,但是天旦的BPC对于网络流量采集设备、自身应用的系统软硬件兼容的确是我见过比较差的。我不知道您是怎么了解到140家银行的使用情况的,如方便,能否提供两家银行的实践案例,我去调研下。
    2019-11-15
  • 你好,我行就在使用天旦的BPC监控,没有遇到流量镜像和硬件不兼容的问题,新实施安装总是需要调试的。BPC的优势是无需应用修改代码,做到日志规范,即可实现对应用交易路径各节点的监控。在定位应用故障节点、哪些交易响应慢、失败率高方面,我觉得是见效快的,特别是运维无法对开发进行要求或者老旧系统不便于改造的。如果各个系统日志都比较规范,例如有每只交易开始、过程、结束、全局流水号的记录,通过日志集中分析平台,也可以实现应用监控。 -如果就旁路应用监控而言,BPC还是可以的,建议找天旦原厂对实施进行总结分析。
    2019-11-15
  • BPC是基于交易报文的吧?不可否认的是BPC的确在应用监控方面突破了传统的基于应用日志的监控思维,不需要安装agent,对应用本身无任何干扰,但是自身应用对于操作系统版本的要求,对于网卡的要求,对一些加密报文解密效率的问题都给使用方带来一些困扰。个人觉得最大的问题是监控功能自由度不够,监控的指标数量、监控展示自定义空间较小,较为依赖厂商。交易的路径还依赖于管理员梳理,无法实现真正的自动发现。
    2019-11-15
  • 我也是天旦BPC的用户,业务级性能监控领域,个人觉得没有更产品化高,易用性强,见效快的产品了,其实天旦BPC还是比较灵活的,只要能力强,自己也能自定义解码,输出各种参数指标的,至于您说的交易路径的梳理,自动发现可能是过于理想化了,实现难度非常依赖报文规范性,这并不是技术难点,而是现状,痛点,只能先应用改造,统一报文格式规范,才能发现得了,否则任何产品都没办法,至多发现上下游关系。另外,监控软件安装在有一定定制的硬件和操作系统上,而不是标准设备上,反而是非常好的做法,因为标准设备的性能有一定的缺陷,经过定制化后能够大幅提高监控性能和用户体验,尤其是减少丢包问题,提高准确性。
    2019-11-15
  • 非常感谢您的回复!您说的业务级性能监控最好的产品是BPC,我觉得要先加个定语,至少要加上旁路监控。我个人认为这款产品的确很有特点,在旁路监控领域是一套成熟的产品。但是您说的统一报文格式我觉得在银行业系统中推行比较有难度,而且您说的对硬件个性化要求是好事我个人不敢苟同,个人觉得一套好的软件产品,兼容性一定要足够好。
    2019-11-26

提问者

我爱大锅饭系统运维工程师, 银行

问题状态

  • 发布时间:2019-11-14
  • 关注会员:9 人
  • 问题浏览:6055
  • 最近回答:2019-11-27
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30