天津交行无代理IT监控方案设计与研究

王绍红

摘 要：“531工程”项目上线后天津交行基于新的IT架构设计了一套无需部署代理端的IT监控方案，即通过Linux网络命令直接对主机服务和网络节点进行逐一扫描，以扫描结果作为监控指标，通过指标间的关系来定位故障点，丰富了生产系统监控手段，提高了故障发现和排除的效率。

关键词：IT运维；无代理监控；指标；故障定位；CMDB

中图分类号：TP308 文献标志码：A 文章编号：2095-2945（2018）28-0096-03

Abstract： After the "531 Project" was launched， Bank of Communications Tianjin Branch designed a set of IT monitoring scheme based on the new IT architecture without the need to deploy the agent， that is， directly scanning the host service and network nodes one by one through the Linux network command. The scanning result is used as the monitoring index to locate the fault point through the relationship between the indicators， which enriches the monitoring means of the production system and improves the efficiency of fault detection and removal.

Keywords： IT operation and maintenance； agentless monitoring； index； fault location； CMDB

1 概述

隨着交通银行“境内外一体化全业务系统重构工程” （即531工程）项目2015年7月在天津成功上线，交通银行天津市分行（下面简称天津交行）在以新型技术架构助推银行转型发展的道路上迈出了一大步。这项浩大的工程，以业务整合为突破口，打破横向条块分割的约束，立足当下，着眼未来，以强大前台、高效中台、集约后台合力打造一流的流程银行。新架构在为业务发展提供支撑和推力同时，也为开创IT运维工作新局面提供了契机。天津交行作为交通银行的省级分行，在工程上线期间即考虑未来的分行IT监控问题，基于对新架构下主要系统的技术平台高度统一的认知，逐渐形成了一套对生产运行几乎无影响的无代理监控方案。传统的监控，一般是在各目标主机部署代理端抓取系统运行信息发送给监控服务器，由其加工后生成图表、发出异常警告。由于代理端自身对系统资源是有消耗的，其开发、部署、维护需要一定的人力成本和时间成本。同时重要的网络节点也需要监控，而代理端程序很难在网络设备上安装，因而传统模式存在某种局限性，需要新的监控手段作为补充。新的方案放弃了传统的代理端部署，改为通过Linux网络命令直接对主机服务和网络节点进行逐一扫描，以扫描结果作为监控指标，通过指标间的关系来定位故障点，丰富了生产系统监控手段，提高了故障发现和排除的效率。此方案一经初步实施，即收到良好效果。据此设立的无代理监控平台（下称监控平台）一期脚本仅几千字节，以集中的网络扫描代替分散的代理端数据采集，实现了对生产系统大部分重要节点的监控。目前监控平台还在根据预先设计的方案持续建设中。本文谨从介绍平台当前架构和技术出发，延伸到下一步以指标及指标依赖、指标集合为核心的智能化监控目标，对未来可能使用到的其他技术做出初步的研究。

2 监控平台现状和核心技术

传统监控模式下的信息流向是从各代理端到服务端，代理端处于主动地位。在天津交行的无代理监控平台中没有代理端、服务端的区分，监控的发起始于平台主机，目标则是IT系统的各个主机、网络上的各个重要节点。常规情况下，监控平台根据预先定义的扫描策略在指定时间对目标主机、网络节点进行网络扫描，同步记录扫描结果，生成可通过Web浏览器访问的报告，发现有某项结果异常，根据策略中设定的信息发出警报。网络扫描结果的有效性基于IT系统得以正常运行的三点基本要求：（1）各主机、网络节点在网络上处于连通状态。（2）主机的对外服务端口处于监听状态。（3）主机对外服务对请求应该有合理的响应。

监控平台运行在Linux操作系统上，其原生的三个网络命令ping、netcat、curl可以分别按上述三点要求对IT系统（含网络设备）进行扫描。ping命令很常用，可检测某个ip在网络上能否到达。netcat命令是一个强大的端口通讯工具，可以检测监听端口，发送报文，模拟交易请求。对于提供Web服务的主机，netcat命令已经不能满足全部要求，因为即使端口处于监听状态，也不代表Web服务正常。这就需要用到curl命令，一个在文字环境下模拟浏览器访问获取页面源代码、下载文件、发送POST请求的工具。它无视Web服务器的具体应用逻辑，带上特定的参数执行，通过判断命令的Shell返回值即可检测Web服务的正常性、Web部署的有效性。

curl命令和netcat命令一样，也可以模拟交易请求。但是，生产环境中不可能大规模地模拟交易。一些系统对请求的来源和报文有校验，而由于交易接口的庞杂与多变，监控平台不可能频繁地去同步变更，因此，模拟交易只能在个别关键而简单的监控需求上有限使用。这些交易请求大都会返回用户权限不足等业务类报错信息，而这恰恰是正常的。

3 监控指标体系与故障定位

（1）指标体系的引入。监控平台所使用的ping、netcat、curl三个网络扫描命令，其执行结果其实有着递次依赖的关系。对于无法ping通的主机，只要其未禁止ICMP协议，使用netcat扫描肯定失败，而对于netcat扫描端口返回失败的Web服务，就没必要再使用curl尝试访问了。生产系统实际运行中存在着更广泛的依赖关系。对于交易路径中串联的各个系统节点，只要最后一个节点停止服务，那么其余的各节点交易都会返回失败。对于负责与总行通讯的节点，其故障将导致分行业务近乎全局性的瘫痪，其他系统健康状况再良好也无济于事。网上也是如此，某个交换机的宕机，将使得整片网络的电脑处于断网状态。将依赖关系反过来，由结果推导原因，可用于揭示某些问题。可以ping通但netcat其某个端口不通，说明该端口未处于监听状态。就交易渠道而言，柜面交易大面积报错，但其他渠道没有异常，那么基本可以判定柜面交易相关的系统出现了问题。为了规范化地描述上述分析判断过程，在监控方案中，将网络扫描项称为指标，称指标间的依赖关系为指标依赖，引入数学上的集合概念，将一组拥有某共同特性的指标作为一个整体来分析，通过指标、集合间的逻辑关系评估生产运行情况，从而构建一个监控指标体系。这些共同特性包括网段、应用系统、物理位置、逻辑位置或管理视角等多方面，根据监控的需要而设定、扩充、调整。（2）指标体系的设计。监控平台目前的常规扫描策略在定义时已经考虑了指标间的依赖关系，避免无谓的重复，但是有时候，“重复”又是必要的。例如，netcat端口扫描结果正常意味着无需再进行ping扫描，但是前者返回异常，那就需要后者来定位到底是网络中断还是端口服务停止。这种取舍的选择，需要依靠指标的依赖关系来决定。在定义指标时，如果它的正常有赖于另一个指标的正常，就要在指标依赖关系配置文件中指定。一个指标的正常有可能依赖多个指标的正常，也可能是多个指标的正常依赖于一个指标的正常，就需要将对应依赖关系拆成一对一的记录存储下来，以便于监控平台能够智能地选择需要检测的指标，避免没必要的重复的同时也可以快速地判断出是哪个指标是系统异常的根源。有时候一个指标的正常，会依赖多个其他指标中任何一个或全部的正常。这多个指标必然有某种共性，否则无法造成统一的影响，可以视为一个集合。集合内成员在条件判断上也许是“或”的关系，例如做了负载均衡的服务器组的任何一台服务器正常即可保障基本的功能，也有可能是“与”的关系，例如一个交易路径上的全部系统都正常才能保证交易能够顺利提交到总行。定义集合时需要考虑其成员关系的类型，不限于“或”和“与”。集合本身也是一个指标，其值不是成员状态的简单叠加，而是要基于一个科学合理的算法进行计算。例如一个前置机房内的几百台设备因为某种动力环境原因导致全部断网，监控平台不应该为每台设备播报一遍故障，而应在检测到全部断网前已经有一个准确的评估，发出一个精准的整体性警报。同指标与指标之间一样，集合与集合、单个指标之间也可以有依赖关系，集合可以有自己的子集，它也可能是其他集合的子集。除此外，集合还有交集、并集、补集运算，方法同数学上集合的运算一致。（3）故障点快速定位。在通常情况下，监控平台直接以一个又一个的指标逐一呈现生产服务状态，发现异常立即发出信息精准的警报，直接定位到ip地址、端口、Web服务、Web部署，运维人员可以立即对目标进行检查。

但是，很多时候，对故障的判断不能只是靠这种孤立的指标来实现，而是要参照多个指标。以高可用集群为例。正常情况下，集群的两个节点都处于网络连通状态，其中活动节点以Service IP对外提供服务。有一天忽然活动节点的Boot IP却无法访问，但集群的Service IP和备用节点的Boot IP处于连通状态，那就说明集群的生产服务已经发生了HA接管，活动节点宕机，备用节点已经启动对外服务。这里就需要ping三个ip地址，分别获取指标值，符合上述状态，即可发出HA接管警报，而不仅仅是报告活动节点宕机。

一些复杂的情况，可以借助依赖关系和集合概念来分析。图1是一个简化的多楼层网络节点图，财务部分居3、4楼，分别通过各自楼层交换机连往核心交换机。而3楼除财务部还有一个保卫部的监控室，通过3楼交换机连往核心交换机。这样3楼财务部同时属于3楼和财务部的两个集合，也就是它们的交集（图2）。某日这个交集突然网络瘫痪，那就要判断它所属两个集合的其他成员（补集）的状况，以此分析是哪个集合出了问题。如果3楼保卫部也网络瘫痪，4楼财务部没有问题，那几乎可以判定三楼这个集合所依赖的3楼交换机有了故障。如果3楼保卫部和4楼财务部也都断网，即3楼、4楼全部断网，而这两个楼层共同依赖的网络节点是核心交换机，应该是核心交换机出现了问题。一般情况下，同一楼层各部门的网络状况应该是一样的，如果某日出现两层楼的财务部都网络中断，而3楼保卫部的网络却处于连接状态，那就需要进一步排查，或许有其他未曾预计的原因，查明后设计好指标和策略添加到监控平台中。

如同计算机人脸识别往往在速度、准确性、灵活性上比不上人眼，实际生产运行中，辅助使用一些准实时加载监控指标数据的动态图表可能效果更好。例如参照机房布局图和网络拓扑图，以主机、网络设备为节点，以绿、红两色表示网络连通性的正常和不正常，若某分区各个绿点忽然开始逐一变为红点，那么运维人员很容易产生直觉判断：该分区很可能出现了全局性问题，譬如断电。但是，人不可能一直盯着监控屏幕看，除了动态图表，更根本的解决方法是借助一些智能的算法（例如卡尔曼滤波算法）将这种经验的判断转换为监控平台的自动播报。

以效率而言，应该将重要指标和部分重要集合进行高频次重复扫描、精准运算，及时发出告警信息，以便于运维人员第一时间获得精准信息，立即投入抢修，而其他指标/集合的计算和动态直观图表的重绘，就不必过于强调时效性。

4 无代理IT监控的未来研究方向

（1）根据监控对象已有协议和接口轻度侵入。操作系统层的CPU、内存、存储、进程等信息是传统监控基本的目标。但在监控平台上，IT系统主机的这些数据都无法获取到。对网络设备，目前仅限于网络连通性的判断，无法完成对流量、策略等更深入的检测，也不能做到路由自动发现。就应用层和银行交易而言，有时因为系统资源瓶颈、程序代码存在bug以及其他暂时未知因素，在相关范围内也会有交易缓慢、失败率过高甚至业务中断等情况发生，而监控平台上却毫无征兆。监控平台的这些短板，需要采用更广泛的技术、扩充无代理监控的手段来解决。主机系统、网络设备、基础软件或广泛或局部开放的外部访问协议和接口为下一步的研究提供了方向，而交通银行新一代业务系统普遍采用了具有自主知识产权的架构平台，技术上高度一致，为监控方案的优化提供了持续的便利条件。早年网络监控即使用了snmp（简单网络管理协议），这个技术现在还在广泛的使用，网络设备一般都默认可以开启snmp的外部访问。另一个也具有广泛性的协议是ssh（Secure Shell），Unix/Linux操作系统和许多的网络设备都可以通过该协议访问。在监控平台上部署数据库、Web中间件、消息队列工具等基础软件的客户端，可以相应地获取IT系统上这些基础软件的运行状况，间接获得操作系统层的数据。这些协议和工具的访问对监控目标难免会有一定的写入权限，但建立了良好的安全访问控制机制，可以将监控对生产运行的扰动控制在合理的范围内，达到以轻度侵入实现无代理监控的目的。

（2）与配置管理数据库的整合。IT基础架构库，即ITIL，是国际上最成熟的一套IT管理解决方案，为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。作为ITIL的主要组成部分之一，配置管理数据库，即CMDB，存储与管理IT架构中资源的各种配置信息，为IT建设、运维提供相关的基础配置信息以及配置之间的相互关系，涵盖硬件、操作系统、逻辑设备、系统配置、基础软件、应用部署以及相关管理信息等各个方面。运维人员可以根据设备的名称来检索它上、下游和同级的关联信息，轻松地了解生产运行全局资源的组织架构，辅助判断某项资源调整时可能涉及的方方面面，同样也能知晓某项资源缺失会影响哪些业务和系统，或者反过来由某个结果推算导致其发生的原因。监控平台的指标、集合及其相互关系，某种程度可以视为配置管理数据库的一部分，在监控层面可以认为二者之间有相当大的重合。例如，对于一个Service IP，在配置管理数据中，它从属于某个高可用集群，其下一级又有多个对外提供服务的监听端口，而同样的关系也会体现在监控平台上。在未来的方案中，配置管理数据库的完整和及时更新，能为监控平台监控对象的全面性、准确性、合理性提供可靠的参照。相反，监控平台可以帮助核对配置管理数据库中的数据，在配置管理数据库的关系结构图中显示配置项的可用状态，提示出某些配置项信息或配置项之间关系的变化。基于配置管理数据库数据和监控平台监控对象的相似性与相关性，二者可以深度整合，避免维护两套数据带来的额外工作量和数据不一致，也便于运维人员更容易理解、把控双方数据。

5 结束语

天津交行无代理IT监控方案目前主要是实现了本文第一部分的目标，即根据预先设定的策略对生产系统重要服务和生产网络重要节点进行网络掃描，已经覆盖主要系统、大部分应用服务和重要网络节点。对于监控指标的依赖关系判定、集合划分、逻辑关系分析、故障定位、图表展示以及无代理检测手段的扩充、监控平台策略定义与配置管理数据库的整合，目前在进行进一步的细化设计和深入研究。相信整个方案的完全实施，对的系统监控工作将更有裨益，其轻量、易部署、易扩展的特性也有助于它的向外推广。

参考文献：

[1]张晓丹.面向业务应用交易的IT运维监控系统建设思路[J].中国金融电脑，2015（1）.

[2]卑风.基于ITIL体系的银行数据中心配置管理工具的分析与设计[J].微型电脑应用，2013（3）.