一种电力应用系统故障实时分析诊断系统及方法
一种电力应用系统故障实时分析诊断系统及方法
【技术领域】
[0001]本发明涉及一种故障分析诊断系统及方法，具体地说是一种电力应用系统故障实时分析诊断系统及方法，属于电力系统自动化技术领域。
【背景技术】
[0002]随着电力行业“十二五规划”任务的逐步完成，电力企业已建成覆盖各级单位、各业务领域的诸多业务应用系统，由此，保障各业务应用系统的安全运行就成了重要课题。特别是，当业务应用系统发生故障时，能够做到早发现、早诊断、快速定位，迅速采取故障应急处置措施，具有非常重要的意义。
[0003]目前，多数业务应用系统的运行监测以指标报送、服务器监控为主，以发现和告警导致系统停运的重大故障、服务器硬件故障为重点，而系统局部功能故障和导致重大故障前的故障线索则难以监控。从日常运行维护角度讲，也缺少以业务系统为单位，全面监测业务应用系统安全运行的措施和方法，传统的业务应用系统运行监测方法存在以下问题:
[0004](1)故障发现迟，留给处置故障的时间短。因为缺少全方位监测和分析的措施方法，局部功能故障和小故障多数在用户使用过程中被发现并报告，而当监测系统告警时，业务系统往往已经停运，或者部分节点停运，造成的影响很大，留给应急处置的时间极为有限，运检人员压力巨大。
[0005](2)依赖人工排查故障线索。常规的监控系统都能提供告警，但缺少故障线索发现和推导跟踪功能。故障告警后，仍然需要熟悉各个专业的专工赶到现场，通过人工搜集和查看各种日志、各种中间件状态、业务系统环境参数，从中发现故障线索，并进行汇总、整理和分析，整个过程耗时、耗力，还容易出现疏漏。
[0006](3)不能按业务系统进行故障诊断分析，定位故障原因。常规监控系统提供的故障分析和定位能力有限，很难做到按照业务系统进行故障诊断分析，最终仍然依靠人工分析和定位故障。复杂的故障，往往需要多个专业经验丰富的专家集体会诊，进行原因确认和定位。
[0007](4)难以重现故障场景，故障处置时间长。因为缺少以业务系统单位组织的全面监测和分析系统，故障发生后，大部分故障线索需要各专业经验丰富专家从大量日志、参数中查找蛛丝马迹，但一些对故障诊断分析有重要作用的业务系统环境的参数和日志，因为没有及时保存故障现场，已经不能获得，严重影响故障诊断和定位，造成故障处置时间不断推迟。
【发明内容】
[0008]为克服上述现有技术存在的不足，本发明提供了一种电力应用系统故障实时分析诊断系统及方法，其能够对电力应用系统进行故障定位与诊断，有效对电力应用系统的故障应急处置进行指导。
[0009]本发明解决其技术问题所采取的技术方案是:一种电力应用系统故障实时分析诊断系统，其特征是，包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示丰旲块;
[0010]所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
[0011 ]所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
[0012]所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
[0013]所述存储模块用以储存分析结果；
[0014]所述显示模块用以展示故障告警信息。
[0015]优选地，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Appl icat1n Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
[0016]优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器;所述消息通道模块采用集群部署方式、具备缓存功能的流式消息传输模块。
[0017]优选地，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。
[0018]本发明还提供了一种电力应用系统故障实时分析诊断方法，其特征是，包括以下步骤:
[0019]S1:实时从各个业务系统采集数据;所述步骤S1具体包括以下步骤:S101:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道；
[0020]S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台；所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存；
[0021]S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用；
[0022]S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常;S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
[0023]优选地，所述获取各个业务系统的状态数据包括但不限于:
[0024]用户进程:进程名称及数量参数；
[0025]服务器内存参数:total、used、free、shared、buffers、cached、-/+buffers/cache参数；
[0026]服务器swap参数:Swaptotal、swap usecUswap freenswap file数量和size参数；
[0027]服务器CPU参数:％us、％sy、％n1、％ id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st参数；
[0028]服务器磁盘参数:Mountedon、Use%、Used Avail、Size参数；
[0029]磁盘10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util参数；
[0030]网络传输参数:工作模式、连通状态、是否丢包、响应时间参数。
[0031]优选地，对汇聚后消息数据进行分类处理过程中采用的分类格式为:地址+位置+类别;地址即数据来源地址，为数据源的IP地址;位置即数据来源位置，为文件路径，如果为服务器参数则可空;类别即数据类别，包括但不限于以下类型:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、ffeblogic Domain 日志、Weblogic控制台输出、Oracle监听日志、Oracle alert 日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、Cpu、和网络参数。
[0032]优选地，所述故障识别特征包括但不限于以下内容:
[0033]1 )apache访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息;
[0034]2)apache错误日志:级别为EMERG、ERR0R、ALERT、CRIT的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息；
[0035]3)Tomcat访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息;
[0036]4)Tomcat运行日志:级别为SEVERE的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含 ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息；
[0037]5)webl0giC访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息；
[0038]6)weblogic服务器日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息；
[0039 ] 7)weblogic domain 日志:级别为 ENERGENCY、ALERT、CRITI CAL、ERROR 的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以 及级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息；
[0040]8)应用程序日志:级别为FAILURE、ERR0R的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERR0R、EXCEPT10N、FAILURE、WARNING关键字的消息；
[0041 ] 9)0racle alert日志:在系统非计划检修期间，日志记录中包含:状态为启动失败、服务关闭的消息，日志记录中包含ERR0R、EXCEPT10N、FAILURE和WARNING关键字的消息，日志记录中包含"0RA-数字〃关键字的消息；
[0042]10)0racle listener日志:RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在系统非计划检修期间，监听启动失败、监听关闭的消息;
[0043]ll)syslog日志:日志记录中包含ERR0R、FAILURE和WARNING关键字的消息；
[0044]12)用户进程:根据用户进程名称和数量范围设定值，判断用户进程是否正常；
[0045]13)内存参数:根据设定阀值，判断total、used、free、shared、buff ers、cached、-/+buff ers/cache参数是否超过警戒值；
[0046]14)swap参数:根据设定阀值，判断Swap total、swap used和swap free参数是否超过警戒线值；
[0047]15)01?参数:根据设定阀值，判断％118、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、参数是否超过警戒值；
[0048]16)磁盘参数:根据设定阀值，判断Mounted on、Use%、Used Avail和Size参数是否超过警戒值；
[0049]17)磁盘 1 参数:根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-s z、awa i t、svctm 和 ％ ut i 1 参数是否超过警戒值；
[0050]18)网络参数:根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。
[0051 ] 优选地，所述节点类型topology进行故障推导的过程包括以下步骤:
[0052]S3031 )假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2);如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务系统进行汇聚信息；
[0053]S3032)对判定为服务不可用故障的信息通过推导规则表进行如下推导:
[0054]判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步；
[0055]判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步；
[0056]判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导；
[0057]判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断；
[0058]S3033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
[0059]优选地，所述业务类型topology进行故障推导的过程包括以下步骤:
[0060]S3041)获得步骤 S3033)的推导结果，按照 WebServer->AppServer_>Database 的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤S3042)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区；
[0061 ] S3042)判断AppServer层节点故障，如果Webserver层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因；
[0062]S3043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因；
[0063]S3044)当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
[0064]本发明的有益效果如下:本发明以业务系统为单位，实时采集业务系统的应用、中间件、数据库、操作系统、硬盘、CPU、内存、网络等的日志、实时状态参数，经过汇聚传输和分类、特征筛选、线索汇集、原因分析，实时发现故障，确定故障业务系统、所在服务器、故障位置，并推导处故障特征的关联关系，用以指导故障应急处置。
[0065]本发明通过对电力应用系统进行故障定位与诊断，有效对电力应用系统的故障应急处置进行指导，与现有技术相比有以下优点:
[0066](1)状态早发现。以业务系统为单位，可以将业务系统所有类型的状态、日志文件作为监测数据源，避免以往监控系统监测范围固定且狭小，很多早期故障状态特征难以发现的问题。采集数据以消息流的方式传输，并汇聚、分类，由实时计算分析平台的筛选任务进行迅速特征筛选。消息的传递和处理都以流的方式进行，快速高效，消息传输和实时计算任务都采用集群负载均衡，并且可以根据计算量，横向扩展增加计算节点，保证消息在迅速得到处理，异常状态第一时间被发现。
[0067](2)问题早分析。异常状态发现后，会迅速交由节点型任务和业务型任务进行分析处理。同样的，节点型任务和业务型任务也基于实时计算分析平台的分布式计算能力和水平横向扩展能力，对问题进行快速诊断分析，并推导节点内、业务系统内问题线索和关联关系，形成非常有价值的故障场景和进程堆栈。
[0068](3)故障早定位。本发明采用特有的故障定位方法，从故障发现到线索追踪，再到推导定位，都建立在大数据量流处理分析基础上，最终以业务系统为单位，对结果进行汇总、展现。
[0069](4)处置有指导。将与故障相关的各种日志特征信息和参数状态信息，集中展现，按故障发展进程排列，为专责处置故障提供有力支持和指导，如果增加应急处置专家模块，可以在线给出处置方案，如果提供自学习模块，可以实现无监督学习和业务应用系统故障预警。
【附图说明】
[0070]下面结合附图对本发明进一步说明:
[0071 ]图1是本发明的系统结构图；
[0072]图2是本发明的总体方法流程图；
[0073]图3是本发明的具体实施方法流程图。
【具体实施方式】
[0074]为能清楚说明本方案的技术特点，下面通过【具体实施方式】，并结合其附图，对本发明进行详细阐述。下文的公开提供了许多不同的实施例或例子用来实现本发明的不同结构。为了简化本发明的公开，下文中对特定例子的部件和设置进行描述。此外，本发明可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。应当注意，在附图中所图示的部件不一定按比例绘制。本发明省略了对公知组件和处理技术及工艺的描述以避免不必要地限制本发明。
[0075]如图1所示，本发明提供了一种在线实时发现、诊断、定位业务应用系统故障的系统。图中以业务系统为单位进行监测、分析和告警，对被监测业务系统采用主动、非侵入式数据采集，实施监测简单，不影响业务系统正常运行，数据采集范围涵盖业务系统及其所在服务器环境的绝大部分日志、运行状态参数，故障的发现和诊断采用专门设计的规则库和规则处理引擎。为达到更强处理能力和响应速度，本发明采用流式数据传输和处理，并在实时计算分析平台部分采用云计算技术，实现可随时扩展的计算能力扩充。
[0076]本发明的一种电力应用系统故障实时分析诊断系统，它包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；
[0077]所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端通过数据总线与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
[0078]所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
[0079]所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
[0080]所述存储模块用以储存分析结果；
[0081]所述显示模块用以展示故障告警信息。
[0082]优选地，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Appl icat1n Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
[0083]优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器，用以实现对业务系统应用状态的实时数据采集。
[0084]优选地，所述消息通道模块首先对数据采集器模块推送的数据进行汇聚，并以流式(stream)消息的方式进行处理和传输，并对消息按地址、类型进行分类处理，为防止数据未处理期间丢失，将数据缓存在本地，消息被处理后会删除本地缓存。所有被监测业务系统的采集数据通过消息通道传递给实时计算分析模块，为了防止消息传输通道因节点故障不可用，本发明对消息通道模块采用集群部署方式。
[0085]优选地，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计 算分析模块。实时计算分析模块是本发明系统分析计算功能的主体部分，每个topology都分为数据源和处理逻辑两个部分，topology数据源可以是消息通道、数据库、另一个topology处理结果。实时计算分析模块主动从消息通道获取消息，并通过预定义的规则库，对消息进行筛选，通过特征识别发现故障，并因此收集追溯故障的进程踪迹，通过推导分析，判定导致故障发生的根本原因和位置，形成故障信息堆栈，以告警形式反馈给用户。实时分析模块计算量大、实时性要求高，根据任务和地址的不同，采用分布式在不同节点并行执行。根据分析计算量，在负载大时还可以对storm进行横向扩展，能够利用云计算虚拟化技术增加节点，提高计算处理能力。
[0086]如图2所示，本发明的一种电力应用系统故障实时分析诊断方法，它包括以下步骤:
[0087]S1:实时从各个业务系统采集数据;所述步骤SI具体包括以下步骤:SlOl:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道；
[0088]S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台；所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存；
[0089]S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用；
[0090]S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常;S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
[0091 ]如图3所示，本发明的具体实施过程如下:
[0092]—、采集器实时从各个业务系统所在服务器采集数据。
[0093](I )以增量形式获取 Webserver Log、AppServer Log、DB Log、0S Log、Applicat1n Log等文件数据，采集器记录每次读取数据位置，作为下一次读取的起点。当文件名变化时，根据命名规则，自动更换文件继续进行读取数据。采集器可以设定两次读取数据的时间间隔，根据日志增长量和网络负载情况进行设定。采集器可以设置分配内存大小，避免采集期间消耗大量内存，对业务系统造成影响。
[0094](2)对业务应用系统所运行环境参数的获取，采集器自动根据操作系统版本等信息，从服务器解析并获得如下参数值:
[0095]用户进程:进程名称、数量等参数。
[0096]服务器内存参数:total、used、free、shared、bufferS、cached、-/+buffers/cache等参数。
[0097]服务器swap参数:Swaptotal、swap usednswap freenswap file数量和size等参数。
[0098]服务器CPU参数:％us、％sy、％n1、％ id、load average、users、total 'running、sleeping、s topped、st 等参数。
[0099]服务器磁盘参数:Mountedon、Use%、Used Avail、Size等参数。
[0100]磁盘10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util等参数。
[0101 ]网络传输参数:工作模式、连通状态、是否丢包、响应时间等参数。
[0102](3)采集器将采集到的业务系统状态数据推送给消息通道，采集器不缓存数据，数据以消息形式推送向消息通道的不同主题分类。
[0103]二、消息通道将来自不同业务系统、不同服务器、不同类别的采集数据进行汇聚，按位置、类别、服务器、业务系统进行分类，以消息流的形式传输，为保证消息安全进行必要缓存，最终提供给实时计算分析平台处理。
[0104]本发明所涉及的“流”是建立在Java语言中的流概念之上，实现从众多不同类型的采集源数据向输出通道、实时计算分析平台高效流动，在业务层面对不同源和目地的数据流进行分类和封装，如1.XXX.XX.XX地址的内存数据。
[0105](I)接收采集器推送的数据，以流式消息方式接收，对不同来源、不同业务系统、不同类型的消息数据进行汇聚。
[0106](2)对消息数据进行分类，分类的依据是数据来源地址、数据来源位置和数据类别。分类格式:地址+位置+类别。地址为数据源IP地址，位置为文件路径，如果为服务器参数则可空，类别包括但不限于:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、cpu、网络等参数类型，且以上类型维护在系统采集数据类型表中，可以根据实际被监测业务系统需要随时增加，即时生效。
[0107]通过消息通道的消息汇聚和分类，为后续步骤消息处理分析做好准备。
[0108](3)为防止数据传输过程中丢失，传输通道可以对数据进行缓存。通过设置在本地磁盘缓存，可以有效解决消息在传输过程中某个环节丢失，缓存在本地磁盘的数据，在实时计算分析模块获取后，即删除掉，防止占用大量磁盘或者存储空间。为了防止数据在传输通道过度累积，实时计算模块可以通过增加并行任务处理节点，加快消息处理速度，及时清除缓存在消息通道的数据。
[0109]三、实时计算分析模块被设计为不断从消息通道顺次获取消息、不停进行实时计算分析的循环处理机制，详细步骤如下:
[0110](I)按地址、位置、类别主动获取消息。实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理，提高处理效率，便于封装业务规则，实现动态平台扩展。
[0111](2)过滤类型topology从数据库的特征识别表获得故障特征，对消息进行过滤和故障识别:如果识别为非故障消息，按照地址、位置、类别更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景。其中:
[0?12]I)过滤类型topo1gy通过以下规则特征识别故障:
[0113]_apache 访问日志
[0114]丨状态代码为4XX、5XX的消息。
[0115]入响应时间超过限定阀值的消息。
[0116]_apache 错误日志
[0117]入级别为:EMERG、ERROR、ALERT、CRIT 的消息。
[0118]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0119]入级别为INFO、NOTI CE、DEBUG，原因描述中包含ERROR、EXCEPT I ON、FAILURE、WARNING等关键字的消息。
[0120]_Tomcat 访问日志
[0121 ]入状态代码为4XX、5XX的消息。
[0122]入响应时间超过限定阀值的消息。
[0123]■ Tomcat 运行日志
[0124]入级别为:SEVERE的消息。
[0125]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0126]丨级别为WARNING、INF0、⑶NFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPT1N、FAILURE、WARNING 等关键字的消息。
[0127]_weblogic访问日志
[0128]入状态代码为4XX、5XX的消息。
[0129]入响应时间超过限定阀值的消息。
[0130]■ web I ogi c服务器日志
[0131 ]丨级别为:ENERGENCY、ALERT、CRITICAL、ERROR 的消息。
[0132]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0133]丨级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0134]Hweblogic domain 日志
[0135]入级别为:ENERGENCY、ALERT、CRITICAL、ERROR的消息。
[0136]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0137]丨级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0138]说明:domain日志需要对已经包含在服务器日志中的故障信息去重。
[0139]■应用程序日志
[0140]入级别为:FAILURE、ERROR的消息。
[0141]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0142]丨日志记录 中包含:ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0143]HOracle alert 日志
[0144]入在系统非计划检修期间，日志记录中包含:状态为启动失败、服务关闭的消息。
[0145]丨日志记录中包含:ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0146]f日志记录中包含:"0RA-数字〃关键字的消息。
[0147]HOracle listener日志
[0148]入RETURN CODE不为O的记录。
[0149]丨RETURNMESSAGE信息包含WARNING、TNS_nn关键字的消息。
[0150]入在系统非计划检修期间，监听启动失败、监听关闭的消息。
[0151]_syslog 日志
[0152]日志记录中包含:ERROR、FAILURE、WARNING等关键字的消息。
[0153]■用户进程
[0154]根据用户进程名称和数量范围设定值，判断用户进程是否正常。
[0155]■内存参数
[0156]根据设定阀值，判断total、used、free、shared、buffers、cached、-/+buffers/cache等参数是否超过警戒值。
[0157]■ swip 参数
[0158]根据设定阀值，判断Swap total、swap used、swap free等参数是否超过警戒线值。
[0159]■ CPU 参数
[Ο??Ο]根据设定阀值，判断％ us、％ sy、%ni N % id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st等参数是否超过警戒值。
[0161]■磁盘参数
[0162]根据设定阀值，判断Mounted on、Use%、Used Avai1、Size等参数是否超过警戒值。
[0163]■磁盘1参数
[0164]根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util等参数是否超过警戒值。
[0165]■网络参数
[0166]根据网卡设定，判断网卡工作模式、连通状态等参数是否正确，根据包传输、响应时间等参数判断网络连通是否稳定，响应时间是否超过警戒值。
[0167]识别故障的规则特征不限于以上内容，此处仅是为了展示系统实现的完整性和描述方便，选取以上具有代表性的典型规则特征。通过特征识别表，过滤类型topology可根据业务需要动态扩展或者缩小故障识别范围。
[0168]2)故障场景的保存由过滤型topology执行，在识别为故障消息后，从故障消息前两行或者前一个状态开始，直至故障消息结束或者状态恢复，将故障消息拼接为连续的故障场景，与地址、位置、类别相关联，保存在故障场景文件中。
[0169](3)按地址汇聚信息、规则推导。
[0170]实现按地址汇聚信息的是节点型topology，数据源为过滤型topology和高速共享缓存区。节点型topology可以将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，根据节点故障语义识别规则和推导规则表的定义进行故障推导，节点型topo I ogy规则推导总体遵循:环境故障先于应用故障规则。下面选择具有典型代表性的推导步骤描述如下:[Ο171 ] I)假设通过过滤型topology获得某节点SERVER级别异常，节点型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障;如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤(4)按业务系统汇聚信息。
[0172]2)通过判定为服务不可用故障，通过推导规则表，分别进行如下推导:
[0173]a)判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步。
[0174]b)判断用户进程名称和数量是否正常，如果为O或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步。
[0175]c)判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤(4)判断，继续后续推导。
[0176]d)判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤(4)判断。
[0177]3)节点型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
[0178](4)按业务系统汇聚信息、规则推导
[0179]实现按业务系统汇聚信息的是业务型topology，数据源为节点型topology和高速共享缓存区。业务型topology以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，根据业务关系规则表中定义的进行故障推导，业务型topology规则推导总体遵循:以信息流动方向为规则的逻辑次序。下面继续根据上一步骤的例子描述本步骤的推导过程:
[0180]I)获得步骤(3)推导结果，按照WebServer->AppServer_>Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤(3)2)c)和d)进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区。
[0181 ] 2)其次，判断AppServer层节点故障，如果WebServer层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因。
[0182]3)再次，判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因。
[0183]4)最后，当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
[0184](5)梳理故障演进过程，创建故障进程堆栈
[0185]以业务系统为单位，组织步骤(4)的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的堆栈，并与保存在文件中的故障场景进行关联，供告警和展示用。
[0186]四、结果存储和告警展现。
[0187](I)所有计算分析结果，都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常。实时计算平台的计算结果不但包括故障信息，也包括业务系统健康运行状态的统计信息。
[0188](2)在监控界面，以业务系统为单位，展示每个系统的状态信息，如果某个系统被发现故障，则以故障发展进程倒序展示给用户，用户可以业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录，指导用户追踪、处置故障。
[0189]以上所述只是本发明的优选实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也被视为本发明的保护范围。
【主权项】
1.一种电力应用系统故障实时分析诊断系统，其特征是，包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块； 所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端与消息通道模块相连，用以将采集到的数据推送到消息通道模块； 所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块； 所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息； 所述存储模块用以储存分析结果； 所述显示模块用以展示故障告警信息。2.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Applicat1nLog文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。3.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述数据采集器为具有增量采集和频度设定功能的数据采集器;所述消息通道模块采用集群部署方式、具备缓存功能的流式消息传输模块。4.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。5.—种电力应用系统故障实时分析诊断方法，其特征是，包括以下步骤: S1:实时从各个业务系统采集数据;所述步骤S1具体包括以下步骤:S101:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道； S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台;所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存； S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识 别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用； S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常；S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。6.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述获取各个业务系统的状态数据包括但不限于: 用户进程:进程名称及数量参数； 服务器内存参数:total、used、free、shared、buff ers、cached、-/+buff ers/cache 参数； 服务器swap参数:Swap totalnswap usednswap freenswap file数量和size参数； 服务器CPU参数:％us、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st参数； 服务器磁盘参数:Mounted on、Use%、Used Avail、Size参数； 磁盘 10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、awai t、svctm、％util参数； 网络传输参数:工作模式、连通状态、是否丢包、响应时间参数。7.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，对汇聚后消息数据进行分类处理过程中采用的分类格式为:地址+位置+类别;地址即数据来源地址，为数据源的IP地址;位置即数据来源位置，为文件路径，如果为服务器参数则可空;类别即数据类别，包括但不限于以下类型:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic月艮务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、cpu、和网络参数。8.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述故障识别特征包括但不限于以下内容: 1 )apache访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息； 2)apache错误日志:级别为EMERG、ERROR、ALERT、CRIT的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息； 3)Tomcat访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息； 4)Tomcat运行日志:级别为SEVERE的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息； 5)webl0giC访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息; 6)weblogic服务器日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARN ING、NOT ICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息； 7)weblogicdomaiη日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARN I NG、NOT I CE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息； 8)应用程序日志:级别为FAILURE、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERROR、EXCEPT1N、FAILURE、WARNING关键字的消息； 9)0raclealert日志:在系统非计划检修期间，日志记录中包含:状态为启动失败、月艮务关闭的消息，日志记录中包含ERROR、EXCEPT1N、FAILURE和WARNING关键字的消息，日志记录中包含"0RA-数字〃关键字的消息； 10)0racle1 istener 日志:RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在系统非计划检修期间，监听启动失败、监听关闭的消息; 1 Dsyslog日志:日志记录中包含ERROR、FAILURE和WARNING关键字的消息； 12)用户进程:根据用户进程名称和数量范围设定值，判断用户进程是否正常； 13)内存参数:根据设定阀值，判断total、used、free、shared、buffers、cached、_/+buff ers/cache参数是否超过警戒值； 14)swap参数:根据设定阀值，判断Swaptotal、swap used和swap free参数是否超过警戒线值； 15)CPU参数:根据设定阀值，判断^仍、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、参数是否超过警戒值； 16)磁盘参数:根据设定阀值，判断Mountedon、Use %、Used Avail和Size参数是否超过警戒值； 17)磁盘1参数:根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctn^P%util参数是否超过警戒值； 18)网络参数:根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。9.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述节点类型topology进行故障推导的过程包括以下步骤: 53031)假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2);如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务系统进行汇聚信息； 53032)对判定为服务不可用故障的信息通过推导规则表进行如下推导: 判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步； 判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步； 判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导； 判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断； 53033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。10.根据权利要求9所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述业务类型topology进行故障推导的过程包括以下步骤: 53041)获得步骤S3033)的推导结果，按照WebServer->AppServer_>Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤S3042)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否贝lj，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区； 53042)判断AppServer层节点故障，如果Webserver层已经存在网络故障，贝ijAppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因； 53043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因； 53044)当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
【专利摘要】一种电力应用系统故障实时分析诊断系统及方法,系统包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；所述数据采集模块用以实时采集业务系统的文件数据和状态数据并推送到消息通道模块；所述消息通道模块用以对采集的数据进行汇聚后并进行分类处理；所述实时计算分析模块对数据进行筛选确定的故障信息，并对故障信息进行通过推导分析判定故障发生原因和故障发生位置；所述存储模块用以储存分析结果；所述显示模块用以展示故障告警信息。本发明以业务系统为单位，对实时采集业务系统的数据进行分析处理，确定故障业务系统、所在服务器、故障位置，并推导出故障特征的关联关系，用以指导故障应急处置。
【IPC分类】G06Q10/06, G06Q50/06
【公开号】CN105488610
【申请号】CN201510821162
【发明人】严莉, 王丞远, 刘范范, 曲延盛, 张宏基, 汤耀庭, 王岳, 赵晓, 林鹏
【申请人】国网山东省电力公司信息通信公司, 国家电网公司
【公开日】2016年4月13日
【申请日】2015年11月23日
【技术领域】
[0001]本发明涉及一种故障分析诊断系统及方法，具体地说是一种电力应用系统故障实时分析诊断系统及方法，属于电力系统自动化技术领域。
【背景技术】
[0002]随着电力行业“十二五规划”任务的逐步完成，电力企业已建成覆盖各级单位、各业务领域的诸多业务应用系统，由此，保障各业务应用系统的安全运行就成了重要课题。特别是，当业务应用系统发生故障时，能够做到早发现、早诊断、快速定位，迅速采取故障应急处置措施，具有非常重要的意义。
[0003]目前，多数业务应用系统的运行监测以指标报送、服务器监控为主，以发现和告警导致系统停运的重大故障、服务器硬件故障为重点，而系统局部功能故障和导致重大故障前的故障线索则难以监控。从日常运行维护角度讲，也缺少以业务系统为单位，全面监测业务应用系统安全运行的措施和方法，传统的业务应用系统运行监测方法存在以下问题:
[0004](1)故障发现迟，留给处置故障的时间短。因为缺少全方位监测和分析的措施方法，局部功能故障和小故障多数在用户使用过程中被发现并报告，而当监测系统告警时，业务系统往往已经停运，或者部分节点停运，造成的影响很大，留给应急处置的时间极为有限，运检人员压力巨大。
[0005](2)依赖人工排查故障线索。常规的监控系统都能提供告警，但缺少故障线索发现和推导跟踪功能。故障告警后，仍然需要熟悉各个专业的专工赶到现场，通过人工搜集和查看各种日志、各种中间件状态、业务系统环境参数，从中发现故障线索，并进行汇总、整理和分析，整个过程耗时、耗力，还容易出现疏漏。
[0006](3)不能按业务系统进行故障诊断分析，定位故障原因。常规监控系统提供的故障分析和定位能力有限，很难做到按照业务系统进行故障诊断分析，最终仍然依靠人工分析和定位故障。复杂的故障，往往需要多个专业经验丰富的专家集体会诊，进行原因确认和定位。
[0007](4)难以重现故障场景，故障处置时间长。因为缺少以业务系统单位组织的全面监测和分析系统，故障发生后，大部分故障线索需要各专业经验丰富专家从大量日志、参数中查找蛛丝马迹，但一些对故障诊断分析有重要作用的业务系统环境的参数和日志，因为没有及时保存故障现场，已经不能获得，严重影响故障诊断和定位，造成故障处置时间不断推迟。
【发明内容】
[0008]为克服上述现有技术存在的不足，本发明提供了一种电力应用系统故障实时分析诊断系统及方法，其能够对电力应用系统进行故障定位与诊断，有效对电力应用系统的故障应急处置进行指导。
[0009]本发明解决其技术问题所采取的技术方案是:一种电力应用系统故障实时分析诊断系统，其特征是，包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示丰旲块;
[0010]所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
[0011 ]所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
[0012]所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
[0013]所述存储模块用以储存分析结果；
[0014]所述显示模块用以展示故障告警信息。
[0015]优选地，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Appl icat1n Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
[0016]优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器;所述消息通道模块采用集群部署方式、具备缓存功能的流式消息传输模块。
[0017]优选地，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。
[0018]本发明还提供了一种电力应用系统故障实时分析诊断方法，其特征是，包括以下步骤:
[0019]S1:实时从各个业务系统采集数据;所述步骤S1具体包括以下步骤:S101:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道；
[0020]S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台；所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存；
[0021]S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用；
[0022]S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常;S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
[0023]优选地，所述获取各个业务系统的状态数据包括但不限于:
[0024]用户进程:进程名称及数量参数；
[0025]服务器内存参数:total、used、free、shared、buffers、cached、-/+buffers/cache参数；
[0026]服务器swap参数:Swaptotal、swap usecUswap freenswap file数量和size参数；
[0027]服务器CPU参数:％us、％sy、％n1、％ id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st参数；
[0028]服务器磁盘参数:Mountedon、Use%、Used Avail、Size参数；
[0029]磁盘10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util参数；
[0030]网络传输参数:工作模式、连通状态、是否丢包、响应时间参数。
[0031]优选地，对汇聚后消息数据进行分类处理过程中采用的分类格式为:地址+位置+类别;地址即数据来源地址，为数据源的IP地址;位置即数据来源位置，为文件路径，如果为服务器参数则可空;类别即数据类别，包括但不限于以下类型:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、ffeblogic Domain 日志、Weblogic控制台输出、Oracle监听日志、Oracle alert 日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、Cpu、和网络参数。
[0032]优选地，所述故障识别特征包括但不限于以下内容:
[0033]1 )apache访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息;
[0034]2)apache错误日志:级别为EMERG、ERR0R、ALERT、CRIT的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息；
[0035]3)Tomcat访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息;
[0036]4)Tomcat运行日志:级别为SEVERE的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含 ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息；
[0037]5)webl0giC访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息；
[0038]6)weblogic服务器日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息；
[0039 ] 7)weblogic domain 日志:级别为 ENERGENCY、ALERT、CRITI CAL、ERROR 的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以 及级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息；
[0040]8)应用程序日志:级别为FAILURE、ERR0R的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERR0R、EXCEPT10N、FAILURE、WARNING关键字的消息；
[0041 ] 9)0racle alert日志:在系统非计划检修期间，日志记录中包含:状态为启动失败、服务关闭的消息，日志记录中包含ERR0R、EXCEPT10N、FAILURE和WARNING关键字的消息，日志记录中包含"0RA-数字〃关键字的消息；
[0042]10)0racle listener日志:RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在系统非计划检修期间，监听启动失败、监听关闭的消息;
[0043]ll)syslog日志:日志记录中包含ERR0R、FAILURE和WARNING关键字的消息；
[0044]12)用户进程:根据用户进程名称和数量范围设定值，判断用户进程是否正常；
[0045]13)内存参数:根据设定阀值，判断total、used、free、shared、buff ers、cached、-/+buff ers/cache参数是否超过警戒值；
[0046]14)swap参数:根据设定阀值，判断Swap total、swap used和swap free参数是否超过警戒线值；
[0047]15)01?参数:根据设定阀值，判断％118、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、参数是否超过警戒值；
[0048]16)磁盘参数:根据设定阀值，判断Mounted on、Use%、Used Avail和Size参数是否超过警戒值；
[0049]17)磁盘 1 参数:根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-s z、awa i t、svctm 和 ％ ut i 1 参数是否超过警戒值；
[0050]18)网络参数:根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。
[0051 ] 优选地，所述节点类型topology进行故障推导的过程包括以下步骤:
[0052]S3031 )假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2);如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务系统进行汇聚信息；
[0053]S3032)对判定为服务不可用故障的信息通过推导规则表进行如下推导:
[0054]判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步；
[0055]判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步；
[0056]判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导；
[0057]判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断；
[0058]S3033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
[0059]优选地，所述业务类型topology进行故障推导的过程包括以下步骤:
[0060]S3041)获得步骤 S3033)的推导结果，按照 WebServer->AppServer_>Database 的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤S3042)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区；
[0061 ] S3042)判断AppServer层节点故障，如果Webserver层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因；
[0062]S3043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因；
[0063]S3044)当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
[0064]本发明的有益效果如下:本发明以业务系统为单位，实时采集业务系统的应用、中间件、数据库、操作系统、硬盘、CPU、内存、网络等的日志、实时状态参数，经过汇聚传输和分类、特征筛选、线索汇集、原因分析，实时发现故障，确定故障业务系统、所在服务器、故障位置，并推导处故障特征的关联关系，用以指导故障应急处置。
[0065]本发明通过对电力应用系统进行故障定位与诊断，有效对电力应用系统的故障应急处置进行指导，与现有技术相比有以下优点:
[0066](1)状态早发现。以业务系统为单位，可以将业务系统所有类型的状态、日志文件作为监测数据源，避免以往监控系统监测范围固定且狭小，很多早期故障状态特征难以发现的问题。采集数据以消息流的方式传输，并汇聚、分类，由实时计算分析平台的筛选任务进行迅速特征筛选。消息的传递和处理都以流的方式进行，快速高效，消息传输和实时计算任务都采用集群负载均衡，并且可以根据计算量，横向扩展增加计算节点，保证消息在迅速得到处理，异常状态第一时间被发现。
[0067](2)问题早分析。异常状态发现后，会迅速交由节点型任务和业务型任务进行分析处理。同样的，节点型任务和业务型任务也基于实时计算分析平台的分布式计算能力和水平横向扩展能力，对问题进行快速诊断分析，并推导节点内、业务系统内问题线索和关联关系，形成非常有价值的故障场景和进程堆栈。
[0068](3)故障早定位。本发明采用特有的故障定位方法，从故障发现到线索追踪，再到推导定位，都建立在大数据量流处理分析基础上，最终以业务系统为单位，对结果进行汇总、展现。
[0069](4)处置有指导。将与故障相关的各种日志特征信息和参数状态信息，集中展现，按故障发展进程排列，为专责处置故障提供有力支持和指导，如果增加应急处置专家模块，可以在线给出处置方案，如果提供自学习模块，可以实现无监督学习和业务应用系统故障预警。
【附图说明】
[0070]下面结合附图对本发明进一步说明:
[0071 ]图1是本发明的系统结构图；
[0072]图2是本发明的总体方法流程图；
[0073]图3是本发明的具体实施方法流程图。
【具体实施方式】
[0074]为能清楚说明本方案的技术特点，下面通过【具体实施方式】，并结合其附图，对本发明进行详细阐述。下文的公开提供了许多不同的实施例或例子用来实现本发明的不同结构。为了简化本发明的公开，下文中对特定例子的部件和设置进行描述。此外，本发明可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。应当注意，在附图中所图示的部件不一定按比例绘制。本发明省略了对公知组件和处理技术及工艺的描述以避免不必要地限制本发明。
[0075]如图1所示，本发明提供了一种在线实时发现、诊断、定位业务应用系统故障的系统。图中以业务系统为单位进行监测、分析和告警，对被监测业务系统采用主动、非侵入式数据采集，实施监测简单，不影响业务系统正常运行，数据采集范围涵盖业务系统及其所在服务器环境的绝大部分日志、运行状态参数，故障的发现和诊断采用专门设计的规则库和规则处理引擎。为达到更强处理能力和响应速度，本发明采用流式数据传输和处理，并在实时计算分析平台部分采用云计算技术，实现可随时扩展的计算能力扩充。
[0076]本发明的一种电力应用系统故障实时分析诊断系统，它包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；
[0077]所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端通过数据总线与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
[0078]所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
[0079]所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
[0080]所述存储模块用以储存分析结果；
[0081]所述显示模块用以展示故障告警信息。
[0082]优选地，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Appl icat1n Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
[0083]优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器，用以实现对业务系统应用状态的实时数据采集。
[0084]优选地，所述消息通道模块首先对数据采集器模块推送的数据进行汇聚，并以流式(stream)消息的方式进行处理和传输，并对消息按地址、类型进行分类处理，为防止数据未处理期间丢失，将数据缓存在本地，消息被处理后会删除本地缓存。所有被监测业务系统的采集数据通过消息通道传递给实时计算分析模块，为了防止消息传输通道因节点故障不可用，本发明对消息通道模块采用集群部署方式。
[0085]优选地，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计 算分析模块。实时计算分析模块是本发明系统分析计算功能的主体部分，每个topology都分为数据源和处理逻辑两个部分，topology数据源可以是消息通道、数据库、另一个topology处理结果。实时计算分析模块主动从消息通道获取消息，并通过预定义的规则库，对消息进行筛选，通过特征识别发现故障，并因此收集追溯故障的进程踪迹，通过推导分析，判定导致故障发生的根本原因和位置，形成故障信息堆栈，以告警形式反馈给用户。实时分析模块计算量大、实时性要求高，根据任务和地址的不同，采用分布式在不同节点并行执行。根据分析计算量，在负载大时还可以对storm进行横向扩展，能够利用云计算虚拟化技术增加节点，提高计算处理能力。
[0086]如图2所示，本发明的一种电力应用系统故障实时分析诊断方法，它包括以下步骤:
[0087]S1:实时从各个业务系统采集数据;所述步骤SI具体包括以下步骤:SlOl:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道；
[0088]S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台；所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存；
[0089]S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用；
[0090]S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常;S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
[0091 ]如图3所示，本发明的具体实施过程如下:
[0092]—、采集器实时从各个业务系统所在服务器采集数据。
[0093](I )以增量形式获取 Webserver Log、AppServer Log、DB Log、0S Log、Applicat1n Log等文件数据，采集器记录每次读取数据位置，作为下一次读取的起点。当文件名变化时，根据命名规则，自动更换文件继续进行读取数据。采集器可以设定两次读取数据的时间间隔，根据日志增长量和网络负载情况进行设定。采集器可以设置分配内存大小，避免采集期间消耗大量内存，对业务系统造成影响。
[0094](2)对业务应用系统所运行环境参数的获取，采集器自动根据操作系统版本等信息，从服务器解析并获得如下参数值:
[0095]用户进程:进程名称、数量等参数。
[0096]服务器内存参数:total、used、free、shared、bufferS、cached、-/+buffers/cache等参数。
[0097]服务器swap参数:Swaptotal、swap usednswap freenswap file数量和size等参数。
[0098]服务器CPU参数:％us、％sy、％n1、％ id、load average、users、total 'running、sleeping、s topped、st 等参数。
[0099]服务器磁盘参数:Mountedon、Use%、Used Avail、Size等参数。
[0100]磁盘10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util等参数。
[0101 ]网络传输参数:工作模式、连通状态、是否丢包、响应时间等参数。
[0102](3)采集器将采集到的业务系统状态数据推送给消息通道，采集器不缓存数据，数据以消息形式推送向消息通道的不同主题分类。
[0103]二、消息通道将来自不同业务系统、不同服务器、不同类别的采集数据进行汇聚，按位置、类别、服务器、业务系统进行分类，以消息流的形式传输，为保证消息安全进行必要缓存，最终提供给实时计算分析平台处理。
[0104]本发明所涉及的“流”是建立在Java语言中的流概念之上，实现从众多不同类型的采集源数据向输出通道、实时计算分析平台高效流动，在业务层面对不同源和目地的数据流进行分类和封装，如1.XXX.XX.XX地址的内存数据。
[0105](I)接收采集器推送的数据，以流式消息方式接收，对不同来源、不同业务系统、不同类型的消息数据进行汇聚。
[0106](2)对消息数据进行分类，分类的依据是数据来源地址、数据来源位置和数据类别。分类格式:地址+位置+类别。地址为数据源IP地址，位置为文件路径，如果为服务器参数则可空，类别包括但不限于:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、cpu、网络等参数类型，且以上类型维护在系统采集数据类型表中，可以根据实际被监测业务系统需要随时增加，即时生效。
[0107]通过消息通道的消息汇聚和分类，为后续步骤消息处理分析做好准备。
[0108](3)为防止数据传输过程中丢失，传输通道可以对数据进行缓存。通过设置在本地磁盘缓存，可以有效解决消息在传输过程中某个环节丢失，缓存在本地磁盘的数据，在实时计算分析模块获取后，即删除掉，防止占用大量磁盘或者存储空间。为了防止数据在传输通道过度累积，实时计算模块可以通过增加并行任务处理节点，加快消息处理速度，及时清除缓存在消息通道的数据。
[0109]三、实时计算分析模块被设计为不断从消息通道顺次获取消息、不停进行实时计算分析的循环处理机制，详细步骤如下:
[0110](I)按地址、位置、类别主动获取消息。实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理，提高处理效率，便于封装业务规则，实现动态平台扩展。
[0111](2)过滤类型topology从数据库的特征识别表获得故障特征，对消息进行过滤和故障识别:如果识别为非故障消息，按照地址、位置、类别更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景。其中:
[0?12]I)过滤类型topo1gy通过以下规则特征识别故障:
[0113]_apache 访问日志
[0114]丨状态代码为4XX、5XX的消息。
[0115]入响应时间超过限定阀值的消息。
[0116]_apache 错误日志
[0117]入级别为:EMERG、ERROR、ALERT、CRIT 的消息。
[0118]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0119]入级别为INFO、NOTI CE、DEBUG，原因描述中包含ERROR、EXCEPT I ON、FAILURE、WARNING等关键字的消息。
[0120]_Tomcat 访问日志
[0121 ]入状态代码为4XX、5XX的消息。
[0122]入响应时间超过限定阀值的消息。
[0123]■ Tomcat 运行日志
[0124]入级别为:SEVERE的消息。
[0125]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0126]丨级别为WARNING、INF0、⑶NFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPT1N、FAILURE、WARNING 等关键字的消息。
[0127]_weblogic访问日志
[0128]入状态代码为4XX、5XX的消息。
[0129]入响应时间超过限定阀值的消息。
[0130]■ web I ogi c服务器日志
[0131 ]丨级别为:ENERGENCY、ALERT、CRITICAL、ERROR 的消息。
[0132]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0133]丨级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0134]Hweblogic domain 日志
[0135]入级别为:ENERGENCY、ALERT、CRITICAL、ERROR的消息。
[0136]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0137]丨级别为WARNING、N0TICE、INF0、TRACE，原因描述中包含ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0138]说明:domain日志需要对已经包含在服务器日志中的故障信息去重。
[0139]■应用程序日志
[0140]入级别为:FAILURE、ERROR的消息。
[0141]入在系统非计划检修期间，状态为启动失败、服务关闭的消息。
[0142]丨日志记录 中包含:ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0143]HOracle alert 日志
[0144]入在系统非计划检修期间，日志记录中包含:状态为启动失败、服务关闭的消息。
[0145]丨日志记录中包含:ERR0R、EXCEPT10N、FAILURE、WARNING等关键字的消息。
[0146]f日志记录中包含:"0RA-数字〃关键字的消息。
[0147]HOracle listener日志
[0148]入RETURN CODE不为O的记录。
[0149]丨RETURNMESSAGE信息包含WARNING、TNS_nn关键字的消息。
[0150]入在系统非计划检修期间，监听启动失败、监听关闭的消息。
[0151]_syslog 日志
[0152]日志记录中包含:ERROR、FAILURE、WARNING等关键字的消息。
[0153]■用户进程
[0154]根据用户进程名称和数量范围设定值，判断用户进程是否正常。
[0155]■内存参数
[0156]根据设定阀值，判断total、used、free、shared、buffers、cached、-/+buffers/cache等参数是否超过警戒值。
[0157]■ swip 参数
[0158]根据设定阀值，判断Swap total、swap used、swap free等参数是否超过警戒线值。
[0159]■ CPU 参数
[Ο??Ο]根据设定阀值，判断％ us、％ sy、%ni N % id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st等参数是否超过警戒值。
[0161]■磁盘参数
[0162]根据设定阀值，判断Mounted on、Use%、Used Avai1、Size等参数是否超过警戒值。
[0163]■磁盘1参数
[0164]根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、await、svctm、％util等参数是否超过警戒值。
[0165]■网络参数
[0166]根据网卡设定，判断网卡工作模式、连通状态等参数是否正确，根据包传输、响应时间等参数判断网络连通是否稳定，响应时间是否超过警戒值。
[0167]识别故障的规则特征不限于以上内容，此处仅是为了展示系统实现的完整性和描述方便，选取以上具有代表性的典型规则特征。通过特征识别表，过滤类型topology可根据业务需要动态扩展或者缩小故障识别范围。
[0168]2)故障场景的保存由过滤型topology执行，在识别为故障消息后，从故障消息前两行或者前一个状态开始，直至故障消息结束或者状态恢复，将故障消息拼接为连续的故障场景，与地址、位置、类别相关联，保存在故障场景文件中。
[0169](3)按地址汇聚信息、规则推导。
[0170]实现按地址汇聚信息的是节点型topology，数据源为过滤型topology和高速共享缓存区。节点型topology可以将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，根据节点故障语义识别规则和推导规则表的定义进行故障推导，节点型topo I ogy规则推导总体遵循:环境故障先于应用故障规则。下面选择具有典型代表性的推导步骤描述如下:[Ο171 ] I)假设通过过滤型topology获得某节点SERVER级别异常，节点型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障;如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤(4)按业务系统汇聚信息。
[0172]2)通过判定为服务不可用故障，通过推导规则表，分别进行如下推导:
[0173]a)判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步。
[0174]b)判断用户进程名称和数量是否正常，如果为O或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步。
[0175]c)判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤(4)判断，继续后续推导。
[0176]d)判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤(4)判断。
[0177]3)节点型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
[0178](4)按业务系统汇聚信息、规则推导
[0179]实现按业务系统汇聚信息的是业务型topology，数据源为节点型topology和高速共享缓存区。业务型topology以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，根据业务关系规则表中定义的进行故障推导，业务型topology规则推导总体遵循:以信息流动方向为规则的逻辑次序。下面继续根据上一步骤的例子描述本步骤的推导过程:
[0180]I)获得步骤(3)推导结果，按照WebServer->AppServer_>Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤(3)2)c)和d)进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区。
[0181 ] 2)其次，判断AppServer层节点故障，如果WebServer层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因。
[0182]3)再次，判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因。
[0183]4)最后，当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
[0184](5)梳理故障演进过程，创建故障进程堆栈
[0185]以业务系统为单位，组织步骤(4)的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的堆栈，并与保存在文件中的故障场景进行关联，供告警和展示用。
[0186]四、结果存储和告警展现。
[0187](I)所有计算分析结果，都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常。实时计算平台的计算结果不但包括故障信息，也包括业务系统健康运行状态的统计信息。
[0188](2)在监控界面，以业务系统为单位，展示每个系统的状态信息，如果某个系统被发现故障，则以故障发展进程倒序展示给用户，用户可以业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录，指导用户追踪、处置故障。
[0189]以上所述只是本发明的优选实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也被视为本发明的保护范围。
【主权项】
1.一种电力应用系统故障实时分析诊断系统，其特征是，包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块； 所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务系统相连，用以实时采集业务系统的文件数据和状态数据，所述数据采集器的输出端与消息通道模块相连，用以将采集到的数据推送到消息通道模块； 所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块； 所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则;所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块;所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息； 所述存储模块用以储存分析结果； 所述显示模块用以展示故障告警信息。2.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述业务系统的文件数据包括Webserver Log、AppServer Log、DB Log、OS Log和Applicat1nLog文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。3.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述数据采集器为具有增量采集和频度设定功能的数据采集器;所述消息通道模块采用集群部署方式、具备缓存功能的流式消息传输模块。4.根据权利要求1所述的一种电力应用系统故障实时分析诊断系统，其特征是，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。5.—种电力应用系统故障实时分析诊断方法，其特征是，包括以下步骤: S1:实时从各个业务系统采集数据;所述步骤S1具体包括以下步骤:S101:以增量形式获取Webserver Log、AppServer Log、DB Log、0S Log和Applicat1n Log文件数据，并记录每次读取数据的位置，作为下一次读取的起点；S102:获取各个业务系统的内存参数、磁盘参数、cpu参数、进程参数和网络参数状态数据;S103:将采集到的业务系统文件数据和状态数据以消息形式推送给消息通道； S2:消息通道将采集的数据进行汇聚并按照位置、类别、服务器地址进行分类，并传输给实时计算分析平台;所述步骤S2具体包括以下步骤:S201:以流式消息方式接收采集器推送的数据，并对不同来源、不同业务系统、不同类型的消息数据进行汇聚处理;S202:对汇聚后消息数据按照位置、类别、服务器地址进行分类处理;S203:对处理后数据进行缓存； S3:实时计算分析模块从消息通道顺次获取消息，采用循环处理机制对消息进行实时计算分析，判定故障发生原因和故障发生位置，并形成故障信息堆栈;所述步骤S3具体包括以下步骤:S301:按照地址、位置和类别主动获取消息，实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理;S302:过滤类型topology从规则库中获取故障识别特征对消息进行过滤和故障识别:如果识 别为非故障消息，按照位置、类别、服务器地址更新数据源的状态和时间长;如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景;S303:节点类型topology对过滤类型topology处理后的数据和高速共享缓存区内的数据按照地址将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，并根据节点故障语义识别规则和推导规则表的定义按照环境故障先于应用故障的规则进行故障推导，并将推导结果保存到高速共享缓冲区；S304:业务类型topology对节点类型topology处理后的数据和高速共享缓存区内的数据以业务系统为单位，将不同节点按照业务信息处理次序组织到一起，并根据业务关系规则表中定义以信息流动方向为规则的逻辑次序进行故障推导，并将推导结果保存到高速共享缓冲区；S305:以业务系统为单位，组织步骤S304的推导结果，按照业务系统数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的故障信息堆栈，并与保存在文件中的故障场景进行关联，供告警和展示使用； S4:储存诊断结果和展现告警信息；所述步骤S4具体包括以下步骤:S401:将所有的计算分析结果都以业务系统为单位保存到数据库和文件中，分析结果分为两类:正常和异常；S402:在监控界面以业务系统为单位展示每个业务系统的状态信息，如果某个业务系统被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务系统故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。6.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述获取各个业务系统的状态数据包括但不限于: 用户进程:进程名称及数量参数； 服务器内存参数:total、used、free、shared、buff ers、cached、-/+buff ers/cache 参数； 服务器swap参数:Swap totalnswap usednswap freenswap file数量和size参数； 服务器CPU参数:％us、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、％s1、％st参数； 服务器磁盘参数:Mounted on、Use%、Used Avail、Size参数； 磁盘 10参数:TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu_sz、awai t、svctm、％util参数； 网络传输参数:工作模式、连通状态、是否丢包、响应时间参数。7.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，对汇聚后消息数据进行分类处理过程中采用的分类格式为:地址+位置+类别;地址即数据来源地址，为数据源的IP地址;位置即数据来源位置，为文件路径，如果为服务器参数则可空;类别即数据类别，包括但不限于以下类型:Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic月艮务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘1、cpu、和网络参数。8.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述故障识别特征包括但不限于以下内容: 1 )apache访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息； 2)apache错误日志:级别为EMERG、ERROR、ALERT、CRIT的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息； 3)Tomcat访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息； 4)Tomcat运行日志:级别为SEVERE的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPT1N、FAI LURE 和 WARNING 关键字的消息； 5)webl0giC访问日志:状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息; 6)weblogic服务器日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARN ING、NOT ICE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息； 7)weblogicdomaiη日志:级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARN I NG、NOT I CE、INF0、TRACE，原因描述中包含ERROR、EXCEPT1N、FAI LURE和WARNING关键字的消息； 8)应用程序日志:级别为FAILURE、ERROR的消息，在系统非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERROR、EXCEPT1N、FAILURE、WARNING关键字的消息； 9)0raclealert日志:在系统非计划检修期间，日志记录中包含:状态为启动失败、月艮务关闭的消息，日志记录中包含ERROR、EXCEPT1N、FAILURE和WARNING关键字的消息，日志记录中包含"0RA-数字〃关键字的消息； 10)0racle1 istener 日志:RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在系统非计划检修期间，监听启动失败、监听关闭的消息; 1 Dsyslog日志:日志记录中包含ERROR、FAILURE和WARNING关键字的消息； 12)用户进程:根据用户进程名称和数量范围设定值，判断用户进程是否正常； 13)内存参数:根据设定阀值，判断total、used、free、shared、buffers、cached、_/+buff ers/cache参数是否超过警戒值； 14)swap参数:根据设定阀值，判断Swaptotal、swap used和swap free参数是否超过警戒线值； 15)CPU参数:根据设定阀值，判断^仍、％sy、％n1、％id、load average、users、total、running、sleeping、stopped、％h1、参数是否超过警戒值； 16)磁盘参数:根据设定阀值，判断Mountedon、Use %、Used Avail和Size参数是否超过警戒值； 17)磁盘1参数:根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctn^P%util参数是否超过警戒值； 18)网络参数:根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。9.根据权利要求5所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述节点类型topology进行故障推导的过程包括以下步骤: 53031)假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2);如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务系统进行汇聚信息； 53032)对判定为服务不可用故障的信息通过推导规则表进行如下推导: 判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步； 判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步； 判断cpu参数，如果％sy在40%以上且％ni较高，或者％us在75%以上且％hi数量大，则存在系统进程因磁盘1等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导； 判断swap参数，swap used逐渐增加，swap free逐步减少，说明系统内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断； 53033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。10.根据权利要求9所述的一种电力应用系统故障实时分析诊断方法，其特征是，所述业务类型topology进行故障推导的过程包括以下步骤: 53041)获得步骤S3033)的推导结果，按照WebServer->AppServer_>Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于Webserver层的故障，如果服务不可用出现在本层，则对步骤S3042)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否贝lj，c)和d)作为Webserver层相应节点的性能问题单独保存到高速共享缓冲区； 53042)判断AppServer层节点故障，如果Webserver层已经存在网络故障，贝ijAppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为Webserver层相应节点故障的原因； 53043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因； 53044)当不同业务系统共享节点时，共享节点按照不同业务系统中的节点，分别记录故障推导关系。
【专利摘要】一种电力应用系统故障实时分析诊断系统及方法,系统包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；所述数据采集模块用以实时采集业务系统的文件数据和状态数据并推送到消息通道模块；所述消息通道模块用以对采集的数据进行汇聚后并进行分类处理；所述实时计算分析模块对数据进行筛选确定的故障信息，并对故障信息进行通过推导分析判定故障发生原因和故障发生位置；所述存储模块用以储存分析结果；所述显示模块用以展示故障告警信息。本发明以业务系统为单位，对实时采集业务系统的数据进行分析处理，确定故障业务系统、所在服务器、故障位置，并推导出故障特征的关联关系，用以指导故障应急处置。
【IPC分类】G06Q10/06, G06Q50/06
【公开号】CN105488610
【申请号】CN201510821162
【发明人】严莉, 王丞远, 刘范范, 曲延盛, 张宏基, 汤耀庭, 王岳, 赵晓, 林鹏
【申请人】国网山东省电力公司信息通信公司, 国家电网公司
【公开日】2016年4月13日
【申请日】2015年11月23日
最新回复(0)