CN113778788A - 一种操作系统故障监控装置及方法 - Google Patents

一种操作系统故障监控装置及方法 Download PDF

Info

Publication number
CN113778788A
CN113778788A CN202110928546.3A CN202110928546A CN113778788A CN 113778788 A CN113778788 A CN 113778788A CN 202110928546 A CN202110928546 A CN 202110928546A CN 113778788 A CN113778788 A CN 113778788A
Authority
CN
China
Prior art keywords
monitoring
layer
fault
operating system
module
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.)
Withdrawn
Application number
CN202110928546.3A
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.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology 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 Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202110928546.3A priority Critical patent/CN113778788A/zh
Publication of CN113778788A publication Critical patent/CN113778788A/zh
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3051Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开一种操作系统故障监控装置及方法,监控装置配置于待监控操作系统,包括监控层、数据层和展示层;监控层用于在操作系统内核态配置多个监控模块,监控操作系统状态和操作系统所在设备的硬件状态;数据层用于将监控层所监控的数据存储于数据库;展示层用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警。本发明能够同时监控硬件与操作系统本身,不易被卸载,不依赖于网络,可稳定可靠的对操作系统进行故障监控。

Description

一种操作系统故障监控装置及方法
技术领域
本发明涉及操作系统故障监控领域,具体涉及一种操作系统故障监控装置及方法。
背景技术
操作系统的主要工作模式是建立在硬件之上,能够灵活的调度硬件的功能与工作状态,为上层应用软件提供了一个平台。基于该平台,上层应用软件得以屏蔽不同硬件平台的差异,实现应用软件的正常工作。因此,在现在计算机领域,操作系统的稳定性与可靠性是必须值得注意与保证的。操作系统与应用软件不同,操作系统不需要也无法进行快速变更,操作系统的主要要求是稳定性与可靠性。在可靠的操作系统之上,能够充分的调动硬件的性能。
针对操作系统的稳定性与可靠性,目前存在的主要解决方案为用户态的操作系统监控或硬件环境的硬件监控。以目前流行的开源操作系统运维监控工具Zabbix为例,描述目前的主要解决方案。
Zabbix.Zabbix作为开源的操作系统的监控工具,采用单服务端多客户端的方式进行操作系统的状态监控与信息采集。Zabbix的监控模式主要为探针模式,在需要被监控的操作系统安装探针(agent)。该探针的实现较为轻量,主要是采集操作系统的工作状态,例如/proc下的内存状态与cpu状态,采集到基本信息后发送至服务端,该操作仅限于用户态。服务端与多个操作系统探针进行交互,服务端采集到信息后,将数据保存至数据库。用户登录服务端的页面后,可以查看到服务端收集的操作系统工作状态信息,并对服务器的工作状态进行判断。服务端能够采集的全部信息基于探针的功能,探针通过http协议向服务端发送采集到的监控信息。
Zabbix能够实现同时监控多台服务,实现一台服务器多台被监控客户端的工作模式。该架构的主要优势在于,能够同时监控多台主机。但是缺点也较为明显。主要的问题在于:
1)如果服务器的硬件发生异常,Zabbix无法检测到硬件的工作状态。因此只能体现在服务器的软件工作状态与数据上。例如磁盘发生故障后,无法判断磁盘发生了怎样的故障。只能看到操作系统的IO出现了或高或低的异常。从而通过人工的判断。判断是否是磁盘出现了问题还是操作系统的文件系统的出现了问题。
2)探针的工作模式容易被拔出。例如,服务器被黑客攻陷,攻陷后的服务器直接卸载掉探针后监控便失效。在服务器端只能看到该服务器已下线,无法记录是否为人为主动的拔出或者操作系统工作异常。
3)探针的工作模式依赖于网络。因为单纯的探针是无法正常的工作的,探针需要与服务端进行交互,服务端收集到信息后才能对故障信息进行检测与评估。因此在非网络环境下的主机是无法进行监控与调试的。
4)探针模块固定,功能不可变。一个固定的探针只能监控固定的功能。例如探针想要停止监控某些模块,只能在逻辑上对某些模块进行停止。新增监控的时候也无法实现对探针不存在的功能进行停止,只能采用升级探针的模式对监控的内容进行升级。
发明内容
为解决上述问题,本发明提供一种操作系统故障监控装置及方法,能够同时监控硬件与操作系统本身,不易被卸载,不依赖于网络,可稳定可靠的对操作系统进行故障监控。
第一方面,本发明的技术方案提供一种操作系统故障监控装置,配置于待监控操作系统,包括,
监控层:用于在操作系统内核态配置多个监控模块,监控操作系统状态和操作系统所在设备的硬件状态;
数据层:用于将监控层所监控的数据存储于数据库;
展示层:用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警。
进一步地,在操作系统内核态配置的监控模块包括,
主板故障监控模块:用于监控主板状态,获取主板故障信息;
CPU故障监控模块:用于监控CPU的缓存状态,获取CPU故障信息;
内存故障监控模块:用于监控内存的工作状态,获取内存故障信息;
磁盘故障监控模块:用于监控磁盘状态,获取磁盘故障信息;
内核死锁故障监控模块:用于监控操作系统内核死锁状态,获取内核死锁故障信息;
XFS文件系统故障监控模块:用于监控XFS文件系统的索引节点信息、内核态的目录项信息及超级块信息,获取XFS文件系统故障信息;
PCIE插槽故障监控模块:用于监控PCIE插槽状态,获取PCIE插槽故障信息;
网卡网络故障监控模块:用于监控网络协议栈工作状态,获取网卡网络故障信息。
进一步地,
主板故障监控模块通过采集BMC芯片的状态监控主板状态;
CPU故障监控模块通过机器检查工具监控CPU的缓存状态;
内存故障监控模块通过机器检查工具监控内存的工作状态;
磁盘故障监控模块通过硬盘检测工具监控磁盘状态;
内核死锁故障监控模块通过操作系统的死锁检测机制监控操作系统内核死锁状态;
PCIE插槽故障监控模块通过BMC芯片监控PCIE插槽状态。
进一步地,监控层包括内核层、用户态层和代理层;
内核层将监控模块以驱动模块文件方式组织;用户态层和代理层将监控模块以动态链接库方式组织;
内核层监控模块获取到故障信息时,将故障信息发送至用户态层,用户态层将故障信息发送至代理层和数据层,代理层将故障信息转义为可读日志,并将日志进行打印。
进一步地,展示层包括服务后端和用户前端;
用户前端用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警;服务后端为用户前端提供展示服务支持。
进一步地,展示层的服务后端从数据层的数据库获取监控层所监控的数据。
进一步地,展示层的用户前端用于将监控层的监控模块以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警,包括:
根据监控层所监控的数据判断故障类型;根据故障类型进行打分;根据最终打分结果展示告警类型;
根据监控层所监控的数据统计故障次数,以图表形式展示故障次数。
第二方面,本发明的技术方案提供一种操作系统故障监控方法,包括以下步骤:
启动监控层,数据层自启动并建立数据库文件与表结构;
启动展示层,在展示层选择需加载的监控模块,并基于选择结果向监控层发送加载监控模块指令;
监控层根据加载监控模块指令加载相应监控模块进行监控;
当监控到故障信息时,监控层的内核层将故障信息发送至监控层的用户态层,用户态层将故障信息发送至数据层和监控层的代理层;
代理层将故障信息转义为可读日志,并将日志进行打印;
数据层将故障信息存储于数据库;
展示层从数据层的数据库中查询到故障信息进行展示并告警。
进一步地,监控层根据加载监控模块指令加载相应监控模块,具体为:
监控层根据加载监控模块指令加载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
进一步地,该方法还包括以下步骤:
在展示层选择需卸载的监控模块,并基于选择结果向监控层发送卸载监控模块指令;
监控层根据卸载监控模块指令卸载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
本发明提供的一种操作系统故障监控装置及方法,相对于现有技术,具有以下有益效果:
(1)能够同时进行硬件与操作系统的监控。不仅仅是对硬件或软件进行监控,而是同时对可能影响操作系统稳定性或可靠性的软件、硬件问题同时进行监控,从而在整个操作系统的软硬件结合的情况下,对整个操作系统的运行状态进行评估,能够更加具备深度的对操作系统的软硬件整体稳定性的性能进行评估。
(2)不使用探针模式,而是使用在内核态嵌入内核模块的方式,对操作系统的状态进行监控。作为操作系统的内核模块,具备一定的稳定性。如果想要卸载内核模块,则需要具备以下几个条件:1)识别到本监控管理系统的内核插件。因为内核插件本身具有很多种,因此不容易被轻易识别。2)在内核模块创建的proc文件系统下输入卸载命令,例如具体路径为/proc/sys/unload路径,在该路径下将字符“1”输入后才可以执行卸载本系统的操作。3)内核模块有多个,互相监控。如果发现有一个内核模块被强行卸载,则会由其他的模块模型进行唤醒操作。从而保证模块不会轻易被卸载。
(3)监控的模式不依赖于网络,采取“本地采集数据,本地加工数据,本地维护数据”的方式。该方式不再依赖网络模块,不需要再向外进行网络的传播过程,因此与网络环境无关。与网络环境无关的模式主要有以下几个优点:1)安全性。与网络模式相关就需要考虑网络传输过程中的安全性,如果数据包被中间劫持,则有可能对主机安全会造成破坏。2)普适性。不是所有的网络环境都具备局域网络,因此在部分主机没有网络环境的情况下,依旧能正常的进行监控。3)消耗更低。操作系统的监控功能不应该影响主要的操作系统功能。例如操作系统正在作为一个网络服务器使用对外提供服务时,如果过多的用于监控的网络带宽,就会抢占正常的网络服务器的网络吞吐资源等。因此,不依赖于网络的本监控系统能够在单机模式下良好的工作。
(4)可变的可增减的监控方式。区别于固定结构的探针模式,本方案在监控操作系统状态时,能够根据配置将不同的模块嵌入至本故障监控装置。本故障监控装置总计分为八个模块,分别为:主板故障、CPU故障、内存故障、磁盘故障、内核死锁故障、XFS文件系统故障、PCIE插槽故障与网卡网络故障。每个模块之间互相不存在依赖,相互独立,因此单个模块可以单独存在并进行监控。例如:本机只对内核死锁故障进行监控,其他的模块不关心,可以卸载掉其他的模块。单独安装内核死锁故障模块,即可完成单个故障的监控与监听。
附图说明
为了更清楚的说明本申请实施例或现有技术的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例一提供的一种操作系统故障监控装置架构示意框图;
图2为本发明实施例二提供的一种操作系统故障监控方法流程示意图;
图3为本发明实施例三提供的一种终端的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面结合附图和具体实施方式对本申请作进一步的详细说明。显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
实施例一
如图1所示为本实施例提供的一种操作系统故障监控装置架构示意框图,该装置配置于监控操作系统,包括监控层、数据层和展示层,能够同时监控硬件与操作系统本身,不易被卸载,不依赖于网络,可稳定可靠的对操作系统进行故障监控。
监控层:用于在操作系统内核态配置多个监控模块,监控操作系统状态和操作系统所在设备的硬件状态;
数据层:用于将监控层所监控的数据存储于数据库;
展示层:用于将监控层的监控模块以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警。
其中,监控层通过多个监控模块监控操作系统状态和操作系统所在设备的硬件状态,在操作系统或硬件故障时,获取到故障信息,将故障信息传输到数据层存储于数据库,展示层将故障信息进行展示。需要说明的是,展示层所获取的故障信息从数据库中获取,展示层与监控层相互不耦合、相互独立,因此可相互剥离,不产生依赖。另外需要说明的是,传输至数据层的监控数据为监测到到故障数据,展示层所展示的监控数据也是监测到的故障数据。
监控层包括内核层、用户态层和代理层,数据自底向上流转。本实施例中,内核层、用户态层和代理层这三个层中,每一层又存在八个监控模块,这八个监控模块分别是主板故障监控模块、CPU故障监控模块、内存故障监控模块、磁盘故障监控模块、内核死锁故障监控模块、XFS文件系统故障监控模块、PCIE插槽故障监控模块和网卡网络故障监控模块。通过这八个监控模块实现操作系统状态和操作系统所在设备的硬件状态的整体监控。
在内核层,将监控模块以驱动模块文件(即ko文件)方式组织;在用户态层和代理层,将监控模块以动态链接库(即so文件)方式组织。内核层负责在操作系统内核态监控操作系统状态和操作系统所在设备的硬件状态,并采集故障信息,在采集到故障信息后将故障信息发送至用户态层。具体地,内核层通过内核态提供的netlink交互方式与用户态层进行交互,通过netlink提供的广播方式向用户态发送采集到的故障信息。
用户态层接收到故障信息(由对应的so文件采集到)后,将故障信息发送至代理层和数据层。代理层收到故障信息后,将故障信息进行转义,转义为可读的日志形式,并将该日志进行打印,可打印到系统的固定位置。
数据层接收到故障信息后,将故障信息进行识别并保存到数据库中。具体实施时,可采用SQLite3的数据库的保存方式,并使用sqlchiper的方式对SQLite的数据库文件进行加密,加密后的数据无法被常规的方案读取,只能由本系统进行读取,因此确保的数据的可靠性。需要说明的是,数据库支队数据进行增加,等待展示层的查询功能。
以下对八个监控模块进行详细说明。
1)主板故障监控模块:用于监控主板状态,获取主板故障信息。
主板故障监控模块通过采集BMC(基板管理控制器)芯片的状态监控主板状态,BMC芯片状态为主机的硬件信息维护状态。
2)CPU故障监控模块:用于监控CPU的缓存状态,获取CPU故障信息。
CPU故障监控模块通过机器检查工具监控CPU的缓存状态,其中机器检查工具具体可为MCE(Machine Check Exception,简称MCE)工具,MCE工具时X86架构下的工具,可检测和报告硬件(机器)的错误机制。
3)内存故障监控模块:用于监控内存的工作状态,获取内存故障信息。
与CPU故障监控模块类似,依赖于机器检查工具监控内存的工作状态,其中机器检查工具具体可为MCE工具。
内存的工作状态主要包括slab分配器、伙伴系统、大页使用情况信息等状态信息。
4)磁盘故障监控模块:用于监控磁盘状态,获取磁盘故障信息。
磁盘故障监控模块通过硬盘检测工具监控磁盘状态,其中硬盘检测工具具体为smartctl工具。
5)内核死锁故障监控模块:用于监控操作系统内核死锁状态,获取内核死锁故障信息。
内核死锁故障监控模块通过操作系统的死锁检测机制(即lockdep机制)监控操作系统内核死锁状态。
6)XFS文件系统(一种高性能的日志文件系统)故障监控模块:用于监控XFS文件系统的索引节点信息(即inode信息)、内核态的目录项信息(即dentry信息)及超级块信息(即super_block信息),获取XFS文件系统故障信息。
7)PCIE插槽故障监控模块:用于监控PCIE插槽状态,获取PCIE插槽故障信息。
与主板故障监控模块类似,通过BMC芯片监控PCIE插槽状态。
8)网卡网络故障监控模块:用于监控网络协议栈工作状态,获取网卡网络故障信息。
其中,网络协议栈工作状态包括硬件驱动的状态、数据包的流转、TCP建立成功连接的比率等。
以上各个监控模块实现整体监控,但需要说明的是,各个监控模块之间不存在依赖、相互独立,因此单个监控模块可以单独存在并进行监控,也可以单独卸载某个监控模块。展示层展示监控层的监控模块信息,对于选择哪些监控模块进行监控或卸载,管理人员可在展示层对监控模块信息进行操作,进而向监控层发送相关指令。
本实施例的展示层包括服务后端和用户前端,用户前端用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警;服务后端为用户前端提供展示服务支持。具体实施时,展示层的实现方案可为Java+SpringBoot+Vue的实现方案。其中服务后端使用的Java+SpringBoot,用户前端使用的Vue的解决方案。即用户前端使用vue框架对数据进行展示,服务后端使用Java+SpringBoot的方式进行服务支持。
用户前端的展示分为两个部分,一个部分是监控层的监控模块信息,可供管理人员选择相应监控模块进行加载或卸载,另一个部分是监控层所监控的数据,即监测到的故障信息。
对于监控模块的加载,在展示层选择需加载的监控模块,并基于选择结果向监控层发送加载监控模块指令,监控层根据加载监控模块指令加载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。具体地,管理人员在用户前端选择相应监控模块信息选择启用,用户前端Vue架构调用服务后端接口,服务后端调用命令fmadm loaddeadlock,命令通过消息队列的方式(Linux System V)向监控层发送加载监控模块的命令。监控层接收到加载命令后,可首先查看监控模块是否已加载,如果未加载则再进行加载操作。
对于监控模块的卸载,在展示层选择需要卸载的监控模块,并基于选择结果向监控层发送卸载监控模块指令,监控层根据卸载监控模块指令卸载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。具体地,管理人员在用户前端选择相应监控模块信息选择不启用,用户前端Vue架构调用服务后端接口,服务后端调用命令fmadmunload deadlock,命令通过消息队列的方式(Linux System V)向监控层发送加载监控模块的命令。
用户前端的展示另一个部分是监控层所监控的数据,即监测到的故障信息,这一部分数据均来自数据层的数据库。在不需要对数据进行具体的监控时,数据流到数据层的数据库截止,无需继续进行流转。而需要对数据进行控制或流转时,则需要启动展示层的相关服务。启动后,展示层读取数据库中的内容。展示层与监控层相互不耦合、相互独立,因此可以相互剥离,不产生依赖。
用户前端对故障信息的展示有两种方式,分别为健康状态评分以及故障发生频次统计。一方面,根据监控层所监控的数据判断故障类型,根据故障类型进行打分,根据最终打分结果展示告警类型;另一方面,根据监控层所监控的数据统计故障次数,以图表形式展示故障次数。
具体实施时,健康状态评分为一个整体的操作系统的健康状态的评分系统。例如满分为100分。如果是100分的状态,则代表系统整体健康。优秀分为90分,代表系统虽然有一些警告,但是不影响系统的整体使用,无需进行处理。警告分为80,证明系统正在非正常工作,整体不具备危险性,但是需要进行初步的排查。80分以下为危险状态。证明系统当前工作状态及其不正常,需要尽快进行修复,否则可能会带来较为严重的后果。故障根据不同的故障类型,分为提示、警告、严重、灾难四个等级。系统会根据当前系统存在的所有故障进行统计。满分为100分,存在提示不扣分,存在一条警告扣一分,存在一条严重扣10分,存在一条灾难扣20分。扣至0为止。例如当前系统存在一条提示、一条警告、一条严重和一条灾难,则当前系统的评分为100-1-10-20=69分,证明当前系统存在较为严重的问题,需要及时修复。
对于故障发生频次统计,可采用饼图与列表的方式,可以对历史的主机故障进行查询。饼图以发生的故障模块进行划分。例如磁盘为2条故障,cpu为一条,则为三分之一和三分之二的饼图构成。并且能够通过时间(日期维度)进行查询。
实施例二
本实施例二提供一种操作系统故障监控方法,基于实施例一的操作系统故障监控装置实现。
如图2所示为本实施例二提供的一种操作系统故障监控方法流程示意图,包括以下步骤。
S1,启动监控层,数据层自启动并建立数据库文件与表结构。
S2,启动展示层,在展示层选择需加载的监控模块,并基于选择结果向监控层发送加载监控模块指令。
需要说明的是,操作系统故障监控装置安装到系统之后,系统具备所有监控模块的二进制文件,但还没有被加载到整个系统。需要管理人员在展示层选择需加载的监控模块之后,监控层执行加载进行监控。
S3,监控层根据加载监控模块指令加载相应监控模块进行监控。
S4,当监控到故障信息时,监控层的内核层将故障信息发送至监控层的用户态层,用户态层将故障信息发送至数据层和监控层的代理层。
S5,代理层将故障信息转义为可读日志,并将日志进行打印。
例如将deadlock.spin转义为内核自旋锁死锁状态异常。
S6,数据层将故障信息存储于数据库。
S7,展示层从数据层的数据库中查询到故障信息进行展示并告警。
展示层根据故障信息进行打分,根据打分结果告警,另外绘制故障次数图表。
本实施例中,步骤S3监控层根据加载监控模块指令加载相应监控模块进行监控,具体为:
监控层根据加载监控模块指令加载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
另外,本实施例还提供监控模块卸载的方法流程,包括以下步骤:
步骤一,在展示层选择需卸载的监控模块,并基于选择结果向监控层发送卸载监控模块指令;
步骤二,监控层根据卸载监控模块指令卸载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
与加载监控模块类型,同样需要在展示层选择需卸载的监控模块,之后监控层卸载相应文件。
本实施例的操作系统故障监控方法基于前述的操作系统故障监控装置实现,因此该方法中的具体实施方式可见前文中的操作系统故障监控装置的实施例部分,所以,其具体实施方式可以参照相应的各个部分实施例的描述,在此不再展开介绍。
实施例三
图3为本发明实施例提供的一种终端装置300的结构示意图,该终端装置300可以用于执行本发明实施例二提供的操作系统故障监控方法。
其中,该终端装置300可以包括:处理器310、存储器320及通信单元330。这些组件通过一条或多条总线进行通信,本领域技术人员可以理解,图中示出的服务器的结构并不构成对本发明的限定,它既可以是总线形结构,也可以是星型结构,还可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
其中,该存储器320可以用于存储处理器310的执行指令,存储器320可以由任何类型的易失性或非易失性存储终端或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。当存储器320中的执行指令由处理器310执行时,使得终端300能够执行以下上述方法实施例中的部分或全部步骤。
处理器310为存储终端的控制中心,利用各种接口和线路连接整个电子终端的各个部分,通过运行或执行存储在存储器320内的软件程序和/或模块,以及调用存储在存储器内的数据,以执行电子终端的各种功能和/或处理数据。所述处理器可以由集成电路(Integrated Circuit,简称IC) 组成,例如可以由单颗封装的IC 所组成,也可以由连接多颗相同功能或不同功能的封装IC而组成。举例来说,处理器310可以仅包括中央处理器(Central Processing Unit,简称CPU)。在本发明实施方式中,CPU可以是单运算核心,也可以包括多运算核心。
通信单元330,用于建立通信信道,从而使所述存储终端可以与其它终端进行通信。接收其他终端发送的用户数据或者向其他终端发送用户数据。
实施例四
本发明还提供一种计算机存储介质,其中,该计算机存储介质可存储有程序,该程序执行时可包括本发明提供的实施例二中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(英文:read-only memory,简称:ROM)或随机存储记忆体(英文:random access memory,简称:RAM)等。
本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中如U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质,包括若干指令用以使得一台计算机终端(可以是个人计算机,服务器,或者第二终端、网络终端等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
以上公开的仅为本发明的优选实施方式,但本发明并非局限于此,任何本领域的技术人员能思之的没有创造性的变化,以及在不脱离本发明原理前提下所作的若干改进和润饰,都应落在本发明的保护范围内。

Claims (10)

1.一种操作系统故障监控装置,其特征在于,配置于待监控操作系统,包括,
监控层:用于在操作系统内核态配置多个监控模块,监控操作系统状态和操作系统所在设备的硬件状态;
数据层:用于将监控层所监控的数据存储于数据库;
展示层:用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警。
2.根据权利要求1所述的操作系统故障监控装置,其特征在于,在操作系统内核态配置的多个监控模块包括,
主板故障监控模块:用于监控主板状态,获取主板故障信息;
CPU故障监控模块:用于监控CPU的缓存状态,获取CPU故障信息;
内存故障监控模块:用于监控内存的工作状态,获取内存故障信息;
磁盘故障监控模块:用于监控磁盘状态,获取磁盘故障信息;
内核死锁故障监控模块:用于监控操作系统内核死锁状态,获取内核死锁故障信息;
XFS文件系统故障监控模块:用于监控XFS文件系统的索引节点信息、内核态的目录项信息及超级块信息,获取XFS文件系统故障信息;
PCIE插槽故障监控模块:用于监控PCIE插槽状态,获取PCIE插槽故障信息;
网卡网络故障监控模块:用于监控网络协议栈工作状态,获取网卡网络故障信息。
3.根据权利要求2所述的操作系统故障监控装置,其特征在于,
主板故障监控模块通过采集BMC芯片的状态监控主板状态;
CPU故障监控模块通过机器检查工具监控CPU的缓存状态;
内存故障监控模块通过机器检查工具监控内存的工作状态;
磁盘故障监控模块通过硬盘检测工具监控磁盘状态;
内核死锁故障监控模块通过操作系统的死锁检测机制监控操作系统内核死锁状态;
PCIE插槽故障监控模块通过BMC芯片监控PCIE插槽状态。
4.根据权利要求3所述的操作系统故障监控装置,其特征在于,监控层包括内核层、用户态层和代理层;
内核层将监控模块以驱动模块文件方式组织;用户态层和代理层将监控模块以动态链接库方式组织;
内核层监控模块获取到故障信息时,将故障信息发送至用户态层,用户态层将故障信息发送至代理层和数据层,代理层将故障信息转义为可读日志,并将日志进行打印。
5.根据权利要求4所述的操作系统故障监控装置,其特征在于,展示层包括服务后端和用户前端;
用户前端用于将监控层的监控模块信息以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警;服务后端为用户前端提供展示服务支持。
6.根据权利要求5所述的操作系统故障监控装置,其特征在于,展示层的服务后端从数据层的数据库获取监控层所监控的数据。
7.根据权利要求6所述的操作系统故障监控装置,其特征在于,展示层的用户前端用于将监控层的监控模块以及监控层所监控的数据进行展示,并根据监控层所监控的数据进行告警,包括:
根据监控层所监控的数据判断故障类型;根据故障类型进行打分;根据最终打分结果展示告警类型;
根据监控层所监控的数据统计故障次数,以图表形式展示故障次数。
8.一种操作系统故障监控方法,其特征在于,包括以下步骤:
启动监控层,数据层自启动并建立数据库文件与表结构;
启动展示层,在展示层选择需加载的监控模块,并基于选择结果向监控层发送加载监控模块指令;
监控层根据加载监控模块指令加载相应监控模块进行监控;
当监控到故障信息时,监控层的内核层将故障信息发送至监控层的用户态层,用户态层将故障信息发送至数据层和监控层的代理层;
代理层将故障信息转义为可读日志,并将日志进行打印;
数据层将故障信息存储于数据库;
展示层从数据层的数据库中查询到故障信息进行展示并告警。
9.根据权利要求8所述的操作系统故障监控方法,其特征在于,监控层根据加载监控模块指令加载相应监控模块,具体为:
监控层根据加载监控模块指令加载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
10.根据权利要求9所述的操作系统故障监控方法,其特征在于,该方法还包括以下步骤:
在展示层选择需卸载的监控模块,并基于选择结果向监控层发送卸载监控模块指令;
监控层根据卸载监控模块指令卸载相应监控模块的内核层驱动模块文件以及用户态层和代理层的动态链接库。
CN202110928546.3A 2021-08-13 2021-08-13 一种操作系统故障监控装置及方法 Withdrawn CN113778788A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110928546.3A CN113778788A (zh) 2021-08-13 2021-08-13 一种操作系统故障监控装置及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110928546.3A CN113778788A (zh) 2021-08-13 2021-08-13 一种操作系统故障监控装置及方法

Publications (1)

Publication Number Publication Date
CN113778788A true CN113778788A (zh) 2021-12-10

Family

ID=78837615

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110928546.3A Withdrawn CN113778788A (zh) 2021-08-13 2021-08-13 一种操作系统故障监控装置及方法

Country Status (1)

Country Link
CN (1) CN113778788A (zh)

Similar Documents

Publication Publication Date Title
US8713350B2 (en) Handling errors in a data processing system
US9720757B2 (en) Securing crash dump files
EP2510439B1 (en) Managing errors in a data processing system
US7756048B2 (en) Method and apparatus for customizable surveillance of network interfaces
US20110004791A1 (en) Server apparatus, fault detection method of server apparatus, and fault detection program of server apparatus
US7574620B2 (en) Method for operating an arrangement of a plurality of computers in the event of a computer failure
US20140122931A1 (en) Performing diagnostic tests in a data center
US11157373B2 (en) Prioritized transfer of failure event log data
KR101712172B1 (ko) 컴퓨터 장애 증상의 사전 진단 및 분석 복구 시스템 및 방법
WO2018095107A1 (zh) 一种bios程序的异常处理方法及装置
US6973412B2 (en) Method and apparatus involving a hierarchy of field replaceable units containing stored data
GB2398405A (en) Consolidating data regarding a hierarchy of field replaceable units containing stored data
CN114116276A (zh) Bmc挂死自恢复方法、系统、终端及存储介质
JP2003173272A (ja) 情報処理システム,情報処理装置及び保守センタ
US9411666B2 (en) Anticipatory protection of critical jobs in a computing system
CN117453036A (zh) 调整服务器中的设备的功耗的方法、系统及装置
KR102526368B1 (ko) 멀티벤더를 지원하는 서버 관리 시스템
CN113778788A (zh) 一种操作系统故障监控装置及方法
US20060031521A1 (en) Method for early failure detection in a server system and a computer system utilizing the same
CN112231170B (zh) 一种数据交互卡监管方法、系统、终端及存储介质
CN113608939A (zh) 性能测试中服务器启动计时方法、装置、终端及存储介质
US7676682B2 (en) Lightweight management and high availability controller
US7305497B2 (en) Performing resource analysis on one or more cards of a computer system wherein a plurality of severity levels are assigned based on a predetermined criteria
CN116701036A (zh) 一种bmc系统自动检测修复方法及装置
EP1777620A2 (en) Method for incorporating new device in information processing apparatus, information processing apparatus, program and computer readable information recording medium

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
WW01 Invention patent application withdrawn after publication
WW01 Invention patent application withdrawn after publication

Application publication date: 20211210