最新新闻:

云测试是基于云计算而提出的「大数据与云计算结合」

时间:2022-11-20 18:18:35来源:搜狐

今天带来云测试是基于云计算而提出的「大数据与云计算结合」,关于云测试是基于云计算而提出的「大数据与云计算结合」很多人还不知道,现在让我们一起来看看吧!

随着云计算的迅速发展,能源行业信息化在从传统的IT逐步转向云计算时代。在 传统IT数据中心中,各类IT基础设施的检测与故障预警全部是独立的,不同的厂商只能够 监控各自的产品,无法对整个基础架构层进行快速、统一、有效的检测。在云计算数据中心 中,所有的基础设施资源以服务的方式提供给最终的用户者,SIaaS (Infrastructure as a Service,基础设施即服务),用户可以方便的获取需要的计算、存储、网络资源。但对于运维者来说,如何对云平台下的异构的硬件设备进行统一的检测、快速的定位故障,对实现高效化、精细化运维具有重大意义。

[0003] 目前,市场主流的IT设备有通用的,但也有专用的,主要分为服务器类、存储类、网 络类、安全类、基础设施类,在各自的领域都有专门的设备检测及故障预警系统,但没有一 个兼容不同类型设备的统一平台,造成了如下问题:

[0004] (1)监控信息孤岛,运维效率低下。在云计算的环境,传统的监控和报警分散在不 同的平台中,管理员需要同时在多个平台间切换运维,当有突发故障发生时,需要人工的按照物理拓朴逐个环节逐个界面进行紧急排查,在时效性、准确性上都无法保证,对故障的及 时定位和预警造成很大影响。

[0005] (2)无法同时兼容各类的检测机制,监控不全面。经过30多年IT的发展,针对设备 的监控、检测、故障定位技术不停的发展,出现了很多种不同的监控机制、监控协议等,比如 SNMP (Simple Network Management Protocol,简单网络管理协议)、IPMI (Intelligent Platform Management Interface,智能平台管理接口)、Agent (代理程序)等等,而现有的 各类监控机制,每一类只能支持其中的1〜2种协议,无法全面地对整个数据中心进行统一 监控,存在监控的死角,当故障点出现在监控死角时,将严重影响故障处置。

[0006] (3)监控平台封闭,监控和预警管理简单。无法灵活设置定制化检测指标、报警阀 值、报警方式等。传统的监控报警平台都是由各设备厂商自行研发,因为涉及到商业竞争, 无法兼容其他厂商的产品,也未提供定制化的接口。在云计算时代下,云平台更像是一个生 态系统,承载了生态圈内的各种设备和应用,这些设备的监控指标、阀值、展示方式差异大, 如何通过一个平台收集不同类型的指标,定制不同的展示方式等问题始终未能解决。现有 的监控平台能够支持在线的设备数量有限,很难满足大于1000台设备时的实时性要求,只 能通过增加新的平台来实现,极大增加了运维的成本。

[0007]综上所述,现有技术无法做到对云平台下的异构的硬件设备进行有效地的统一检 测和快速故障定位,导致其运维效率低。

问题拆分


系统包括:实时监控模块、监控信息呈现模块、故障预警模块和告警模块。方法包括以下步骤:步骤1,实时监控:进行实时信息采集,并进行汇总和展现;步骤2,故障预警分析:对采集的信息进行故障预警分析;步骤3,告警机制触发:对预警信息进行分类处理。本发明可以根据云计算数据中心的设备类型、数量、支持协议自主可控的选择检测的指标、适应不同的监控方式、定制报警的触发条件、大规模的扩展监控设备数量等,在统一的系统中集中的收集、监控、报警、故障定位,有效提高了运维的效率。

问题解决


针对现有技术的不足,本友明提出了一种云计算环境下的设备检测及故障预警系 统及方法,其能够对云平台下的异构的硬件设备进行统一的检测和快速的故障定位,有效 提高运维效率。


[0009]本发明解决其技术问题采取的技术方案是:

[0010]本发明实施例提供的一种云计算环境下设备检测及故障预警的系统,它包括: [0011]实时监控模块,用以通过接口方式兼容不同种类的主动和被动采集方式,对被监 控的主机、网络、服务、系统事件进行捕捉,并进一步对采集到的监控项进行汇总;

[0012]监控信息呈现模块,用以将实时监控模块传递过来的数据信息进行呈现,以实现 对云计算环境运行状态的实时全景状态展现;

[0013]故障预警模块,用以基于实时采集模块传递过来的数据进行分析监测,将结果与 管理人员定义的阈值进行比对,当超过阈值时触发报警信息;

[0014]告警模块,用以接收来自故障预警模块的预警事件,通过日志保存相关的故障告 警信息,并及时做出告警呈现。

[0015]作为本实施例一种可能的实现方式,所述实时监控模块包括:

[0016]监控采集模块,用以采集云计算环境中主机、网络、服务和系统事件信息;

[0017]采集汇总模块,用以将采集到的各种数据信息进行汇总。

[0018]作为本实施例一种可能的实现方式,所述采集汇总模块包括直通采集汇总模块和 代理采集汇总模块,所述直通采集汇总模块用以将收集的被监控设备数据直接写入本系统 的Server服务器端,所述代理采集汇总模块用以将收集的被监控设备数据通过proXy代理 传递给Server服务器端。

[0019]作为本实施例一种可能的实现方式,所述故障预警模块包括触发器,所述触发器 用以评估监控对象监控项的数据是否在合理范围,即阈值,监控到其数据大于阈值时,触发 器状态将从“OK”转变为“Problem”,当数据量再次回归到合理范围时,其状态将从 “Prob 1 em” 转换为 “0K”。

[0020]作为本实施例一种可能的实现方式,所述系统还包括Mysql关型数据库模块,用以存储日志。


[0021]本发明实施例提供的一种云计算环境下设备检测及故障预警的方法,它包括以下 步骤:

[0022] 步骤1,实时监控:进行实时信息采集,并进行汇总和展现;

[0023]步骤2,故障预警分析:对采集的信息进行故障预警分析;

[0024]步骤3,告警机制触发:对预警信息进行分类处理。

[0025]作为本实施例一种可能的实现方式,所述步骤1的具体过程包括以下步骤:

[0026]步骤11,监控模块的Server服务器端实时通过不同采集方式通信对云计算环境监 测信息进行采集,所述的不同采集方式包括

[0027] (1) Agent主动方式,由Agent通过获取ACTIVE ITEMS (活动项目)列表”和“提交数 据两者方式主动向Server服务器端汇报数据;获取ACTIVE ITEMS列表的过程为:Agent打开 TCP连接,请求items检测列表,Server服务器端返回items列表,Agent处理响应,关闭TCP连 接,Agent开始收集数据;提交数据的过程为:Agent建立TCP连接,Agent提交items列表收集 的数据,Server服务器端处理数据并返回响应状态,关闭TCP连接;

[0028] (2) Agent被动检测过程,由Server服务器端打开一个TCP连接,Server服务器W发 送请求agent.pingn,Agent接收到请求并且响应<DATALEN><1> (标头、数据长度),Server 服务器端处理接收到的数据,关闭TCP连接;

[0029] (3)简单检查方式过程,由Server服务器端执行预先定义的脚本和命令方式检测 设备的IP、端口,Server服务器端助理接收到的执行结果返回值;

[0030] ⑷SNMP方式,通过SNMP协议收集硬件型号、传感器信息、系统状态、系统报警、登 录信息、各种级别的trap;

[0031] (5) ODBC方式,对于支持ODBC的数据库,获取数据库的实例名、数据库引擎内存使 用情况和连接数信息;

[0032] (6)IPMI方式,通过和服务器建立IPMI连接,以IPMI协议提供其所收集的信息,包 括CPU型号数量、内存大小数量、温度、转速和系统类型版本信息;

[0033] (7) SSH/Telnet Agent方式,这种方式通过在Server服务器端保存被监控设备的 密码或者密钥来实现;

[0034] (8) JMX (Java Management Extensions,Java 管理扩展)Agent 方式,针对类似 Tomcat的中间件可以使用JMX Agent收集Java VM实例的状态信息;

[0035] 步骤12,采集到的信息通过两种方式传递和汇总:(1)如果采用Agent-Server模 式,将直接传递到Server服务器端;(2)如果是Agent-Proxy-Server架构,数据先在缓存在 Proxy中,然后在一定的时间后传递给Server服务器端;

[0036]步骤13,SerVer服务器端收集到数据后将采集的监控项数据实时的展示到用户定 制化的屏幕中。


[0037]作为本实施例一种可能的实现方式,所述步骤2的具体过程包括以下步骤:

[0038]步骤21,定义预警模板,进行快速定义被监控云计算环境下的设备预设条目集合; 所述预警模板包括负载预警模板、故障预警模板和复杂预警模板;

[0039] 所述负载预警模板包括以下信息:CPU、内存、硬盘的使用率上线,磁盘10上线,网 络带宽使用率上线,数据库、应用服务器并发连接数上线,并发等待时间上线;

[0040] 所述故障预警模板包括以下信息:CPU、内存和硬盘的故障信息,网络通信中断,数 据库、应用服务器连接中断;

[0041] 所述复杂预警模板包括以下信息:在负载基础上增加时间维度,故障叠加;

[0042] 步骤22,对获得的环境信息首先根据模板变量需要进行抽取,然后进行故障预警 的模型分析;

[0043]步骤23,利用故障预警模型进行故障分析,数据大于阈值时,触发状态将从“〇K”转 变为“Problem”,当数据量再次回归到合理范围时,其状态将从“Problem”转换为“0K” ;

[0044] 步骤24,达到预警条件的信息形成一个事件;

[0045]作为本实施例一种可能的实现方式,所述步骤3的具体过程包括以下步骤:

[0046]步骤31,对接收到预警信息后进行分类处理,对于负载和故障类预警,仅仅通过 Web界面的高亮提示,以待办事项方式呈现;

[0047]步骤32,对于复杂类预警,将通过短信、微信、邮件或弹窗方式发出报警;如果在预 设时间(如5分钟)内未响应,则报警升级;步骤33,对已经接收到的数据,存放到Mysql数据 库中,以便用户可以在WEB界面中对历史数据进行查询、回溯分析。

[0048]作为本实施例一种可能的实现方式,所述方法还包括以下步骤:

[0049] 步骤4:势态感知反馈机制,所述步骤4的具体过程包括以下步骤 [0050]步骤41,抽取历史数据;

[0051]步骤42,对在线数据进行采样,20分钟采样一次,加权平均,8:00〜20:00数据权重 为70%,20:00到次日S:〇〇数据权重为30%,计算得出每天此监控项的平均值;

[0052]步骤43,将此平均值存放于离线数据库中,以备查用;

[0053]步骤44,每个月1日自动运行阈值调整脚本,此脚本将提取上月的历史数据,并进 行趋势分析,与上上月的数据进行简单的环比,判断此数据的变化趋势及趋势的程度,得出 变化率R;

[0054]步骤45,对当前的报警阈值进行自动调整,调整为“当前阈值=(1 R)*当前阈值”, 进行下一个监控周期。

[0055]本公开的实施例提供的技术方案可以包括以下的有益效果:

[0056]本发明实施例技术方案提供了一种机制和框架,在这个机制下运维管理员可以根 据云计算数据中心的设备类型、数量、支持协议自主可控的选择检测的指标、适应不同的监 控方式、定制报警的触发条件、大规模的扩展监控设备数量等,在统一的系统中集中的收 集、监控、报警、故障定位,有效提高了运维的效率。

[0057]与现有技术相比较,本公开的实施例提供的技术方案具有以下特点:

[0058] ⑴统一监控平台,优化运维能力

[0059]在云计算环境下,将底层的硬件资源状态,网络状态,底层之上的虚拟机、裸机、操 作系统数据库等基础软件、容器集群、大数据等服务状态的监控汇集中到一个平台,减少了 监控平台的数量,提高了故障预警效率;同时提供丰富的定制化接口,可根据不同数据类 型,生成优化展示图表,以最直观的方式展示状态,大大提高运维能力。

[0060] ⑵兼容主流监测机制,提高监控完整性

[0061]按照异构兼容架构思路设计,能够支持基于Ping、端口、标准协议、代理、脚本等十 几种不同状态监测机制,从而能够更好地适配不同设备和软件,进一步保证了监控的完整 性与监控数据的统一性。

[0062] (3)监控指标定制灵活,故障预警精确度高

[0063]提供开放的监控指标和故障预警阈值设置机制,用户可以灵活的自定义模板,根 据实际环境不同,筛选不同的重点监控项,以突出关注的业务方向;同时,支持多条件预警 触发模型,可方便的通过本发明进行复杂阈值触发条件的管理,从而实现复杂故障预警预 警,平衡高敏度预警带来的报警风暴与低敏度预警带来的延误风险,有效提高报警准确率, 进一步提升运维工作效率。

[0064] ⑷适应云计算的横向扩展能力

[0065]云计算系统本身是一个可无限横向扩展的平台,针对这种环境进行了架构优化, 可支持大于2000台以上物理设备的大型云计算环境,实施全面监控,大幅度的提升了本公 开的实施例提供的技术方案在云计算环境下的可用性。

声明:文章仅代表原作者观点,不代表本站立场;如有侵权、违规,可直接反馈本站,我们将会作修改或删除处理。

图文推荐

热点排行

精彩文章

热门推荐