CN105488610B - 一种电力应用***故障实时分析诊断方法 - Google Patents

一种电力应用***故障实时分析诊断方法 Download PDF

Info

Publication number
CN105488610B
CN105488610B CN201510821162.6A CN201510821162A CN105488610B CN 105488610 B CN105488610 B CN 105488610B CN 201510821162 A CN201510821162 A CN 201510821162A CN 105488610 B CN105488610 B CN 105488610B
Authority
CN
China
Prior art keywords
failure
message
data
fault
parameter
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.)
Active
Application number
CN201510821162.6A
Other languages
English (en)
Other versions
CN105488610A (zh
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.)
State Grid Corp of China SGCC
Information and Telecommunication Branch of State Grid Shandong Electric Power Co Ltd
Original Assignee
State Grid Corp of China SGCC
Information and Telecommunication Branch of State Grid Shandong Electric Power 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 State Grid Corp of China SGCC, Information and Telecommunication Branch of State Grid Shandong Electric Power Co Ltd filed Critical State Grid Corp of China SGCC
Priority to CN201510821162.6A priority Critical patent/CN105488610B/zh
Publication of CN105488610A publication Critical patent/CN105488610A/zh
Application granted granted Critical
Publication of CN105488610B publication Critical patent/CN105488610B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Educational Administration (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Game Theory and Decision Science (AREA)
  • Public Health (AREA)
  • Water Supply & Treatment (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种电力应用***故障实时分析诊断***及方法,***包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；所述数据采集模块用以实时采集业务***的文件数据和状态数据并推送到消息通道模块；所述消息通道模块用以对采集的数据进行汇聚后并进行分类处理；所述实时计算分析模块对数据进行筛选确定的故障信息，并对故障信息进行通过推导分析判定故障发生原因和故障发生位置；所述存储模块用以储存分析结果；所述显示模块用以展示故障告警信息。本发明以业务***为单位，对实时采集业务***的数据进行分析处理，确定故障业务***、所在服务器、故障位置，并推导出故障特征的关联关系，用以指导故障应急处置。

Description

一种电力应用***故障实时分析诊断方法
技术领域
本发明涉及一种故障分析诊断***及方法，具体地说是一种电力应用***故障实时分析诊断***及方法，属于电力***自动化技术领域。
背景技术
随着电力行业“十二五规划”任务的逐步完成，电力企业已建成覆盖各级单位、各业务领域的诸多业务应用***，由此，保障各业务应用***的安全运行就成了重要课题。特别是，当业务应用***发生故障时，能够做到早发现、早诊断、快速定位，迅速采取故障应急处置措施，具有非常重要的意义。
目前，多数业务应用***的运行监测以指标报送、服务器监控为主，以发现和告警导致***停运的重大故障、服务器硬件故障为重点，而***局部功能故障和导致重大故障前的故障线索则难以监控。从日常运行维护角度讲，也缺少以业务***为单位，全面监测业务应用***安全运行的措施和方法，传统的业务应用***运行监测方法存在以下问题：
(1)故障发现迟，留给处置故障的时间短。因为缺少全方位监测和分析的措施方法，局部功能故障和小故障多数在用户使用过程中被发现并报告，而当监测***告警时，业务***往往已经停运，或者部分节点停运，造成的影响很大，留给应急处置的时间极为有限，运检人员压力巨大。
(2)依赖人工排查故障线索。常规的监控***都能提供告警，但缺少故障线索发现和推导跟踪功能。故障告警后，仍然需要熟悉各个专业的专工赶到现场，通过人工搜集和查看各种日志、各种中间件状态、业务***环境参数，从中发现故障线索，并进行汇总、整理和分析，整个过程耗时、耗力，还容易出现疏漏。
(3)不能按业务***进行故障诊断分析，定位故障原因。常规监控***提供的故障分析和定位能力有限，很难做到按照业务***进行故障诊断分析，最终仍然依靠人工分析和定位故障。复杂的故障，往往需要多个专业经验丰富的专家集体会诊，进行原因确认和定位。
(4)难以重现故障场景，故障处置时间长。因为缺少以业务***单位组织的全面监测和分析***，故障发生后，大部分故障线索需要各专业经验丰富专家从大量日志、参数中查找蛛丝马迹，但一些对故障诊断分析有重要作用的业务***环境的参数和日志，因为没有及时保存故障现场，已经不能获得，严重影响故障诊断和定位，造成故障处置时间不断推迟。
发明内容
为克服上述现有技术存在的不足，本发明提供了一种电力应用***故障实时分析诊断***及方法,其能够对电力应用***进行故障定位与诊断，有效对电力应用***的故障应急处置进行指导。
本发明解决其技术问题所采取的技术方案是：一种电力应用***故障实时分析诊断***，其特征是，包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；
所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务***相连，用以实时采集业务***的文件数据和 状态数据，所述数据采集器的输出端与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则；所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块；所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
所述存储模块用以储存分析结果；
所述显示模块用以展示故障告警信息。
优选地，所述业务***的文件数据包括WebServer Log、AppServer Log、DB Log、OS Log和Application Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器；所述消息通道模块采用集群部署方式、具备缓存功能的流式消息传输模块。
优选地，所述实时计算分析模块以storm实时计算平台为基础，以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。
本发明还提供了一种电力应用***故障实时分析诊断方法，其特征是，包括以下步骤：
S1：实时从各个业务***采集数据；所述步骤S1具体包括以下步骤：S101：以增量形式获取WebServer Log、AppServer Log、DB Log、OS Log和Application 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：在监控界面以业务***为单位展示每个业务***的状态信息，如果某个业务***被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务***故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
优选地，所述获取各个业务***的状态数据包括但不限于：
用户进程：进程名称及数量参数；
服务器内存参数：total、used、free、shared、buffers、cached、-/+buffers/cache参数；
服务器swap参数：Swap total、swap used、swap free、swap file数量和size参数；
服务器CPU参数：％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si、％st参数；
服务器磁盘参数：Mounted on、Use％、Used Avail、Size参数；
磁盘IO参数：TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm、％util参数；
网络传输参数：工作模式、连通状态、是否丢包、响应时间参数。
优选地，对汇聚后消息数据进行分类处理过程中采用的分类格式为：地址+位置+类别；地址即数据来源地址，为数据源的IP地址；位置即数据来源位置，为文件路径，如果为服务器参数则可空；类别即数据类别，包括但不限于以下类型：Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘io、cpu、和网络参数。
优选地，所述故障识别特征包括但不限于以下内容：
1)apache访问日志：状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息；
2)apache错误日志：级别为EMERG、ERROR、ALERT、CRIT的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
3)Tomcat访问日志：状态代码为4XX、5XX的消息，以及响应 时间超过限定阀值的消息；
4)Tomcat运行日志：级别为SEVERE的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
5)weblogic访问日志：状态代码为4XX、5XX的消息，以及响应时间超过限定阀值的消息；
6)weblogic服务器日志：级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
7)weblogic domain日志：级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
8)应用程序日志：级别为FAILURE、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERROR、EXCEPTION、FAILURE、WARNING关键字的消息；
9)Oracle alert日志：在***非计划检修期间，日志记录中包含：状态为启动失败、服务关闭的消息，日志记录中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息，日志记录中包含"ORA-数字"关键字的消息；
10)Oracle listener日志：RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在***非计划检修期间，监听启动失败、监听关闭的消息；
11)syslog日志：日志记录中包含ERROR、FAILURE和WARNING关键字的消息；
12)用户进程：根据用户进程名称和数量范围设定值，判断用户进程是否正常；
13)内存参数：根据设定阀值，判断total、used、free、shared、buffers、cached、-/+buffers/cache参数是否超过警戒值；
14)swap参数：根据设定阀值，判断Swap total、swap used和swap free参数是否超过警戒线值；
15)CPU参数：根据设定阀值，判断％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si和％st参数是否超过警戒值；
16)磁盘参数：根据设定阀值，判断Mounted on、Use％、Used Avail和Size参数是否超过警戒值；
17)磁盘io参数：根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm和％util参数是否超过警戒值；
18)网络参数：根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。
优选地，所述节点类型topology进行故障推导的过程包括以下步骤：
S3031)假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2)；如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续 的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务***进行汇聚信息；
S3032)对判定为服务不可用故障的信息通过推导规则表进行如下推导：
判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步；
判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步；
判断cpu参数，如果％sy在40％以上且％ni较高，或者％us在75％以上且％hi数量大，则存在***进程因磁盘io等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导；
判断swap参数，swap used逐渐增加，swap free逐步减少，说明***内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断；
S3033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
优选地，所述业务类型topology进行故障推导的过程包括以下步骤：
S3041)获得步骤S3033)的推导结果，按照WebServer->AppServer->Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于WebServer层的故障，如果服 务不可用出现在本层，则对步骤S3042)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为WebServer层相应节点的性能问题单独保存到高速共享缓冲区；
S3042)判断AppServer层节点故障，如果WebServer层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为WebServer层相应节点故障的原因；
S3043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因；
S3044)当不同业务***共享节点时，共享节点按照不同业务***中的节点，分别记录故障推导关系。
本发明的有益效果如下：本发明以业务***为单位，实时采集业务***的应用、中间件、数据库、操作***、硬盘、CPU、内存、网络等的日志、实时状态参数，经过汇聚传输和分类、特征筛选、线索汇集、原因分析，实时发现故障，确定故障业务***、所在服务器、故障位置，并推导处故障特征的关联关系，用以指导故障应急处置。
本发明通过对电力应用***进行故障定位与诊断，有效对电力应用***的故障应急处置进行指导，与现有技术相比有以下优点：
(1)状态早发现。以业务***为单位，可以将业务***所有类型的状态、日志文件作为监测数据源，避免以往监控***监测范围 固定且狭小，很多早期故障状态特征难以发现的问题。采集数据以消息流的方式传输，并汇聚、分类，由实时计算分析平台的筛选任务进行迅速特征筛选。消息的传递和处理都以流的方式进行，快速高效，消息传输和实时计算任务都采用集群负载均衡，并且可以根据计算量，横向扩展增加计算节点，保证消息在迅速得到处理，异常状态第一时间被发现。
(2)问题早分析。异常状态发现后，会迅速交由节点型任务和业务型任务进行分析处理。同样的，节点型任务和业务型任务也基于实时计算分析平台的分布式计算能力和水平横向扩展能力，对问题进行快速诊断分析，并推导节点内、业务***内问题线索和关联关系，形成非常有价值的故障场景和进程堆栈。
(3)故障早定位。本发明采用特有的故障定位方法，从故障发现到线索追踪，再到推导定位，都建立在大数据量流处理分析基础上，最终以业务***为单位，对结果进行汇总、展现。
(4)处置有指导。将与故障相关的各种日志特征信息和参数状态信息，集中展现，按故障发展进程排列，为专责处置故障提供有力支持和指导，如果增加应急处置专家模块，可以在线给出处置方案，如果提供自学习模块，可以实现无监督学习和业务应用***故障预警。
附图说明
下面结合附图对本发明进一步说明：
图1是本发明的***结构图；
图2是本发明的总体方法流程图；
图3是本发明的具体实施方法流程图。
具体实施方式
为能清楚说明本方案的技术特点，下面通过具体实施方式，并结合其附图，对本发明进行详细阐述。下文的公开提供了许多不同的实施例或例子用来实现本发明的不同结构。为了简化本发明的公开，下文中对特定例子的部件和设置进行描述。此外，本发明可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。应当注意，在附图中所图示的部件不一定按比例绘制。本发明省略了对公知组件和处理技术及工艺的描述以避免不必要地限制本发明。
如图1所示，本发明提供了一种在线实时发现、诊断、定位业务应用***故障的***。图中以业务***为单位进行监测、分析和告警，对被监测业务***采用主动、非侵入式数据采集，实施监测简单，不影响业务***正常运行，数据采集范围涵盖业务***及其所在服务器环境的绝大部分日志、运行状态参数，故障的发现和诊断采用专门设计的规则库和规则处理引擎。为达到更强处理能力和响应速度，本发明采用流式数据传输和处理，并在实时计算分析平台部分采用云计算技术，实现可随时扩展的计算能力扩充。
本发明的一种电力应用***故障实时分析诊断***，它包括数据采集模块、消息通道模块、实时计算分析模块、存储模块和显示模块；
所述数据采集模块包括若干个数据采集器，所述数据采集器的输入端分别与业务***相连，用以实时采集业务***的文件数据和状态数据，所述数据采集器的输出端通过数据总线与消息通道模块相连，用以将采集到的数据推送到消息通道模块；
所述消息通道模块包括数据汇聚模块和数据分类模块，所述数据汇聚模块用以接收数据采集器推送的数据，并对所有数据采集器 采集的数据采用流式消息方式进行汇聚后发送给数据分类模块，所述数据分类模块对汇聚后的数据按位置、地址、类型进行分类处理，并将分类后数据发送给实时计算分析模块；
所述实时计算分析模块包括规则库模块、筛选模块和定位模块，所述规则库模块用以存储预定义的故障特征识别规则、节点故障语义识别规则和推导规则；所述筛选模块根据故障特征识别规则对消息通道模块发送的数据进行筛选，并将确定的故障消息发送给定位模块；所述定位模块根据故障语义识别规则和推导规则表对故障信息进行通过推导分析，判定故障发生原因和故障发生位置，并将形成故障信息堆栈和故障告警信息；
所述存储模块用以储存分析结果；
所述显示模块用以展示故障告警信息。
优选地，所述业务***的文件数据包括WebServer Log、AppServer Log、DB Log、OS Log和Application Log文件，状态数据包括内存参数、磁盘参数、cpu参数、进程参数和网络参数。
优选地，所述数据采集器为具有增量采集和频度设定功能的数据采集器，用以实现对业务***应用状态的实时数据采集。
优选地，所述消息通道模块首先对数据采集器模块推送的数据进行汇聚，并以流式(stream)消息的方式进行处理和传输，并对消息按地址、类型进行分类处理，为防止数据未处理期间丢失，将数据缓存在本地，消息被处理后会删除本地缓存。所有被监测业务***的采集数据通过消息通道传递给实时计算分析模块，为了防止消息传输通道因节点故障不可用，本发明对消息通道模块采用集群部署方式。
优选地，所述实时计算分析模块以storm实时计算平台为基础， 以topology为基本处理单元，可以根据任务和地址的不同，采用分布式云计算实时计算分析模块。实时计算分析模块是本发明***分析计算功能的主体部分，每个topology都分为数据源和处理逻辑两个部分，topology数据源可以是消息通道、数据库、另一个topology处理结果。实时计算分析模块主动从消息通道获取消息，并通过预定义的规则库，对消息进行筛选，通过特征识别发现故障，并因此收集追溯故障的进程踪迹，通过推导分析，判定导致故障发生的根本原因和位置，形成故障信息堆栈，以告警形式反馈给用户。实时分析模块计算量大、实时性要求高，根据任务和地址的不同，采用分布式在不同节点并行执行。根据分析计算量，在负载大时还可以对storm进行横向扩展，能够利用云计算虚拟化技术增加节点，提高计算处理能力。
如图2所示，本发明的一种电力应用***故障实时分析诊断方法，它包括以下步骤：
S1：实时从各个业务***采集数据；所述步骤S1具体包括以下步骤：S101：以增量形式获取WebServer Log、AppServer Log、DB Log、OS Log和Application 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：在监控界面以业务***为单位展示每个业务***的状态信息，如果某个业务***被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务***故障发生在哪个节 点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
如图3所示，本发明的具体实施过程如下：
一、采集器实时从各个业务***所在服务器采集数据。
(1)以增量形式获取WebServer Log、AppServer Log、DB Log、OS Log、Application Log等文件数据，采集器记录每次读取数据位置，作为下一次读取的起点。当文件名变化时，根据命名规则，自动更换文件继续进行读取数据。采集器可以设定两次读取数据的时间间隔，根据日志增长量和网络负载情况进行设定。采集器可以设置分配内存大小，避免采集期间消耗大量内存，对业务***造成影响。
(2)对业务应用***所运行环境参数的获取，采集器自动根据操作***版本等信息，从服务器解析并获得如下参数值：
用户进程：进程名称、数量等参数。
服务器内存参数：total、used、free、shared、buffers、cached、-/+buffers/cache等参数。
服务器swap参数：Swap total、swap used、swap free、swap file数量和size等参数。
服务器CPU参数：％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si、％st等参数。
服务器磁盘参数：Mounted on、Use％、Used Avail、Size等参数。
磁盘IO参数：TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm、％util等参数。
网络传输参数：工作模式、连通状态、是否丢包、响应时间等参数。
(3)采集器将采集到的业务***状态数据推送给消息通道，采集器不缓存数据，数据以消息形式推送向消息通道的不同主题分类。
二、消息通道将来自不同业务***、不同服务器、不同类别的采集数据 进行汇聚，按位置、类别、服务器、业务***进行分类，以消息流的形式传输，为保证消息安全进行必要缓存，最终提供给实时计算分析平台处理。
本发明所涉及的“流”是建立在Java语言中的流概念之上，实现从众多不同类型的采集源数据向输出通道、实时计算分析平台高效流动，在业务层面对不同源和目地的数据流进行分类和封装，如10.xxx.xx.xx地址的内存数据。
(1)接收采集器推送的数据，以流式消息方式接收，对不同来源、不同业务***、不同类型的消息数据进行汇聚。
(2)对消息数据进行分类，分类的依据是数据来源地址、数据来源位置和数据类别。分类格式：地址+位置+类别。地址为数据源IP地址，位置为文件路径，如果为服务器参数则可空，类别包括但不限于：Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog等文件类型；用户进程、内存、swap、磁盘、磁盘io、cpu、网络等参数类型，且以上类型维护在***采集数据类型表中，可以根据实际被监测业务***需要随时增加，即时生效。
通过消息通道的消息汇聚和分类，为后续步骤消息处理分析做好准备。
(3)为防止数据传输过程中丢失，传输通道可以对数据进行缓存。通过设置在本地磁盘缓存，可以有效解决消息在传输过程中某个环节丢失，缓存在本地磁盘的数据，在实时计算分析模块获取后，即删除掉，防止占用大量磁盘或者存储空间。为了防止数据在传输通道过度累积，实时计算模块可以通过增加并行任务处理节点，加快消息处理速度，及时清除缓存在消息通道的数据。
三、实时计算分析模块被设计为不断从消息通道顺次获取消息、不停进行实时计算分析的循环处理机制，详细步骤如下：
(1)按地址、位置、类别主动获取消息。实时计算分析模块的过滤类型topology将消息先按类别分组，以便不同类型消息交给固定的topology处理，提高处理效率，便于封装业务规则，实现动态平台扩展。
(2)过滤类型topology从数据库的特征识别表获得故障特征，对消息进行过滤和故障识别：如果识别为非故障消息，按照地址、位置、类别更新数据源的状态和时间长；如果识别为故障消息，将消息交个故障分析topology，置数据源状态为故障，开始累计故障时长，将识别结果保存到高速共享缓冲区，并保存故障场景。其中：
1)过滤类型topology通过以下规则特征识别故障：
■apache访问日志
√状态代码为4XX、5XX的消息。
√响应时间超过限定阀值的消息。
■apache错误日志
√级别为:EMERG、ERROR、ALERT、CRIT的消息。
√在***非计划检修期间，状态为启动失败、服务关闭的消息。
√级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
■Tomcat访问日志
√状态代码为4XX、5XX的消息。
√响应时间超过限定阀值的消息。
■Tomcat运行日志
√级别为:SEVERE的消息。
√在***非计划检修期间，状态为启动失败、服务关闭的消息。
√级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
■weblogic访问日志
√状态代码为4XX、5XX的消息。
√响应时间超过限定阀值的消息。
■weblogic服务器日志
√级别为：ENERGENCY、ALERT、CRITICAL、ERROR的消息。
√在***非计划检修期间，状态为启动失败、服务关闭的消息。
√级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
■weblogic domain日志
√级别为：ENERGENCY、ALERT、CRITICAL、ERROR的消息。
√在***非计划检修期间，状态为启动失败、服务关闭的消息。
√级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
说明：domain日志需要对已经包含在服务器日志中的故障信息去重。
■应用程序日志
√级别为：FAILURE、ERROR的消息。
√在***非计划检修期间，状态为启动失败、服务关闭的消息。
√日志记录中包含：ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
■Oracle alert日志
√在***非计划检修期间，日志记录中包含：状态为启动失败、服务关闭的消息。
√日志记录中包含：ERROR、EXCEPTION、FAILURE、WARNING等关键字的消息。
√日志记录中包含："ORA-数字"关键字的消息。
■Oracle listener日志
√RETURN CODE不为0的记录。
√RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息。
√在***非计划检修期间，监听启动失败、监听关闭的消息。
■syslog日志
日志记录中包含：ERROR、FAILURE、WARNING等关键字的消息。
■用户进程
根据用户进程名称和数量范围设定值，判断用户进程是否正常。
■内存参数
根据设定阀值，判断total、used、free、shared、buffers、cached、-/+buffers/cache等参数是否超过警戒值。
■swap参数
根据设定阀值，判断Swap total、swap used、swap free等参数是否超过警戒线值。
■CPU参数
根据设定阀值，判断％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si、％st等参数是否超过警戒值。
■磁盘参数
根据设定阀值，判断Mounted on、Use％、Used Avail、Size等参数是否超过警戒值。
■磁盘io参数
根据设定阀值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm、％util等参数是否超过警戒值。
■网络参数
根据网卡设定，判断网卡工作模式、连通状态等参数是否正确，根据包传输、响应时间等参数判断网络连通是否稳定，响应时间是否超过警戒值。
识别故障的规则特征不限于以上内容，此处仅是为了展示***实现的完整性和描述方便，选取以上具有代表性的典型规则特征。通过特征识别表，过滤类型topology可根据业务需要动态扩展或者缩小故障识别范围。
2)故障场景的保存由过滤型topology执行，在识别为故障消息后，从故障消息前两行或者前一个状态开始，直至故障消息结束或者状态恢复，将故障消息拼接为连续的故障场景，与地址、位置、类别相关联，保存在故障场景文件中。
(3)按地址汇聚信息、规则推导。
实现按地址汇聚信息的是节点型topology，数据源为过滤型topology和高速共享缓存区。节点型topology可以将所有属于该节点地址的所有故障信息和环境参数信息汇聚到一起，根据节点故障语义识别规则和推导规则表的定义进行故障推导，节点型topology规则推导总体遵循：环境故障先于应用故障规则。下面选择具有典型代表性的推导步骤描述如下：
1)假设通过过滤型topology获得某节点SERVER级别异常，节点型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障；如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤(4)按业务***汇聚信息。
2)通过判定为服务不可用故障，通过推导规则表，分别进行如下推导：
a)判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步。
b)判断用户进程名称和数量是否正常，如果为0或者超过最大值，则 将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步。
c)判断cpu参数，如果％sy在40％以上且％ni较高，或者％us在75％以上且％hi数量大，则存在***进程因磁盘io等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤(4)判断，继续后续推导。
d)判断swap参数，swap used逐渐增加，swap free逐步减少，说明***内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤(4)判断。
3)节点型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
(4)按业务***汇聚信息、规则推导
实现按业务***汇聚信息的是业务型topology，数据源为节点型topology和高速共享缓存区。业务型topology以业务***为单位，将不同节点按照业务信息处理次序组织到一起，根据业务关系规则表中定义的进行故障推导，业务型topology规则推导总体遵循：以信息流动方向为规则的逻辑次序。下面继续根据上一步骤的例子描述本步骤的推导过程：
1)获得步骤(3)推导结果，按照WebServer->AppServer->Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于WebServer层的故障，如果服务不可用出现在本层，则对步骤(3)2)c)和d)进行确认，如果已经排除了网络和用户进程故障，也排出了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为WebServer层相应节点的性能问题单独保存到高速共享缓冲区。
2)其次，判断AppServer层节点故障，如果WebServer层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为WebServer层相应节点故障的原因。
3)再次，判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因。
4)最后，当不同业务***共享节点时，共享节点按照不同业务***中的节点，分别记录故障推导关系。
(5)梳理故障演进过程，创建故障进程堆栈
以业务***为单位，组织步骤(4)的推导结果，按照业务***数据的逻辑处理次序，将故障形成从结果到原因的链条，构建故障发展进程的堆栈，并与保存在文件中的故障场景进行关联，供告警和展示用。
四、结果存储和告警展现。
(1)所有计算分析结果，都以业务***为单位保存到数据库和文件中，分析结果分为两类：正常和异常。实时计算平台的计算结果不但包括故障信息，也包括业务***健康运行状态的统计信息。
(2)在监控界面，以业务***为单位，展示每个***的状态信息，如果某个***被发现故障，则以故障发展进程倒序展示给用户，用户可以业务***故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录，指导用户追踪、处置故障。
以上所述只是本发明的优选实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也被视为本发明的保护范围。

Claims (6)

1.一种电力应用***故障实时分析诊断方法，其特征是，包括以下步骤：
S1：实时从各个业务***采集数据；所述步骤S1具体包括以下步骤：S101：以增量形式获取WebServer Log、AppServer Log、DB Log、OS Log和Application 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：在监控界面以业务***为单位展示每个业务***的状态信息，如果某个业务***被发现故障，则以故障发展进程倒序发送给客户端向用户展示，用户可以看到业务***故障发生在哪个节点、哪类组件或者设备、故障原因，并能够查看当时故障现场记录。
2.根据权利要求1所述的一种电力应用***故障实时分析诊断方法，其特征是，所述获取各个业务***的状态数据包括但不限于：
用户进程：进程名称及数量参数；
服务器内存参数：total、used、free、shared、buffers、cached、-/+buffers/cache参数；
服务器swap参数：Swap total、swap used、swap free、swap file数量和size参数；
服务器CPU参数：％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si、％st参数；
服务器磁盘参数：Mounted on、Use％、Used Avail、Size参数；
磁盘IO参数：TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm、％util参数；
网络传输参数：工作模式、连通状态、是否丢包、响应时间参数。
3.根据权利要求1所述的一种电力应用***故障实时分析诊断方法，其特征是，对汇聚后消息数据进行分类处理过程中采用的分类格式为：地址+位置+类别；地址即数据来源地址，为数据源的IP地址；位置即数据来源位置，为文件路径，如果为服务器参数则可空；类别即数据类别，包括但不限于以下类型：Apache访问日志、Apache错误日志、Tomcat访问日志、Tomcat运行日志、Weblogic访问日志、Weblogic服务器日志、Weblogic Domain日志、Weblogic控制台输出、Oracle监听日志、Oracle alert日志、Syslog文件类型，以及用户进程、内存、swap、磁盘、磁盘io、cpu、和网络参数类型。
4.根据权利要求1所述的一种电力应用***故障实时分析诊断方法，其特征是，所述故障识别特征包括但不限于以下内容：
1)apache访问日志：状态代码为4XX、5XX的消息，以及响应时间超过限定阈值的消息；
2)apache错误日志：级别为EMERG、ERROR、ALERT、CRIT的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为INFO、NOTICE、DEBUG，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
3)Tomcat访问日志：状态代码为4XX、5XX的消息，以及响应时间超过限定阈值的消息；
4)Tomcat运行日志：级别为SERVER的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、INFO、CONFIG、FINE、FINER、FINEST，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
5)weblogic访问日志：状态代码为4XX、5XX的消息，以及响应时间超过限定阈值的消息；
6)weblogic服务器日志：级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
7)weblogic domain日志：级别为ENERGENCY、ALERT、CRITICAL、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及级别为WARNING、NOTICE、INFO、TRACE，原因描述中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息；
8)应用程序日志：级别为FAILURE、ERROR的消息，在***非计划检修期间，状态为启动失败、服务关闭的消息，以及日志记录中包含ERROR、EXCEPTION、FAILURE、WARNING关键字的消息；
9)Oracle alert日志：在***非计划检修期间，日志记录中包含：状态为启动失败、服务关闭的消息，日志记录中包含ERROR、EXCEPTION、FAILURE和WARNING关键字的消息，日志记录中包含"ORA-数字"关键字的消息；
10)Oracle listener日志：RETURN CODE不为0的记录，RETURN MESSAGE信息包含WARNING、TNS-nn关键字的消息，以及在***非计划检修期间，监听启动失败、监听关闭的消息；
11)syslog日志：日志记录中包含ERROR、FAILURE和WARNING关键字的消息；
12)用户进程：根据用户进程名称和数量范围设定值，判断用户进程是否正常；
13)内存参数：根据设定阈值，判断total、used、free、shared、buffers、cached、-/+buffers/cache参数是否超过警戒值；
14)swap参数：根据设定阈值，判断Swap total、swap used和swap free参数是否超过警戒线值；
15)CPU参数：根据设定阈值，判断％us、％sy、％ni、％id、load average、users、total、running、sleeping、stopped、％hi、％si和％st参数是否超过警戒值；
16)磁盘参数：根据设定阈值，判断Mounted on、Use％、Used Avail和Size参数是否超过警戒值；
17)磁盘io参数：根据设定阈值，判断TPS、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn、avgqu-sz、await、svctm和％util参数是否超过警戒值；
18)网络参数：根据网卡设定，判断网卡工作模式、连通状态参数是否正确，根据包传输、响应时间参数判断网络连通是否稳定，并判断响应时间是否超过警戒值。
5.根据权利要求1所述的一种电力应用***故障实时分析诊断方法，其特征是，所述节点类型topology进行故障推导的过程包括以下步骤：
S3031)假设通过过滤类型topology获得某节点SERVER级别异常，节点类型topology通过故障语义识别规则获得Service Unavailable，判断为服务不可用故障，进入步骤2)；如果不能通过故障语义识别规则进行识别，则判定为未知故障，不能通过后续的规则推导，判断不同故障和参数之间关系，而是直接进入到步骤S304按照业务***进行汇聚信息；
S3032)对判定为服务不可用故障的信息通过推导规则表进行如下推导：
a)判断网络参数是否正常，如果不正常，将网络参数异常作为服务不可用故障的原因，如果正常，继续下一步；
b)判断用户进程名称和数量是否正常，如果为0或者超过最大值，则将用户进程异常作为服务不可用故障的原因，如果正常，继续下一步；
c)判断cpu参数，如果％sy在40％以上且％ni高于警戒值，或者％us在75％以上且％hi数量大，则存在***进程因磁盘io等待时间长或者用户进程堵塞造成服务不可用的可能性，结果交给步骤S304进行判断，继续后续推导；
d)判断swap参数，swap used逐渐增加，swap free逐步减少，说明***内存不足，存在大量页交换，存在造成服务不可用的可能性，结果交给步骤S304进行判断；
S3033)节点类型topology将同一个IP地址的故障逐一进行识别、判断、推导，将可以梳理出演进关系的故障记录到高速共享缓冲区，不能推导出演进关系的故障，分别独立记录到高速共享缓冲区，留待后续步骤使用。
6.根据权利要求5所述的一种电力应用***故障实时分析诊断方法，其特征是，所述业务类型topology进行故障推导的过程包括以下步骤：
S3041)获得步骤S3033)的推导结果，按照WebServer->AppServer->Database的逻辑顺序，判断故障位于那一个逻辑层次的节点上，首先判断位于WebServer层的故障，如果服务不可用出现在本层，则对步骤S3032)中的c)和d)推导进行确认，如果已经排除了网络和用户进程故障，也排除了AppServer层节点存在故障后，则c)和d)作为服务不可用的原因，否则，c)和d)作为WebServer层相应节点的性能问题单独保存到高速共享缓冲区；
S3042)判断AppServer层节点故障，如果WebServer层已经存在网络故障，则AppServer层节点故障作为独立故障记录到高速共享缓冲区，否则，则AppServer层节点故障可以作为WebServer层相应节点故障的原因；
S3043)判断database层节点故障，如果AppServer层节点存在网络故障，则database层节点故障作为独立故障记录到高速共享缓冲区，否则，database层节点故障作为AppServer层节点故障原因；
S3044)当不同业务***共享节点时，共享节点按照不同业务***中的节点，分别记录故障推导关系。
CN201510821162.6A 2015-11-23 2015-11-23 一种电力应用***故障实时分析诊断方法 Active CN105488610B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510821162.6A CN105488610B (zh) 2015-11-23 2015-11-23 一种电力应用***故障实时分析诊断方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510821162.6A CN105488610B (zh) 2015-11-23 2015-11-23 一种电力应用***故障实时分析诊断方法

Publications (2)

Publication Number Publication Date
CN105488610A CN105488610A (zh) 2016-04-13
CN105488610B true CN105488610B (zh) 2017-05-10

Family

ID=55675579

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510821162.6A Active CN105488610B (zh) 2015-11-23 2015-11-23 一种电力应用***故障实时分析诊断方法

Country Status (1)

Country Link
CN (1) CN105488610B (zh)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105956135A (zh) * 2016-05-12 2016-09-21 南京唯实科技有限公司 基于storm 的实时数据计算平台
CN106375113B (zh) * 2016-08-25 2020-01-17 新华三技术有限公司 一种分布式设备故障记录的方法、装置和***
CN107786897A (zh) * 2016-08-31 2018-03-09 南京中兴新软件有限责任公司 Iptv***故障定位方法及***
CN107562768A (zh) * 2016-09-14 2018-01-09 彩讯科技股份有限公司 一种数据处理过程动态回溯追踪方法
CN108073635B (zh) * 2016-11-18 2021-08-27 中国电力科学研究院有限公司 一种电力信息***数据场景加载的***及其加载方法
CN108696371B (zh) * 2017-04-06 2021-10-08 ***通信集团广东有限公司 网络故障确定方法及***
CN107168847A (zh) * 2017-04-21 2017-09-15 国家电网公司 一种支撑分布式架构的全链路应用监控方法与装置
CN107135086A (zh) * 2017-05-26 2017-09-05 努比亚技术有限公司 一种广播推送方法及设备、计算机可读存储介质
CN107391551B (zh) * 2017-06-06 2020-04-14 广东广业开元科技有限公司 一种基于数据挖掘的web业务数据分析方法及***
CN107547273B (zh) * 2017-08-18 2020-06-23 国网山东省电力公司信息通信公司 一种电力***虚拟实例高可用的保障方法及***
CN109426822B (zh) * 2017-08-25 2022-03-11 无锡市明大交通科技咨询有限公司 一种交通设施排查***及其排查方法
CN108010305B (zh) * 2017-12-14 2020-06-30 深圳市科陆电子科技股份有限公司 一种综合能源管理平台数据采集故障的自诊断方法
CN109302723B (zh) * 2017-12-20 2024-03-29 上海创远仪器技术股份有限公司 一种基于互联网的多节点实时无线电监测控制方法
CN108280019A (zh) * 2018-01-08 2018-07-13 郑州云海信息技术有限公司 一种评估服务器健康状态的方法
CN108092825A (zh) * 2018-01-17 2018-05-29 山东钢铁集团日照有限公司 一种跨网络的生产数据安全采集及设备故障诊断方法
CN108187337A (zh) * 2018-01-25 2018-06-22 北京云点联动科技发展有限公司 一种用于娃娃机的故障检测方法及设备
CN108537681B (zh) * 2018-03-06 2020-12-29 国网冀北电力有限公司 一种电网自动化调度***故障定位方法和装置
CN108521339B (zh) * 2018-03-13 2021-08-03 广州西麦科技股份有限公司 一种基于集群日志的反馈式节点故障处理方法及***
CN108491967A (zh) * 2018-03-14 2018-09-04 广东电网有限责任公司惠州供电局 一种适用于调度自动化主站故障自动预判方法
CN110401550A (zh) * 2018-04-24 2019-11-01 贵州白山云科技股份有限公司 客户异常的自动化诊断方法、装置、存储介质及计算设备
CN108809708A (zh) * 2018-06-04 2018-11-13 深圳众厉电力科技有限公司 一种电力通信网络节点故障检测***
CN109034521B (zh) * 2018-06-07 2021-11-16 国电南瑞科技股份有限公司 一种电网调度控制***的智能运维架构设计方法
CN109191103A (zh) * 2018-07-27 2019-01-11 阿里巴巴集团控股有限公司 一种数据梳理方法及装置
CN109450451B (zh) * 2018-10-19 2022-05-24 国网天津市电力公司电力科学研究院 一种波形回放的无缝拼接压缩处理方法和装置
CN109685399B (zh) * 2019-02-19 2022-09-09 贵州电网有限责任公司 电力***日志整合分析方法及***
CN109889527B (zh) * 2019-02-28 2021-06-22 中山市云经纪网络科技有限公司 一种基于大数据的网络安全防护***及其防护方法
CN109948157A (zh) * 2019-03-13 2019-06-28 日照职业技术学院 一种诗词收集和数据分析方法
CN110011872B (zh) * 2019-04-10 2020-12-01 海南航空控股股份有限公司 一种基于诊断消息的流式计算平台状态监控方法和装置
CN110636116B (zh) * 2019-08-29 2022-05-10 武汉烽火众智数字技术有限责任公司 一种多维数据采集的***及方法
CN110908964B (zh) * 2019-10-18 2023-08-18 平安科技（深圳）有限公司 分布式文件***的监控方法、装置、终端及存储介质
CN110969286B (zh) * 2019-11-01 2023-04-07 南京深度智控科技有限公司 基于物联网数据的建筑运行安全诊断与分析***及方法
CN112988432A (zh) * 2019-12-02 2021-06-18 上海宝信软件股份有限公司 使用诊断分析大盘定位故障方法、***及介质
CN110888850B (zh) * 2019-12-04 2023-07-21 国网山东省电力公司威海供电公司 一种基于电力物联网平台的数据质量检测方法
CN111338929A (zh) * 2019-12-05 2020-06-26 国网辽宁省电力有限公司信息通信分公司 一种业务应用***性能评测及其解析技术方法
CN111371623B (zh) * 2020-03-13 2023-02-28 杨磊 业务性能和安全的监测方法、装置、存储介质及电子设备
CN113535500A (zh) * 2020-04-10 2021-10-22 北京沃东天骏信息技术有限公司 一种业务监控的方法和装置
CN111639839B (zh) * 2020-05-14 2023-09-15 深圳供电局有限公司 一种基于微服务的电网故障的分析方法及***
CN112668159A (zh) * 2020-12-15 2021-04-16 交控科技股份有限公司 基于改进fmea***日志文件的故障排查方法和装置
CN112987696A (zh) * 2021-03-15 2021-06-18 国家电网有限公司 一种区域配电网设备管理平台及其运行方法
CN113466823B (zh) * 2021-08-11 2023-06-06 中国电子科技集团公司第三十八研究所 一种数字阵列模块大冗余度健康管理方法
CN113762928A (zh) * 2021-09-08 2021-12-07 广东电网有限责任公司 状态更新方法、装置、电子设备以及存储介质
CN113971003A (zh) * 2021-10-17 2022-01-25 中国船舶重工集团公司第七一六研究所 一种磁盘smart数据的在线采样装置与方法
CN113836044B (zh) * 2021-11-26 2022-03-15 华中科技大学 一种软件故障采集和分析的方法及***
CN117056110B (zh) * 2023-08-17 2024-02-23 北京优特捷信息技术有限公司 一种***故障排查方法、装置、电子设备及存储介质
CN117687873B (zh) * 2023-12-20 2024-04-30 中安华邦(北京)安全生产技术研究院股份有限公司 一种基于ai的安全信息构建方法及***

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200941169A (en) * 2008-03-20 2009-10-01 Nat Univ Tsing Hua Dynamic real-time stability monitoring system for precision equipment
CN104468191A (zh) * 2014-11-05 2015-03-25 国家电网公司 基于时间窗和网络模型的电力通信故障预警方法及***
CN104571099A (zh) * 2015-01-26 2015-04-29 北京国能日新***控制技术有限公司 基于理论计算和数据分析的光伏故障诊断***和诊断方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200941169A (en) * 2008-03-20 2009-10-01 Nat Univ Tsing Hua Dynamic real-time stability monitoring system for precision equipment
CN104468191A (zh) * 2014-11-05 2015-03-25 国家电网公司 基于时间窗和网络模型的电力通信故障预警方法及***
CN104571099A (zh) * 2015-01-26 2015-04-29 北京国能日新***控制技术有限公司 基于理论计算和数据分析的光伏故障诊断***和诊断方法

Also Published As

Publication number Publication date
CN105488610A (zh) 2016-04-13

Similar Documents

Publication Publication Date Title
CN105488610B (zh) 一种电力应用***故障实时分析诊断方法
CN107992398B (zh) 一种业务***的监控方法和监控***
US9672085B2 (en) Adaptive fault diagnosis
CN107729210B (zh) 分布式服务集群的异常诊断方法和装置
CN105426292B (zh) 一种游戏日志实时处理***及方法
CN107229556A (zh) 基于elastic组件的日志分析***
CN105159964B (zh) 一种日志监控方法及***
CN106407083B (zh) 故障检测方法及装置
CN107273267A (zh) 基于elastic组件的日志分析方法
CN110309130A (zh) 一种用于主机性能监控的方法及装置
US20200341868A1 (en) System and Method for Reactive Log Spooling
CN103401698B (zh) 用于服务器集群运算中对服务器状况报警的监控***
US8918345B2 (en) Network analysis system
US10652103B2 (en) System and method for handling events involving computing systems and networks using fabric monitoring system
CN109977089A (zh) 日志管理方法、装置、计算机设备及计算机可读存储介质
CN109460339B (zh) 日志的流式计算***
CN102567185B (zh) 一种应用服务器的监控方法
CN111858251B (zh) 一种基于大数据计算技术的数据安全审计方法及***
CN107544832A (zh) 一种虚拟机进程的监控方法、装置和***
CN104574219A (zh) 电网业务信息***运行工况的监测预警方法及***
CN107635003A (zh) ***日志的管理方法、装置及***
CN106789158A (zh) 一种云服务保险定损方法和***
CN111782486A (zh) 一种基于动态配置的告警实现方法及其***
CN114356499A (zh) Kubernetes集群告警根因分析方法及装置
CN111177193A (zh) 一种基于Flink的日志流式处理方法及***

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant