CN111694743A - 业务系统的检测方法及装置 - Google Patents

业务系统的检测方法及装置 Download PDF

Info

Publication number
CN111694743A
CN111694743A CN202010528829.4A CN202010528829A CN111694743A CN 111694743 A CN111694743 A CN 111694743A CN 202010528829 A CN202010528829 A CN 202010528829A CN 111694743 A CN111694743 A CN 111694743A
Authority
CN
China
Prior art keywords
detection
service
server
service system
sub
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010528829.4A
Other languages
English (en)
Inventor
刘鑫
谭达彬
朱虹
刘保原
胡林红
罗朝亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010528829.4A priority Critical patent/CN111694743A/zh
Publication of CN111694743A publication Critical patent/CN111694743A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明提供了一种业务系统的检测方法及装置;方法包括:接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。通过本发明,能够提高检测的准确度。

Description

业务系统的检测方法及装置
技术领域
本发明涉及计算机技术,尤其涉及一种业务系统的检测方法及装置。
背景技术
云技术为基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云技术已被广泛应用于后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站等业务系统中。
在业务系统用户流量日益庞大的背景下,在第一时间确定业务系统的运营情况是否异常,是确保业务系统稳定运营的重要前提。相关技术在对目标业务的业务系统进行检测时,对目标业务所包括的多个子业务,往往执行相同的检测项检测,导致检测的准确度降低。
发明内容
本发明实施例提供一种业务系统的检测方法及装置,能够提高业务系统检测的准确度。
本发明实施例提供一种业务系统的检测方法,包括:
接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;
其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;
响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;
分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;
基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。
上述方案中,所述分别确定各所述服务器的业务系统所对应的子业务,包括:
获取各所述服务器的标识信息;
基于所述标识信息,确定各所述服务器的业务系统所对应的子业务。
上述方案中,基于所述标识信息,确定各所述服务器的业务系统所对应的子业务,包括:
基于所述标识信息,获取相应的所述服务器的设备参数;
基于所述设备参数、设备参数与子业务之间的映射关系,确定各所述服务器的业务系统所对应的子业务。
本发明实施例提供一种业务系统的检测装置,所述装置包括:
接收模块,用于接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;
其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;
第一确定模块,用于响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;
第二确定模块,用于分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;
执行模块,用于基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。
上述方案中,所述第一确定模块,还用于获取各所述服务器的标识信息;
基于所述标识信息,确定各所述服务器的业务系统所对应的子业务。
上述方案中,所述第一确定模块,还用于基于所述标识信息,获取相应的所述服务器的设备参数;
基于所述设备参数、设备参数与子业务之间的映射关系,确定各所述服务器的业务系统所对应的子业务。
上述方案中,所述第一确定模块,还用于依据各所述服务器的互联网协议地址,分别建立与相应服务器的通信连接;
基于建立的所述通信连接及对应各所述服务器的账号密码,实现相应服务器的业务系统的登录;
基于登录的各所述服务器的业务系统,确定各所述服务器的业务系统所对应的子业务。
上述方案中,所述第二确定模块,还用于分别遍历各所述子业务对应的至少两个功能项;
将与各所述功能项相匹配的检测项,确定为相应的所述子业务对应的检测项。
上述方案中,所述执行模块,还用于分别获取各所述子业务对应的检测项所对应的检测代码;
运行各所述检测代码,以实现对相应的所述服务器的业务系统进行检测。
上述方案中,所述执行模块,还用于分别实时地对各所述服务器的业务系统执行相应的检测;或者,
分别周期性地对各所述服务器的业务系统执行相应的检测。
上述方案中,所述装置还包括:告警模块,所述告警模块用于获取各所述服务器的业务系统的检测结果,并
当所述检测结果表征相应的业务系统中存在错误时,通过以下至少之一的方式输出告警信息:邮件、短信、弹窗。
上述方案中,所述分别对各所述服务器的业务系统执行相应的检测之后,所述装置还包括存储模块,所述存储模块,用于获取各所述服务器的业务系统的检测结果;
存储各所述服务器的业务系统的检测结果至区块链网络。
上述方案中,所述存储模块,还用于生成包括公钥和私钥的非对称密钥对,并将各所述服务器的业务系统的检测结果以及所述公钥发送至区块链网络,以使
所述区块链网络的节点通过所述公钥对各所述服务器的业务系统的检测结果进行加密处理,并将加密后的各所述服务器的业务系统的检测结果以区块形式存储至区块链中;
所述业务系统的检测装置,还包括发送模块,所述发送模块,用于将所述私钥发送至具有对各所述服务器的业务系统的检测结果的查看权限的权限方,以使
所述权限方根据所述私钥,对所述区块链中的加密后的各所述服务器的业务系统的检测结果进行解密处理。
本发明实施例提供一种电子设备,包括:
存储器,用于存储可执行指令;
处理器,用于执行所述存储器中存储的可执行指令时,实现本发明实施例提供的业务系统的检测方法。
本发明实施例提供一种计算机可读存储介质,存储有可执行指令,用于引起处理器执行时,实现本发明实施例提供的业务系统的检测方法。
本发明实施例具有以下有益效果:
在接收到针对目标业务所对应的多个服务器的业务系统的检测指令时,确定每个服务器的业务系统对应目标业务所包括的至少一个子业务,并确定各个子业务的检测项,并基于各个子业务的检测项对相应的服务器的业务系统进行针对性地检测;如此,考虑了不同服务器的业务系统之间的业务差异,对各个服务器的业务系统的检测项进行针对地的检测,能够提高检测的准确度。
附图说明
图1为本发明实施例提供的业务系统的检测系统的一个可选的架构示意图;
图2为本发明实施例提供的业务系统的检测系统的一个可选的架构示意图;
图3为本发明实施例提供的电子设备的一个可选的结构示意图;
图4为本发明实施例提供的业务系统的检测方法的一个可选的流程示意图;
图5为本发明实施例提供的业务系统的检测方法的一个可选的流程示意图;
图6为本发明实施例提供的区块链网络中区块链的结构示意图;
图7为本发明实施例提供的业务系统的检测项的示意图;
图8为本发明实施例提供的系统层检测项示意图;
图9为本发明实施例提供的网络层检测项示意图;
图10为本发明实施例提供的应用层检测项示意图;
图11为本发明实施例提供的持久化检测示意图;
图12为本发明实施例提供的自动化运维检测示意图;
图13为本发明实施例提供的自动化运维检测示意图;
图14为本发明实施例提供的业务系统的检测装置的一个可选的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,所描述的实施例不应视为对本发明的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。
除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本发明实施例的目的,不是旨在限制本发明。
对本发明实施例进行进一步详细说明之前,对本发明实施例中涉及的名词和术语进行说明,本发明实施例中涉及的名词和术语适用于如下的解释。
1)区块链(Blockchain),是由区块(Block)形成的加密的、链式的交易的存储结构。例如,每个区块的头部既可以包括区块中所有交易的哈希值,同时也包含前一个区块中所有交易的哈希值,从而基于哈希值实现区块中交易的防篡改和防伪造;新产生的交易被填充到区块并经过区块链网络中节点的共识后,会被追加到区块链的尾部从而形成链式的增长。
2)区块链网络(Blockchain Network),通过共识的方式将新区块纳入区块链的一系列的节点的集合。
3)交易(Transaction),等同于计算机术语“事务”,交易包括了需要提交到区块链网络执行的操作,并非单指商业语境中的交易,鉴于在区块链技术中约定俗成地使用了“交易”这一术语,本发明实施例遵循了这一习惯。
例如,部署(Deploy)交易用于向区块链网络中的节点安装指定的智能合约并准备好被调用;调用(Invoke)交易用于通过调用智能合约在区块链中追加交易的记录,并对区块链的状态数据库进行操作,包括更新操作(包括增加、删除和修改状态数据库中的键值对)和查询操作(即查询状态数据库中的键值对)。
4)账本(Ledger),是区块链(也称为账本数据)和与区块链同步的状态数据库的统称。其中,区块链是以文件系统中的文件的形式来记录交易;状态数据库是以不同类型的键(Key)值(Value)对的形式来记录区块链中的交易,用于支持对区块链中交易的快速查询。
5)智能合约(Smart Contracts),也称为链码(Chaincode)或应用代码,部署在区块链网络的节点中的程序,节点执行接收的交易中所调用的智能合约,来对账本数据库的键值对数据进行更新或查询的操作。
6)共识(Consensus),是区块链网络中的一个过程,用于在涉及的多个节点之间对区块中的交易达成一致,达成一致的区块将被追加到区块链的尾部,实现共识的机制包括工作量证明(PoW,Proof of Work)、权益证明(PoS,Proof of Stake)、股份授权证明(DPoS,Delegated Proof-of-Stake)、消逝时间量证明(PoET,Proof of Elapsed Time)等。
参见图1,图1为本发明实施例提供的业务系统的检测系统100的一个可选的架构示意图,为实现支撑一个示例性应用,终端200通过网络连接检测设备300,检测设备300将检测指令分发至目标业务所包括的子业务对应的服务器(示例性示出了服务器400-1、服务器400-2和服务器400-N),网络可以是广域网或者局域网,又或者是二者的组合,使用无线链路实现数据传输。
在实际应用中,终端200可以为智能手机、平板电脑、笔记本电脑等各种类型的用户终端,还可以为台式计算机、游戏机、电视机或者这些数据处理设备中任意两个或多个的组合;检测设备300可单独为一个用于接收终端发送的检测指令的服务器,也可以为目标业务所包括的多个子业务对应的服务器400中的其中一个,服务器400为相应的数据处理后台,既可以为单独配置的支持各种业务的一个服务器,亦可以配置为一个服务器集群,还可以为云服务器等。
终端200,用于在对目标业务的业务系统进行检测时,响应于用户的触发操作,生成并发送针对目标业务的检测指令至检测设备300;
检测设备300,用于接收到针对目标业务的检测指令,响应于检测指令,分别确定各服务器的业务系统所对应的子业务;分别确定各子业务对应的检测项,其中,检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;基于各子业务对应的检测项,分别对各服务器的业务系统执行相应的检测。
本发明实施例也可结合区块链技术实现,区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中,用户管理模块负责所有区块链参与者的身份信息管理,包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等,并且在授权的情况下,监管和审计某些真实身份的交易情况,提供风险控制的规则配置(风控审计);基础服务模块部署在所有区块链节点设备上,用来验证业务请求的有效性,并对有效请求完成共识后记录到存储上,对于一个新的业务请求,基础服务先对接口适配解析和鉴权处理(接口适配),然后通过共识算法将业务信息加密(共识管理),在加密之后完整一致的传输至共享账本上(网络通信),并进行记录存储;智能合约模块负责合约的注册发行以及合约触发和合约执行,开发人员可以通过某种编程语言定义合约逻辑,发布到区块链上(合约注册),根据合约条款的逻辑,调用密钥或者其它的事件触发执行,完成合约逻辑,同时还提供对合约升级注销的功能;运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出,例如:告警、监控网络情况、监控节点设备健康状态等。
参见图2,图2为本发明实施例提供的业务系统的检测系统110的一个可选的架构示意图,包括业务主体800,区块链网络600(示例性示出了共识节点610-1至共识节点610-3)、认证中心700,下面分别进行说明。
区块链网络600的类型是灵活多样的,例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例,任何业务主体的电子设备例如图1中的终端200、检测设备300、服务器400,都可以在不需要授权的情况下接入区块链网络600,成为区块链网络600中的客户端节点;以联盟链为例,业务主体在获得授权后其下辖的电子设备(例如图1中的终端200、检测设备300、服务器400)可以接入区块链网络600,成为区块链网络600中的客户端节点。
在一些实施例中,客户端节点可以只作为区块链网络600的观察者,即提供支持业务主体发起交易(例如,用于上链存储数据或查询链上数据)功能,对于区块链网络600的共识节点610的功能,例如排序功能、共识服务和账本功能等,客户端节点可以缺省或者有选择性(例如,取决于业务主体的具体业务需求)地实施。从而,可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络600中,通过区块链网络600实现数据和业务处理过程的可信和可追溯。
区块链网络600中的共识节点接收来自不同业务主体(例如图2中示出的业务主体800)的客户端节点(例如,图2中示出的归属于业务主体800的客户端节点810提交的交易,执行交易以存储各服务器的业务系统检测结果,执行交易的各种中间结果或最终结果可以返回业务主体的客户端节点中显示。
例如,客户端节点810可以订阅区块链网络600中感兴趣的事件,例如区块链网络600中特定的组织/通道中发生的交易,由共识节点610推送相应的交易通知到客户端节点810,从而触发客户端节点810中相应的业务逻辑。
下面以业务主体接入区块链网络以实现各服务器的业务系统的检测结果上链为例,说明区块链的示例性应用。
业务主体800的客户端节点810接入区块链网络600,成为区块链网络600的客户端节点。客户端节点810在获取各服务器的业务系统的检测结果后,生成提交各服务器的业务系统的检测结果的交易,在交易中指定了实现提交操作需要调用的智能合约以及向智能合约传递的参数,交易还携带了业务主体800的数字证书,并将交易广播到区块链网络600。其中,数字证书可由业务主体800向认证中心700进行登记注册得到。
区块链网络600中的节点610在接收到交易时,对交易携带的数字证书进行验证,数字证书验证成功后,根据交易中携带的业务主体800的身份,确认业务主体800是否是具有交易权限,数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署节点610自己的数字签名,并继续在区块链网络600中广播。
区块链网络600中具有排序功能的节点610接收到验证成功的交易后,将交易填充到新的区块中,并广播到区块链网络600提供共识服务的节点。
区块链网络600中的提供共识服务的节点610对新区块进行共识过程以达成一致,提供账本功能的节点将新区块追加到区块链的尾部,并执行新区块中的交易:对于提交各服务器的业务系统的检测结果的交易,将各服务器的业务系统的检测结果以键值对的形式存储至状态数据库。
下面以业务主体接入区块链网络以实现各服务器的业务系统的检测结果的查询为例,说明区块链网络的示例性应用。
客户端节点810在需要获取各服务器的业务系统的检测结果时,生成查询各服务器的业务系统的检测结果的交易,同时在交易中指定了实现查询操作需要调用的智能合约以及向智能合约传递的参数,交易还携带了业务主体800的数字证书。然后,客户端节点810将交易广播到区块链网络600,区块链网络的节点610经验证、区块填充及共识一致后,提供账本功能的节点610将形成的新区块追加到区块链的尾部,并执行新区块中的交易:对于查询各服务器的业务系统的检测结果的交易,从状态数据库中查询出各服务器的业务系统的检测结果,并将其发送至客户端节点810。值得说明的是,状态数据库中存储的数据通常与区块链存储的数据相同,在响应查询交易时,优先根据状态数据库中的数据进行响应,从而提升响应效率。
业务主体800执行的查询操作可延伸至任意具有交易权限的其他业务系统。举例来说,业务主体800是广告业务的内部运营方的系统,在获取广告业务对应的各服务器的业务系统的检测结果后,将各服务器的业务系统的检测结果进行上链。广告主投放端的业务系统可向区块链网络600发起查询各服务器的业务系统的检测结果的交易,此时广告主投放端的业务系统中的检测设备是区块链网络600中的客户端节点。区块链网络的节点610在验证广告主投放端的业务系统具有查询的权限后,从区块链(或状态数据库)中查询各服务器的业务系统的检测结果,并将各服务器的业务系统的检测结果发送至广告主投放端的业务系统,广告主投放端的业务系统可根据各服务器的业务系统的检测结果执行后续操作,如将各服务器的业务系统的检测结果展示于前端界面。
又如,业务主体800是直播业务的内部运营方的系统,在获取直播业务对应的各服务器的业务系统的检测结果后,将各服务器的业务系统的检测结果进行上链。直播客户端的业务系统可向区块链网络600发起查询各服务器的业务系统的检测结果的交易,此时直播客户端的业务系统中的检测设备是区块链网络600中的客户端节点。区块链网络的节点610在验证直播客户端的业务系统具有查询的权限后,从区块链(或状态数据库)中查询各服务器的业务系统的检测结果,并将各服务器的业务系统的检测结果发送至直播客户端的业务系统,直播客户端的业务系统可根据各服务器的业务系统的检测结果执行后续操作,如将各服务器的业务系统的检测结果展示于前端界面。
下面继续说明本发明实施例提供的电子设备的示例性应用。参见图3,图3为本发明实施例提供的电子设备500的一个可选的结构示意图,在实际应用中,电子设备500可以为图1中的终端200或检测设备300,以电子设备为图1所示的检测设备300为例,对实施本发明实施例的电子设备进行说明。图3所示的电子设备500包括:至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。电子设备500中的各个组件通过总线系统540耦合在一起。可理解,总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图3中将各种总线都标为总线系统540。
处理器510可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
用户接口530包括使得能够呈现媒体内容的一个或多个输出装置531,包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530还包括一个或多个输入装置532,包括有助于用户输入的用户接口部件,比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器550可以是可移除的,不可移除的或其组合。示例性的硬件设备包括固态存储器,硬盘驱动器,光盘驱动器等。存储器550可选地包括在物理位置上远离处理器510的一个或多个存储设备。
存储器550包括易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM,Read Only Me mory),易失性存储器可以是随机存取存储器(RAM,Random Access Memor y)。本发明实施例描述的存储器550旨在包括任意适合类型的存储器。
在一些实施例中,存储器550能够存储数据以支持各种操作,这些数据的示例包括程序、模块和数据结构或者其子集或超集,下面示例性说明。
操作系统551,包括用于处理各种基本系统服务和执行硬件相关任务的系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务;
网络通信模块552,用于经由一个或多个(有线或无线)网络接口520到达其他计算设备,示例性的网络接口520包括:蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB,Universal Serial Bus)等;
呈现模块553,用于经由一个或多个与用户接口530相关联的输出装置531(例如,显示屏、扬声器等)使得能够呈现信息(例如,用于操作外围设备和显示内容和信息的用户接口);
输入处理模块554,用于对一个或多个来自一个或多个输入装置532之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中,本发明实施例提供的业务系统的检测装置可以采用软件方式实现,图3示出了存储在存储器550中的业务系统的检测装置555,其可以是程序和插件等形式的软件,包括以下软件模块:接收模块5551、第一确定模块5552、第二确定模块5553和执行模块5554,这些模块是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中,本发明实施例提供的业务系统的检测装置可以采用硬件方式实现,作为示例,本发明实施例提供的业务系统的检测装置可以是采用硬件译码处理器形式的处理器,其被编程以执行本发明实施例提供的业务系统的检测方法,例如,硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC,Application SpecificIntegrated Circuit)、DSP、可编程逻辑器件(PLD,Programmable Logic Device)、复杂可编程逻辑器件(CPLD,Complex Programmable Logic Device)、现场可编程门阵列(FPGA,Field-Pro grammable Gate Array)或其他电子元件。
接下来对本发明实施例的提供的业务系统的检测方法进行说明,参见图4,图4为本发明实施例提供的业务系统的检测方法的一个可选的流程示意图,将结合图4示出的步骤进行说明。
步骤101:检测设备接收到针对目标业务的检测指令,其中,检测指令指示对目标业务对应的至少两个服务器的业务系统进行检测。
这里,检测设备可为一个单独用于接收终端发送的检测指令的服务器,也可以为目标业务所包括的多个子业务对应的服务器中的一个,此时可称为主服务器,主服务器可分别根据服务器信息列表中的各个服务器的账号密码连接对应的服务器。
在实际应用中,终端上设置有客户端,如视频播放客户端、购物客户端、直播客户端、政务客户端、教育客户端等。为了保证目标业务整体稳定运行,需要实时检测与目标业务相关的各项指标是否正常,而一个业务系统背后,往往涉及多个服务器、网络设备等硬件资源,每个服务器的业务系统对应目标业务包括的至少一个子业务。
例如,基于直播客户端的直播业务涉及业务服务器、视频服务器、流媒体服务器等多种服务器,每个服务器的业务系统对应直播业务包括的至少一个子业务。为了保证直播业务系统的稳定运行,在对直播业务进行检测时,检测指令用于对直播业务涉及的业务服务器、视频服务器、流媒体服务器等多种服务器的业务系统进行检测。
步骤102:响应于检测指令,分别确定各服务器的业务系统所对应的子业务。
在一些实施例中,检测设备可通过如下方式分别确定各服务器的业务系统所对应的子业务:
获取各服务器的标识信息;基于标识信息,确定各服务器的业务系统所对应的子业务。
其中,标识信息可以是设备标识或其他能够标识该服务器的信息,如服务器对应的管理用户的用户标识。在实际应用中,针对目标业务所包括的多个子业务的服务器都有相应的标识信息,通过各服务器的标识信息,可对各个服务器进行针对性地管理、监控及检测。
在一些实施例中,检测设备可通过如下方式基于标识信息,确定各服务器的业务系统所对应的子业务:
基于标识信息,获取相应的服务器的设备参数;基于设备参数、设备参数与子业务之间的映射关系,确定各服务器的业务系统所对应的子业务。
这里,可将设备参数与子业务之间映射关系通过映射表的形式来体现,基于设备参数及映射表,可确定各服务器的业务系统所对应的子业务。例如,服务器1、服务器2、服务器3的设备参数分别为:设备参数1、设备参数2、设备参数3,且设备参数1、设备参数2、设备参数3分别与子业务1、子业务2、子业务3一一映射对应,则可确定服务器1的业务系统对应的业务为子业务1,服务器2的业务系统对应的业务为子业务2,服务器3的业务系统对应的业务为子业务3。
在一些实施例中,可通过如下方式分别确定各服务器的业务系统所对应的子业务:
依据各服务器的互联网协议地址,分别建立与相应服务器的通信连接;基于建立的通信连接及对应各服务器的账号密码,实现相应服务器的业务系统的登录;基于登录的各服务器的业务系统,确定各服务器的业务系统所对应的子业务。
这里,各服务器的互联网协议地址和账号密码可存储于服务器信息列表中,检测设备也即主服务器可通过expect工具,根据服务器信息列表中的各服务器的互联网协议地址,分别建立与相应服务器的通信连接,并在建立通信连接的基础上,登录账号密码实现相应服务器的业务系统的登录;当登录各服务器的业务系统后,根据各服务器的业务标识,确定各服务器的业务系统所对应的子业务。
步骤103:分别确定各子业务对应的检测项。
这里,检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一,其中,系统层检测项为了保证系统层级基础及核心模块检测,网络层检测项为了保证网络层级的检测,应用层检测项为了保证业务系统应用层级的服务检测。
在一些实施例中,可通过如下方式分别确定各子业务对应的检测项:
分别遍历各子业务对应的至少两个功能项;将与各功能项相匹配的检测项,确定为相应的子业务对应的检测项。
在实际应用中,目标业务的应用大都是基于类Uinx服务器操作系统的,在部署交互目标业务应用时必须做到集系统层检测项、网路层检测项和应用层检测项于一体的检测,而针对不同的子业务,所需的检测项会有所不同,例如,根据子业务的业务类型,确定检测项为存储、数据库等;根据子业务的系统发行版本,当系统发行版本分别为:RHEL6.X、RHEL7.X、RHEL8.X时,确定检测项分别为对应RHEL6.X、RHEL7.X、RHEL8.X的检测;根据子业务防火墙类型确定对应防火墙相应类型的检测项,等等。
步骤104:基于各子业务对应的检测项,分别对各服务器的业务系统执行相应的检测。
在一些实施例中,可通过如下方式基于各子业务对应的检测项,分别对各服务器的业务系统执行相应的检测:
分别获取各子业务对应的检测项所对应的检测代码;运行各检测代码,以实现对相应的服务器的业务系统进行检测。
这里,在对各服务器的业务系统的系统层检测项进行检测时,通过系统自带的命令工具,调用各子业务对应的检测项所对应的检测代码,并运行各检测代码对如下检测项进行检测:底层运行平台、内核版本号、软件包版本、安全上下文、防火墙启停、中央处理器(CPU,Central Processing Unit)负载、磁盘读写、内存、交换区、磁盘分区、磁盘写性能、磁盘随机读性能、时间同步。
在实际实施时,基于检测指令及系统自带的命令工具,对底层运行平台进行检测,如果是物理机,输出硬件厂商型号如:2288H V5;如果是云主机,输出云平台类型,如OpenStack Nova;如此,在云计算、虚拟化以及容器等运行单元发展迅速的今天,准确的分辨出各大业务系统底层运行环境,并将各大业务系统底层运行环境纳入软硬件的考虑范围,便于故障分析,能够提高业务运维质量。
内核是linux操作系统的核心,能够管理如聊天、玩游戏等业务的应用程序,为应用程序准备好运行内存、管理应用程序的执行,还可管理硬件设备,对内核版本号进行检测,能够检测内核当前版本是否存在安全问题,只有当内核安全时,才能确保业务系统的稳定。
软件包版本检测,例如软件包为OpenSSL和OpenSSH时,主要是为了确保OpenSSL和OpenSSH版本是否为最新版本,这将决定业务系统是否符合国家要求的系统层面的等级保护标准。其中,OpenSSL是一个开放源代码的软件库包,应用程序可以使用这个包来进行安全通信,避免窃听,同时确认另一端连接者的身份,这个包广泛被应用在互联网的网页服务器上。OpenSSH是SSH(Secure SHell)协议的免费开源实现,提供了服务端后台程序和客户端工具,用来加密远程控制和文件传输过程中的数据,并由此来代替原来的类似服务。
安全上下文检测,主要是对运行中的程序如进程、进程发起者的身份等进行检测,由于进程所能够访问的所有资源的权限取决于进程的发起者的身份,因此对安全上下文进行检测主要是为了确保进程发起者的身份得到过认证授权,便于后续问题的定位。
防火墙启停检测,主要是为了保证防火墙处于启动状态,加强业务系统的安全运营。
CPU是服务器硬件的核心组成单元,在保证业务系统不受影响的情况下C PU的负载需要保持在一个阈值范围以下的维度,时刻检查CPU负载情况将决定业务运行的稳定性,比如定时输出6小时内CPU的平均负载,看有无异常增长的波动。
磁盘读写检测,主要是为了检测服务应用在进行数据读写时是否存在异常情况,以及检测当前活跃用户是否处于高峰、是否出现应用报错导致日志大量打印从而引起磁盘读写负载增强,如此,通过返回量化数据为日后优化服务应用做准备。
对内存进行检测,是通过检测当前内存使用量是否达到了内存阈值,通常情况下,为了避免内容消耗殆尽造成服务宕机等一级事故,内存使用量得不高于内存总量的80%,当内存不足时应进行相应的告警提示,并当内存剩余量不足以满足应用的需求时,时刻检查交换分区的资源情况,如发现交换分区被调用,则将起到风险预警的作用,此时应该及时增加物理内存。
磁盘分区检测,主要是为了提供量化数据,分析当前应用数据已经生成多少,以及当接近阈值范围时需要及时告警,提示需对磁盘进行及时扩容,避免系统重启等。
磁盘写性能、磁盘随机读性能等磁盘压测,需在非业务敏感期定期通过任意的方法进行,主要为了时刻检测磁盘硬件是否有坏道,或是否出现类似硬件故障而导致磁盘读写性能下降进而影响业务系统的正常运营。
时间同步检测,主要是为了检测服务器当前是否出现延时情况,如果出现延时且未及时发现,将会造成严重的后果,比如财务应用,电商应用,对时间上的要求非常敏感,延时将带来巨大的经济损失;除此之外,时延还会导致用户端时间定位不对应,日志文件生成异常等情况。
在对各服务器的业务系统的网络层检测项进行检测时,需要检测出口网络的连接情况,如可达或中断,还需检测出口访问速度,如快速、延时或超时等;如此,针对出口网络进行不同维度的检测,便于当与出口网络交互的子业务功能出现问题时,对问题进行定位排查,例如,排查问题是由本地局域网、硬件防火墙、出口网络、运营商还是对端请求域名服务器中哪个环节出现问题引起的。
在对各服务器的业务系统的应用层检测项进行检测时,业务系统需要对外提供服务,业务的稳定性与安全性是否得到保障,对于用户来说是非常重要的,业务的类型越来越多,针对业务应用本身的检测方法也各不相同,面对各种各样的应用服务,需要维护商针对性的开发工具或软件等进行深度的检测。通常情况下,需要检测如下检测项:
如涉及到B/S架构应用,需检查web服务器的状态;通过应用日志检测服务是否已经或曾经异常重启;检测应用服务是否由于内存不足导致服务无法启动而影响业务系统的正常运营;检测应用服务是否由于访问人数过多导致并发数不足而造成业务系统的崩溃;检测业务数据库的使用状态是否正常;检测业务服务状态是否正常等。
在一些实施例中,检测设备分别对各服务器的业务系统执行相应的检测:
分别实时地对各服务器的业务系统执行相应的检测;或者,分别周期性地对各服务器的业务系统执行相应的检测。
这里,在实际应用中,为了确保目标业务的业务系统能够稳定运行,需要实时检测与目标业务相关的各项指标是否正常,而一个业务系统的背后,往往存在着很多服务器、网络设备等硬件资源,为了能够更加方便的、集中的检测,需要依靠一些外部的实现集中监控管理的应用程序,如zabbix、cacti、nagios、ganglia。
在一些实施例中,分别对各服务器的业务系统执行相应的检测之后,检测设备还获取各服务器的业务系统的检测结果,并当检测结果表征相应的业务系统中存在错误时,通过以下至少之一的方式输出告警信息:邮件、短信、弹窗。
通过上述方式,当业务系统中存在错误时,立刻触发自动邮件、短信或弹窗的方式将检测日志信息发送给运维人员,以便运维人员及时查看日志信息排查故障原因,尽快使业务系统恢复正常。
在一些实施例中,参见图5,图5为本发明实施例提供的业务系统的检测方法的一个可选的流程示意图,基于图4,在步骤104之后,还可以在步骤105中,存储各服务器的业务系统的检测结果至区块链网络。
在实际实施时,可通过如下方式存储各服务器的业务系统的检测结果至区块链网络:
生成包括公钥和私钥的非对称密钥对,并将各服务器的业务系统的检测结果以及公钥发送至区块链网络,以使区块链网络的节点通过公钥对各服务器的业务系统的检测结果进行加密处理,并将加密后的各服务器的业务系统的检测结果以区块形式存储至区块链中。
在获取各服务器的业务系统的检测结果后,可将各服务器的业务系统的检测结果保存至外部存储,以便涉及到目标业务的相关人员查看。作为区块链的示例,参见图6,图6为本发明实施例提供的区块链网络中区块链的结构示意图,每个区块的头部既可以包括区块中所有交易的哈希值,同时也包含前一个区块中所有交易的哈希值,新产生的交易的记录被填充到区块并经过区块链网络中节点的共识后,会被追加到区块链的尾部从而形成链式的增长,区块之间基于哈希值的链式结构保证了区块中交易的防篡改和防伪造。
在本发明实施例中,可将各服务器的业务系统的检测结果以交易形式发送至区块链网络,区块链网络的节点经验证后将各服务器的业务系统的检测结果填充至新区块,并在对新区块共识一致时,将新区块追加至区块链的尾部。完成各服务器的业务系统的检测结果的上链后,可向区块链网络发送查询请求,从而查询区块链上的各服务器的业务系统的检测结果。值得说明的是,在将新区块追加至区块链的尾部的同时,还可将各服务器的业务系统的检测结果存储至状态数据库,并优先根据状态数据库中的数据响应查询请求,从而提升响应效率。
由于区块链具有公开透明的特性,为了保证区块链上的各服务器的业务系统的检测结果的保密性,避免恶意方非法查询各服务器的业务系统的检测结果,在本发明实施例中,可生成包括公钥和私钥的非对称密钥对,这里对非对称密钥对的生成方式不做限定,例如可通过RSA加密算法生成。然后,将各服务器的业务系统的检测结果以及公钥以交易形式发送至区块链网络,区块链网络根据预先部署的智能合约,通过公钥对各服务器的业务系统的检测结果进行加密处理,并将加密处理的各服务器的业务系统的检测结果填充至新区块中,最终在对新区块共识一致时,将新区块追加至区块链的尾部。
在一些实施例中,可以通过如下方式来实现上述的将各服务器的业务系统的检测结果以及公钥发送至区块链网络:对各服务器的业务系统的检测结果进行哈希处理,得到摘要信息;根据私钥对摘要信息进行加密处理,得到数字签名;将各服务器的业务系统的检测结果、公钥及数字签名发送至区块链网络,以使区块链网络的节点根据公钥和数字签名,对接收到的各服务器的业务系统的检测结果进行完整性验证,并在完整性验证成功时,执行对各服务器的业务系统的检测结果的加密及存储。
为了保证数据上传的完整性,在本发明实施例中,可对各服务器的业务系统的检测结果进行哈希处理,得到摘要信息,为了便于区分,将这里得到的摘要信息命名为第一摘要信息。然后,根据私钥对第一摘要信息进行加密处理,得到数字签名,将各服务器的业务系统的检测结果、公钥及数字签名以交易形式发送至区块链网络。区块链网络的节点在接收到该交易后,根据接收到的公钥对数字签名进行解密,同时对接收到的各服务器的业务系统的检测结果进行哈希处理,得到第二摘要信息。当对数字签名进行解密得到的结果与第二摘要信息一致时,完整性验证成功,区块链网络的节点通过公钥对各服务器的业务系统的检测结果进行加密处理,并将加密后的各服务器的业务系统的检测结果以区块形式存储于区块链中;当对数字签名进行解密得到的结果与第二摘要信息不一致时,完整性验证失败,区块链网络的节点可提示各服务器的业务系统的检测结果的上传方进行重新上传。通过上述方式,保证了区块链上数据的准确性。
在一些实施例中,还可将私钥发送至具有对各服务器的业务系统的检测结果的查看权限的权限方,以使权限方根据私钥,对区块链中的加密后的各服务器的业务系统的检测结果进行解密处理。
这里,除了上传各服务器的业务系统的检测结果的上传方外,各服务器的业务系统的检测结果还可能需要被其他具有查看权限的权限方查询,故将私钥发送至权限方。权限方可向区块链网络发送查询请求,以获取区块链中的加密后的各服务器的业务系统的检测结果,并通过私钥对加密后的各服务器的业务系统的检测结果进行解密处理。如此,区块链公开的是加密后的各服务器的业务系统的检测结果,故就算恶意方取得了加密后的各服务器的业务系统的检测结果,也无法得知其中的真实内容,提升了安全系数。
通过发明实施例对于图5的上述示例性实施可知,本发明实施例通过将得到的各服务器的业务系统的检测结果进行上链,从而能够向查询方提供更为准确的各服务器的业务系统的检测结果,并且,通过加密的方式提升了链上数据的安全性,有效地避免了恶意方查询。
下面,将说明本发明实施例在一个实际的应用场景中的示例性应用,随着网络强国建设整体推进,网络安全保障能力稳步提升,互联网在经济社会发展中的重要作用更加凸显,截止2019年上半年,中国互联网发展呈现如下六个特点:
1)IPv6地址数量全球第一,“.CN”域名数量持续增长。
截至2019年6月,我国IPv6地址数量为50286块/32,较2018年底增长14.3%,已跃居全球第一位。
2)互联网普及率超过六成,移动互联网使用持续深化。
截至2019年6月,我国网民规模达8.54亿,较2018年底增长2598万,互联网普及率达61.2%,较2018年底提升1.6个百分点;我国手机网民规模达8.47亿,较2018年底增长2984万,网民使用手机上网的比例达99.1%,较2018年底提升0.5个百分点。
3)下沉市场释放消费动能,跨境电商等领域持续发展。
截至2019年6月,我国网络购物用户规模达6.39亿,较2018年底增长2871万,占网民整体的74.8%。网络购物市场保持较快发展,下沉市场、跨境电商、模式创新为网络购物市场提供了新的增长动能。
4)网络视频运营更加专业,娱乐内容生态逐步构建。
截至2019年6月,我国网络视频用户规模达7.59亿,较2018年底增长3391万,占网民整体的88.8%。
5)在线教育应用稳中有进,弥补乡村教育短板。
截至2019年6月,我国在线教育用户规模达2.32亿,较2018年底增长3122万,占网民整体的27.2%。
6)在线政务普及率近六成,服务水平持续向好。
截至2019年6月,我国在线政务服务用户规模达5.09亿,占网民整体的59.6%。
由此可以看出,在业务系统用户流量日益庞大的背景下,稳定运营是首要原则;如何保证各大业务系统稳定的运营,已经深入到用户的方方面面,如何在第一时间确定业务系统的是否异常?这是一个难题。
本发明实施例综合考虑了各大IT项目中业务应用都用到的类Unix服务器操作系统,如社区企业操作系统(CentOS,Community Enterprise Operating S ystem)在部署交付应用,对业务系统进行检测时,做到如图7所示的集系统层检测项、网络层检测项和应用层检测项于一体的检测,图7为本发明实施例提供的业务系统的检测项的示意图,图7中,系统层检测项包括内核、CPU、内存、磁盘等,为了保证系统层级基础及核心模块检测;网络层检测项包括速度、超时等,为了保证网络层级的检测;应用层检测项包括服务主题、告警日志等,为了保证业务系统应用层级的服务检测。
以即时通讯产品为例,需检查输出通往云端服务器的业务请求域名链路情况,并且会在自定义的产品日志中呈现,提供管理人员查阅历史数据;还需检查输出应用微服务的运行状态,查看是否出现应用宕机或其它异常情况,并且会在自定义的产品日志中呈现,提供管理人员查阅历史数据。
以各大互联网应用服务器为例,只要是运行基于类Unix平台的系统,遵守基于“一切皆文件”原则下,在磁盘空间日渐增长的情况下,需要每日统计实时业务增长数据,将如下所示的检测结果提交给相关人员供相关人员参考:
Figure BDA0002534491520000231
例如,相关人员可从检测结果中得出:对于“sda3”这一磁盘,总共可利用容量为4605429104G,已经使用容量为184559572G,剩余可用容量为4188745180G,利用率为5%,业务增长量为2008.48MB;如此,相关人员根据每日业务增长数据量,判断磁盘的使用情况,并基于使用情况对业务系统进行监控。
在实际实施时,在对业务系统进行检测时,主要从以下方面进行检测:系统层检测、网络层检测、应用层检测、持久化检测和自动化运维检测,接下来将逐一进行说明。
1、系统层检测
参见图8,图8为本发明实施例提供的系统层检测项示意图,如图8所示,系统层检测项包括:底层运行平台(physical or virtual machine)、内核版本号(kernelversion)、软件包版本、安全上下文(selinux)、防火墙启停(iptables firewalld)、中央处理器(CPU)负载、磁盘读写(disk io)、内存(memory)、交换区(swap)、磁盘分区(disk)、磁盘写性能(disk sequential write peed)、磁盘随机读性能(disk random reading speed)、时间同步(datetime)。
1)底层运行平台(physical or virtual machine)检测:在实际实施时,基于检测指令及系统自带的命令工具,对底层运行平台进行检测,如果检测的是物理机,输出硬件厂商型号如:2288H V5;如果检测的是云主机,输出云平台类型,如Open Stack Nova;如果检测的是是虚拟机,输出Kvm、Xen或Vmw are;如果检测的是容器,则输出docker;如果检测的是云实例,则输出云主题;如此,在云计算、虚拟化以及容器等运行单元发展迅速的今天,准确的分辨出各大业务系统底层运行环境,并将各大业务系统底层运行环境纳入软硬件的考虑范围,便于故障分析,能够提高业务运维质量。
2)内核版本号(kernel version)检测:内核是linux操作系统的核心,能够管理如聊天、玩游戏等业务的应用程序,为应用程序准备好运行内存、管理应用程序的执行,还可管理硬件设备,对内核版本号进行检测,能够检测内核当前版本是否存在安全问题,只有当内核安全时,才能确保业务系统的稳定。
3)软件包版本检测:例如当软件包为OpenSSL和OpenSSH时,主要是为了确保OpenSSL和OpenSSH版本是否为最新版本,这将决定业务系统是否符合国家要求的系统层面的等级保护标准。其中,OpenSSL是一个开放源代码的软件库包,应用程序可以使用这个包来进行安全通信,避免窃听,同时确认另一端连接者的身份,这个包广泛被应用在互联网的网页服务器上。OpenSSH是SSH(Secure SHell)协议的免费开源实现,提供了服务端后台程序和客户端工具,用来加密远程控制和文件传输过程中的数据,并由此来代替原来的类似服务。
4)安全上下文(selinux)检测:主要是对运行中的程序如进程、进程发起者的身份等进行检测,由于进程所能够访问的所有资源的权限取决于进程的发起者的身份,因此对安全上下文进行检测主要是为了确保进程发起者的身份得到过认证授权,便于后续问题的定位。
5)防火墙启停(iptables firewalld)检测:主要是为了保证防火墙处于启动状态,加强业务系统的安全运营。
6)中央处理器(CPU)负载检测:CPU是服务器硬件的核心组成单元,在保证业务系统不受影响的情况下CPU的负载需要保持在一个阈值范围以下的维度,时刻检测CPU负载情况将决定业务运行的稳定性。例如,当检测不足6小时时,输出实际检测时长内CPU的平均负载,当检测超过6小时时,则定时输出6小时内CPU的平均负载,看有无异常增长的波动,提供给相关人员的检测结果如下:
Figure BDA0002534491520000251
相关人员可从上述检测结果中可知,在11:40:01AM~03:10:01PM这一段时间内,CPU的平均负载率或空闲率(即%idle)在99.94%~99.95%之间,通常而言,CPU的空闲率越大,其实际使用率就越小,那么可知,在上述时间端内,CPU的使用率仅在0.05%~0.06%之间,意味着CPU使用正常,并无异常增长波动。
7)磁盘读写负载检测:磁盘读写检测主要是为了检测服务应用在进行数据读写时是否存在异常情况,以及检测当前活跃用户是否处于高峰、是否出现应用报错导致日志大量打印从而引起磁盘读写负载增强,例如,提供给相关人员的磁盘读写负载检测结果如下:
Figure BDA0002534491520000252
相关人员可从上述检测结果中可知,磁盘负载率(即%idle)为99.96%,即磁盘的使用率仅在0.04%,磁盘处于正常情况。如此,相关人员可通过返回量化数据为日后优化服务应用做准备。
8)内存(memory)检测:对内存进行检测,是通过检测当前内存使用量是否达到了内存阈值,通常情况下,为了避免内容消耗殆尽造成服务宕机等一级事故,内存使用量得不高于内存总量的80%,通过判断当前内存使用量是否达到了阈值范围,并进行相应的告警提示,内存不足在日常服务器应用的维护中是不该被允许的。
9)交换区(swap)检测:当内存不足时应进行相应的告警提示,并当内存剩余量不足以满足应用的需求时,时刻检查交换分区的资源情况,如发现交换分区被调用,则将起到风险预警的作用,此时应该及时增加物理内存。
10)磁盘分区(disk)检测:主要是为了提供量化数据,分析当前应用数据已经生成多少,以及当接近阈值范围时需要及时告警,提示需对磁盘进行及时扩容,避免系统重启等。
11)磁盘写性能(disk sequential write peed)压测:需在非业务敏感期定期通过任意的方法进行,主要为了时刻检测磁盘硬件是否有坏道,或是否出现类似硬件故障而导致磁盘读写性能下降进而影响业务系统的正常运营。例如,提供给相关人员的检测结果如下:
Figure BDA0002534491520000261
2000+0 records out
2097152000 bytes(2.1GB)copied,6.49504s,323MB/s
可知,当前磁盘写的速率为323MB/s,磁盘写的速度是否正常,根据相关人员设定的标准不同而不同,例如,当相关人员设定磁盘正常写速度为300M B/s~400MB/s时,323MB/s这一写速度表征磁盘读写性能正常,而比较小的写速度如70MB/s表征磁盘写性能是非正常的,相关人员可排查故障原因,如磁盘硬件可能有坏道,或类似硬件故障。
12)磁盘随机读性能(disk random reading speed)压测:需在非业务敏感期定期通过任意的方法进行,主要为了时刻检测磁盘硬件是否有坏道,或是否出现类似硬件故障而导致磁盘读写性能下降进而影响业务系统的正常运营。具体检测结果的表现和故障排查类似上述磁盘写性能压测,这里不在赘述。
13)时间同步(datetime)检测:主要是为了检测服务器当前是否出现延时情况,如果出现延时且未及时发现,将会造成严重的后果,比如财务应用,电商应用,对时间上的要求非常敏感,延时将带来巨大的经济损失;除此之外,时延还会导致用户端时间定位不对应,日志文件生成异常等情况。
2、网络层检测
参见图9,图9为本发明实施例提供的网络层检测项示意图,如图9所示,在对各服务器的业务系统的网络层检测项进行检测时,需要检测出口网络的连接情况,如可达或中断,还需检测出口访问速度,如快速、延时或超时等。当出口网络超时,可呈现相应的延时时间,如“2seconds delay or timeout”的检测结果,当出口网络正常情况时,可呈现如“0seconds delay or timeout”的检测结果。
通过上述方式,针对出口网络进行不同维度的检测,便于当与出口网络交互的子业务功能出现问题时,对问题进行定位排查,例如,排查问题是由本地局域网、硬件防火墙、出口网络、运营商还是对端请求域名服务器中哪个环节出现问题引起的。
3、应用层检测
在对各服务器的业务系统的应用层检测项进行检测时,业务系统需要对外提供服务,业务的稳定性与安全性是否得到保障,对于用户来说是非常重要的,业务的类型越来越多,针对业务应用本身的检测方法也各不相同,面对各种各样的应用服务,需要维护商针对性的开发工具或软件等进行深度的检测。
参见图10,图10为本发明实施例提供的应用层检测项示意图,如图10所示,应用层检测项包括:服务状态、告警日志、进程僵死和数据读写等。
1)服务状态:如涉及到B/S架构应用,需检查web服务器的状态,例如,检测nginx的服务状态,以检测nginx目录下的各个进程是否正常启动。nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like协议下发行,具有占有内存少,并发能力强等优点。
2)告警日志:通过告警日志检测服务是否已经或曾经异常重启;
3)进程僵死:检测应用服务是否由于内存不足导致服务无法启动而影响业务系统的正常运营;或是否由于访问人数过多导致并发数不足而造成业务系统的崩溃;
4)数据读写:检测业务数据库的使用状态是否正常;检测业务服务状态是否正常等。
4、持久化检测
发明人在实施本发明实施例时发现,当开发人员开发简单的脚本后,通过crontab定时任务对Linux业务系统进行检测,将输出结果保存到日志中,以使运维人员定期登录系统查阅检测结果确定业务系统是否出现隐患的这一检测方式,存在低失效性、低持续性、低及时性、高成本及低效率等缺点。基于此,为了持续性对业务系统进行检测与监控,本发明实施例采用zabbix运维监控系统,实时地对业务系统执行相应的检测。
参见图11,图11为本发明实施例提供的持久化检测示意图,本发明实施例融入zabbix运维监控系统进行持久检测、自动检测,对所有检测结果的日志按天进行永久保存,定时发送静态业务数据报告等检测结果,并当检测结果表征相应的业务系统中存在错误时,通过如下所示的邮件输出告警信息至相关人员,及时地提醒相关人员在第一时间查看检测结果对问题进行排查。
今天(1封)
Figure BDA0002534491520000281
昨天(2封)
Figure BDA0002534491520000282
5、自动化运维检测
在实际应用中,一个目标业务的业务系统往往涉及多个服务器,每个服务器会充当不同的角色,即每个服务器的业务系统对应目标业务包括的至少一个子业务,并且不同角色之间的服务器又会存在某种逻辑或业务层面的联系。因此在对目标业务的业务系统进行自动化运维检测时,可通过检测设备将检测指令下发至各服务器中,上述的检测设备可为一个单独用于接收终端发送的检测指令的服务器,也可以为目标业务所包括的多个子业务对应的服务器中的一个,此时可称为主服务器,主服务器可通过expect工具分别根据服务器信息列表中的各个服务器的账号密码连接对应的服务器。
在实际实时,上述检测设备在接收到针对目标业务所对应的多个服务器的业务系统的检测指令时,确定每个服务器的业务系统对应目标业务所包括的至少一个子业务,并确定各个子业务的检测项,基于各个子业务的检测项对相应的服务器的业务系统进行针对性地检测。
参见图12,图12为本发明实施例提供的自动化运维检测示意图,各服务器如服务器1~服务器6的互联网协议地址和账号密码可存储于服务器信息列表中,检测设备也即主服务器通过expect工具,依据各服务器的互联网协议地址,分别建立与相应服务器的通信连接;基于建立的通信连接及对应各服务器的账号密码,实现相应服务器的业务系统的登录;基于登录的各服务器的业务系统,对各服务器进行角色判断,基于各服务器的业务标识确定各服务器的业务系统所对应的子业务。
参见图13,图13为本发明实施例提供的自动化运维检测示意图,在实际实施时,通过检测工具内置功能实现,即目标业务所对应的所有服务器被自动触发执行检测任务时,检测指令传达到所有服务器执行检测前会预先执行内置代码中角色判断的函数;对于基于角色判断得到的不同服务器所对应的子业务,针对性的设计不同的检测项,当角色判断函数执行结束返回结果时,代码逻辑会自动匹配运行相对应的自定义检测函数中。
例如,判断子业务的系统发行版本,根据发行版本的不同,如当系统发行版本分别为:RHEL6.X、RHEL7.X、RHEL8.X时,而执行相应的检测语句进行检测;判断子业务的业务类型,根据业务类型的不同执行相关检测语句进行检测;根据子业务的防火墙类型,决定执行iptables相关检测语句或执行ifirewal ld相关检测语句,等等。
需要说明的是,在对上述检测时,需连同上述系统层检测项、网络层检测项及应用层检测项等基础检测项开启执行完整的、正式的检测并最终输出完整的检测结果报告。
通过本发明实施例,能够实现以下技术效果:
1)对目标业务的业务系统同时进行检测和监控,做到真正的巡检,及时发现并处理故障和隐患,保障业务系统的稳步运营。
2)执行高密度的检测以及监控,进一步提高了业务系统的自动化检测的高度。
3)当发现错误时,运维人员会第一时间收到告警邮件,降低反应的时间。
4)通过内置函数的智能判断,可以辨别业务系统不同角色的服务器,进而执行自定义的检测项,能够提高检测的准确度。
下面继续说明本发明实施例提供一种业务系统的检测装置实施为软件模块的示例性结构,在一些实施例中,参见图14,图14为本发明实施例提供的业务系统的检测装置的一个可选的结构示意图,包括:
接收模块5551,用于接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;
其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;
第一确定模块5552,用于响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;
第二确定模块5553,用于分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;
执行模块5554,用于基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。
在一些实施例中,所述第一确定模块,还用于获取各所述服务器的标识信息;
基于所述标识信息,确定各所述服务器的业务系统所对应的子业务。
在一些实施例中,所述第一确定模块,还用于基于所述标识信息,获取相应的所述服务器的设备参数;
基于所述设备参数、设备参数与子业务之间的映射关系,确定各所述服务器的业务系统所对应的子业务。
在一些实施例中,所述第一确定模块,还用于依据各所述服务器的互联网协议地址,分别建立与相应服务器的通信连接;
基于建立的所述通信连接及对应各所述服务器的账号密码,实现相应服务器的业务系统的登录;
基于登录的各所述服务器的业务系统,确定各所述服务器的业务系统所对应的子业务。
在一些实施例中,所述第二确定模块,还用于分别遍历各所述子业务对应的至少两个功能项;
将与各所述功能项相匹配的检测项,确定为相应的所述子业务对应的检测项。
在一些实施例中,所述执行模块,还用于分别获取各所述子业务对应的检测项所对应的检测代码;
运行各所述检测代码,以实现对相应的所述服务器的业务系统进行检测。
在一些实施例中,所述执行模块,还用于分别实时地对各所述服务器的业务系统执行相应的检测;或者,
分别周期性地对各所述服务器的业务系统执行相应的检测。
在一些实施例中,所述装置还包括:告警模块,所述告警模块用于获取各所述服务器的业务系统的检测结果,并
当所述检测结果表征相应的业务系统中存在错误时,通过以下至少之一的方式输出告警信息:邮件、短信、弹窗。
在一些实施例中,所述分别对各所述服务器的业务系统执行相应的检测之后,所述装置还包括存储模块,所述存储模块,用于获取各所述服务器的业务系统的检测结果;
存储各所述服务器的业务系统的检测结果至区块链网络。
在一些实施例中,所述存储模块,还用于生成包括公钥和私钥的非对称密钥对,并将各所述服务器的业务系统的检测结果以及所述公钥发送至区块链网络,以使
所述区块链网络的节点通过所述公钥对各所述服务器的业务系统的检测结果进行加密处理,并将加密后的各所述服务器的业务系统的检测结果以区块形式存储至区块链中;
所述业务系统的检测装置,还包括发送模块,所述发送模块,用于将所述私钥发送至具有对各所述服务器的业务系统的检测结果的查看权限的权限方,以使所述权限方根据所述私钥,对所述区块链中的加密后的各所述服务器的业务系统的检测结果进行解密处理。
本发明实施例提供一种电子设备,包括:
存储器,用于存储可执行指令;
处理器,用于执行所述存储器中存储的可执行指令时,实现本发明实施例提供的业务系统的检测方法。
本发明实施例提供一种存储介质,存储有可执行指令,用于引起处理器执行时,实现本发明实施例提供的业务系统的检测方法。
在一些实施例中,存储介质可以是FRAM、ROM、PROM、EPROM、EE PROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器;也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中,可执行指令可以采用程序、软件、软件模块、脚本或代码的形式,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例,可执行指令可以但不一定对应于文件系统中的文件,可以可被存储在保存其它程序或数据的文件的一部分,例如,存储在超文本标记语言(HTML,Hyper TextMarkup Language)文档中的一个或多个脚本中,存储在专用于所讨论的程序的单个文件中,或者,存储在多个协同文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。
作为示例,可执行指令可被部署为在一个计算设备上执行,或者在位于一个地点的多个计算设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上所述,仅为本发明的实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和范围之内所作的任何修改、等同替换和改进等,均包含在本发明的保护范围之内。

Claims (10)

1.一种业务系统的检测方法,其特征在于,所述方法包括:
接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;
其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;
响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;
分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;
基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。
2.如权利要求1所述的方法,其特征在于,所述分别确定各所述服务器的业务系统所对应的子业务,包括:
获取各所述服务器的标识信息;
基于所述标识信息,确定各所述服务器的业务系统所对应的子业务。
3.如权利要求1所述的方法,其特征在于,所述分别确定各所述服务器的业务系统所对应的子业务,包括:
依据各所述服务器的互联网协议地址,分别建立与相应服务器的通信连接;
基于建立的所述通信连接及对应各所述服务器的账号密码,实现相应服务器的业务系统的登录;
基于登录的各所述服务器的业务系统,确定各所述服务器的业务系统所对应的子业务。
4.如权利要求1所述的方法,其特征在于,所述分别确定各所述子业务对应的检测项,包括:
分别遍历各所述子业务对应的至少两个功能项;
将与各所述功能项相匹配的检测项,确定为相应的所述子业务对应的检测项。
5.如权利要求1所述的方法,其特征在于,所述基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测,包括:
分别获取各所述子业务对应的检测项所对应的检测代码;
运行各所述检测代码,以实现对相应的所述服务器的业务系统进行检测。
6.如权利要求1所述的方法,其特征在于,所述分别对各所述服务器的业务系统执行相应的检测,包括:
分别实时地对各所述服务器的业务系统执行相应的检测;或者,
分别周期性地对各所述服务器的业务系统执行相应的检测。
7.如权利要求1所述的方法,其特征在于,所述分别对各所述服务器的业务系统执行相应的检测之后,所述方法还包括:
获取各所述服务器的业务系统的检测结果,并
当所述检测结果表征相应的业务系统中存在错误时,输出告警信息。
8.如权利要求1-7任一项所述的方法,其特征在于,所述分别对各所述服务器的业务系统执行相应的检测之后,所述方法还包括:
获取各所述服务器的业务系统的检测结果;
存储各所述服务器的业务系统的检测结果至区块链网络。
9.如权利要求8所述的方法,其特征在于,所述存储各所述服务器的业务系统的检测结果至区块链网络,包括:
生成包括公钥和私钥的非对称密钥对,并将各所述服务器的业务系统的检测结果以及所述公钥发送至区块链网络,以使
所述区块链网络的节点通过所述公钥对各所述服务器的业务系统的检测结果进行加密处理,并将加密后的各所述服务器的业务系统的检测结果以区块形式存储至区块链中;
所述业务系统的检测方法,还包括:
将所述私钥发送至具有对各所述服务器的业务系统的检测结果的查看权限的权限方,以使
所述权限方根据所述私钥,对所述区块链中的加密后的各所述服务器的业务系统的检测结果进行解密处理。
10.一种业务系统的检测装置,其特征在于,所述装置包括:
接收模块,用于接收到针对目标业务的检测指令,所述检测指令指示对所述目标业务对应的至少两个服务器的业务系统进行检测;
其中,每个服务器的业务系统对应所述目标业务包括的至少一个子业务;
第一确定模块,用于响应于所述检测指令,分别确定各所述服务器的业务系统所对应的子业务;
第二确定模块,用于分别确定各所述子业务对应的检测项,所述检测项包括:系统层检测项、网络层检测项和应用层检测项中至少之一;
执行模块,用于基于各所述子业务对应的检测项,分别对各所述服务器的业务系统执行相应的检测。
CN202010528829.4A 2020-06-11 2020-06-11 业务系统的检测方法及装置 Pending CN111694743A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010528829.4A CN111694743A (zh) 2020-06-11 2020-06-11 业务系统的检测方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010528829.4A CN111694743A (zh) 2020-06-11 2020-06-11 业务系统的检测方法及装置

Publications (1)

Publication Number Publication Date
CN111694743A true CN111694743A (zh) 2020-09-22

Family

ID=72480339

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010528829.4A Pending CN111694743A (zh) 2020-06-11 2020-06-11 业务系统的检测方法及装置

Country Status (1)

Country Link
CN (1) CN111694743A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112445691A (zh) * 2020-12-02 2021-03-05 中国建设银行股份有限公司 非侵入式智能合约性能检测方法和装置
CN112579392A (zh) * 2020-12-21 2021-03-30 深圳云之家网络有限公司 应用检测方法、装置、计算机设备和存储介质
CN113409048A (zh) * 2021-08-19 2021-09-17 杭州云链趣链数字科技有限公司 区块链对接平台的监测方法、区块链对接平台和电子装置
CN113553235A (zh) * 2021-07-19 2021-10-26 猪八戒股份有限公司 业务场景监测方法、装置、电子设备及存储介质
CN115002013A (zh) * 2022-08-08 2022-09-02 浙江华创视讯科技有限公司 运行状态的确定方法、装置、存储介质及电子装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112445691A (zh) * 2020-12-02 2021-03-05 中国建设银行股份有限公司 非侵入式智能合约性能检测方法和装置
CN112445691B (zh) * 2020-12-02 2024-05-28 中国建设银行股份有限公司 非侵入式智能合约性能检测方法和装置
CN112579392A (zh) * 2020-12-21 2021-03-30 深圳云之家网络有限公司 应用检测方法、装置、计算机设备和存储介质
CN112579392B (zh) * 2020-12-21 2023-01-24 深圳云之家网络有限公司 应用检测方法、装置、计算机设备和存储介质
CN113553235A (zh) * 2021-07-19 2021-10-26 猪八戒股份有限公司 业务场景监测方法、装置、电子设备及存储介质
CN113409048A (zh) * 2021-08-19 2021-09-17 杭州云链趣链数字科技有限公司 区块链对接平台的监测方法、区块链对接平台和电子装置
CN115002013A (zh) * 2022-08-08 2022-09-02 浙江华创视讯科技有限公司 运行状态的确定方法、装置、存储介质及电子装置
CN115002013B (zh) * 2022-08-08 2022-12-06 浙江华创视讯科技有限公司 运行状态的确定方法、装置、存储介质及电子装置

Similar Documents

Publication Publication Date Title
US11770381B2 (en) Managing security groups for data instances
US11743137B2 (en) Systems, methods, and apparatuses for implementing a metadata driven rules engine on blockchain using distributed ledger technology (DLT)
CN113711536B (zh) 从区块链网络中提取数据
CN110543464B (zh) 一种应用于智慧园区的大数据平台及操作方法
CN111694743A (zh) 业务系统的检测方法及装置
US20190305959A1 (en) Announcement smart contracts to announce software release
US20190303623A1 (en) Promotion smart contracts for software development processes
US11030084B2 (en) API specification parsing at a mocking server
US10972475B1 (en) Account access security using a distributed ledger and/or a distributed file system
US20190306173A1 (en) Alert smart contracts configured to manage and respond to alerts related to code
CN112506747B (zh) 一种业务进程监控方法、装置、电子设备及存储介质
US8254579B1 (en) Cryptographic key distribution using a trusted computing platform
CN112583802A (zh) 基于区块链的数据共享平台系统、设备以及数据共享方法
JP2016129037A (ja) アプリケーション証明のためのシステムおよび方法
WO2022142781A1 (zh) 区块链的异步落账方法、装置、介质及电子设备
CN111008402A (zh) 区块链时间戳协定
JP2012150805A (ja) システムアプリケーション処理に関連する詐欺を検出するシステムおよび方法
CN116155771A (zh) 网络异常测试方法、装置、设备、存储介质和程序
WO2022257226A1 (zh) 基于网络空间测绘的蜜罐识别方法、装置、设备及介质
Kemp et al. Professional Heroku Programming
Quamara et al. An in-depth security and performance investigation in hyperledger fabric-configured distributed computing systems
CN111506661A (zh) 一种内容访问管理方法、装置和存储介质
Habbal Enhancing availability of microservice architecture: a case study on Kubernetes security configurations
CN110430211A (zh) 一种虚拟化云桌面系统及操作方法
CN112565211B (zh) 区块链网络服务平台及信息处理方法、设备、存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination