硕士学位论文
面向自主计算的带内故障检测系统
的研究与设计
RESEARCH AND DESIGN OF
IN-BAND FAULT DETECTION SYSTEM FOR AUTONOMIC COMPUTING
周健
哈尔滨工业大学
2012年6月
国内图书分类号：TP302.8 学校代码：10213 国际图书分类号：681.39 密级：公开
工程硕士学位论文
面向自主计算的带内故障检测系统
的研究与设计
硕士研究生：周健
导师：杨孝宗教授
申请学位：工程硕士
学科：计算机技术
所在单位：计算机科学与技术学院
答辩日期：2012年6月
授予学位单位：哈尔滨工业大学
Classified Index: TP302.8
U.D.C: 681.39
Dissertation for the Master Degree in Engineering
RESEARCH AND DESIGN OF
IN-BAND FAULT DETECTION SYSTEM FOR AUTONOMIC COMPUTING
Candidate：Zhou Jian
Supervisor：Prof. Yang Xiaozong
Academic Degree Applied for：Master of Engineering Speciality：Computer Technology Affiliation：School of Computer Science and
Technology
Date of Defence：June, 2012
Degree-Conferring-Institution：Harbin Institute of Technology
摘要
自主计算由IBM公司于2001年10月提出，旨在通过技术管理技术的手段来降低复杂性，提高系统可用性。故障检测是自主计算最基本、最核心的功能之一，带内故障检测面向一个独立的计算节点，检测系统运行于OS之上，检测过程包含了自主计算的监控和部分诊断功能。
本文就带内故障检测的覆盖率问题、有效性问题进行了研究，定义了针对计算单元的故障划分标准，主要解决了故障检测模型的建立和故障检测工具的实现两个问题。
故障检测模型主要解决故障对象的检测、动态配置、系统查询3方面问题，该模型将各种故障检测对象、检测过程、检测结果标准化，增加系统可配置型和灵活性。
在故障模型的指导下，实现了硬件层、内核数值型、内核非数值型、应用层四个层次的故障检测工具集。这四个工具对系统从上到下、从服务到操作系统OS再到硬件状态、从计算密集型到访存密集型再到IO密集型应用都有覆盖。
本文针对Linux操作系统进行结果验证，将故障检测结果与其它监控工具进行结果比对，同时模拟构造了各种故障情况并对回收结果进行分析。实验表明，本文所实现的故障检测工具集，基本上能够检测到测试对象发生时的各种异常情况，能够实时将检测结果发送给后续处理模块。
关键词：故障检测模型；带内故障检测；故障分类
Abstract
Autonomic computing was proposed in October 2001 by IBM,which was designed to reduce the complexity and improve the system usability by the means of techniques manage techniques. Fault detection is one of the most basic and core functions of autonomic computing,the in-band fault detection mainly turn towards independent compute nodes,the detection system runs above the OS,the detection process consists of monitoring and part of the diagnostic features which was defined in autonomic computing.
This paper do some research about the fault coverage and the detection validity of the in-band fault detection,define the fault classification criteria for computing unit.the paper try to solve the following two issues:building the general fault detection model;designing and implementing fault detection tools.
Fault detection model mainly try to solve fault detection,dynamic configuration and system queries interface of the object,This model standardize a variety of different detection obejects,detection processes and detection results so as to make the detection system more configurable and flexible.
Under the guidance of the fault detection model.This paper bring out a series of fault detection toolsets which including the hardware layer,the numerical kernel,the non-numeric kernel and the application layer.The four tools have full coverage of the system from top to bottom,from the services to the operating system and to the hardware status,from memory intesive application to compute-intensive application and then to IO-intensive application.
At last,this paper do some verification of the fault detection toolsets based on Linux operating system and compare the fault detection results with other monitoring tools,at the same time,the paper simulate various fault conditions and take analysis of the detection results.The experiments show that these fault detection toolsets could detect the corresponding situations when certern objects conk generally and could send the corresponding detection information to the subsequent processing modules.
Keywords: fault detection model，in-band fault detection，fault classification
目录
摘要........................................................................................................................ I ABSTRACT ............................................................................................................. II 第1章绪论. (1)
1.1课题背景 (1)
1.1.1 课题来源 (1)
1.1.2 自主计算及重要性 (1)
1.1.3 带内故障检测在自主计算中的意义 (2)
1.2国内外研究现状 (3)
1.2.1 带内故障检测概述 (3)
1.2.2 带内故障检测技术研究现状 (3)
1.3本文主要研究内容 (5)
1.4本文组织结构 (5)
第2章故障检测模型 (6)
2.1面向计算单元的故障划分标准 (6)
2.1.1 故障分类方法 (6)
2.1.2 面向计算单元的故障分类标准 (6)
2.1.3 面向计算单元的故障分类 (8)
2.2故障检测模型 (9)
2.2.1 故障检测模型需要满足的条件 (9)
2.2.2 故障检测模型 (10)
2.3通用故障检测系统设计方案 (11)
2.3.1 通用数据结构 (11)
2.3.2 通用故障检测过程 (12)
2.3.3 通用故障单元结构 (13)
2.3.4 通用故障消息结构 (14)
2.3.5 通用故障检测接口 (14)
2.4本章小结 (15)
第3章带内故障检测系统设计与实现 (16)
3.1核心服务类故障检测工具 (16)
3.1.1 故障检测对象 (17)
3.1.2 故障检测原理 (19)
3.2内核非数值型故障检测工具 (21)
3.2.1 故障检测对象 (21)
3.2.2 故障检测原理 (22)
3.3内核数值型故障检测工具 (36)
3.3.1 整体介绍 (36)
3.3.2 cpu故障检测工具 (39)
3.3.3 内存故障检测工具 (41)
3.3.4 磁盘故障检测工具 (43)
3.3.5 网络故障检测工具 (45)
3.4硬件层故障检测工具 (46)
3.4.1 故障检测对象 (46)
3.4.2 监控信息采集 (47)
3.5本章小结 (47)
第4章带内故障检测系统评测实验 (48)
4.1实验环境 (48)
4.2交互接口整体框架 (48)
4.2.1 交互接口整体框架 (48)
4.2.2 日志反馈记录 (49)
4.2.3 故障配置接口 (50)
4.2.4 故障单元库 (50)
4.3基于动态配置的通用模型验证实验 (50)
4.3.1 动态配置对象对故障单元库接口的影响 (50)
4.3.2 动态配置对象对日志反馈记录接口的影响 (51)
4.3.3 动态配置故障单元对日志反馈记录接口的影响 (51)
4.4基于故障注入的故障检测实验 (52)
4.4.1 应用层故障注入实验 (52)
4.4.2 内存泄露故障注入实验 (54)
4.4.3 可插拔设备空间不足故障注入实验 (56)
4.5本章小结 (57)
结论 (58)
参考文献 (59)
哈尔滨工业大学学位论文原创性声明 (63)
哈尔滨工业大学硕士学位论文使用授权书 (63)
致谢 (64)
第1章绪论
1.1课题背景
1.1.1课题来源
目前，互联网应用需求正朝横向和纵深两个方向迅速发展：一方面互联网服务正在面向服务、工业、医疗、农林、教育、军工等各个方向快速推进，极大扩宽了应用领域；另一方面，据国务院2010年6月8日发表的《中国互联网状况》白皮书显示，截至2009年年底中国已拥有网民3.84亿[1]，而据中国互联网络中心显示，截至2011年12月，互联网用户达到5.13亿，并将很快突破6亿。需求的发展
促使服务器系统规模日益扩大和难于管理，同时促使软件规模日益膨胀与复杂化，整体系统的可靠性与可用性问题已成为系统应用的重要障碍。
当前，针对服务器系统高可靠性解决方案主要分为两类[2]:一类以牺牲空间
为主，主要采用各个层次的冗余技术，通过硬件、软件冗余技术来实现；另一类牺牲时间为主，主要采用各种软件算法通过复杂的计算，在故障发生前进行故障处理，以期避免故障。
本课题来源于十二五项目，主要研究计算结点故障基本特性，构建故障检测模型，设计实现系统多层次、多目标的故障检测工具集，以便能及时、精确的检测系统已发生或将发生的各类故障并报警。
1.1.2自主计算及重要性
一直以来，随着计算机性能的大幅提升，软件复杂性危机[3]成为制约IT系统可持续发展的新的瓶颈。来自IDC的资料显示，互联网企业需要花费大约高出成本4到20倍的费用用于后续3年的系统维护[4]，即使如此，仍无法避免系统宕机。2010年6月30日，Amazon云计算中心宕机，持续时间超过3小时，每分钟损失约5万美金；2010年9月26日，知名社交网站FaceBook宕机2小时之久；2011年5月26日，Skype发生宕机事故，波及全球用户；而同年11月21日，RIM公司持续3天的宕机事件差点让公司面临灭顶之灾。在这些宕机事件中，人为因素大约占到51%，远高于软件故障的34%和硬件故障的25%。
自主计算由IBM在2001年提出[5]，该技术通过将自主神经系统的“自主”概念模式化、结构化来实现“技术管理技术”这一理念[6]，其主要实施过程包括系统监控、状态诊断、计划制订、策略执行四个环节，通过这些措施的执行来隐藏系统的复杂性、提高系统的可靠性、可用性、容错能力和可扩展性。
1.1.3带内故障检测在自主计算中的意义
传统的带内、带外管理是依据管理通道是否独立于常规的数据通道来划分的。在本文中，带内故障检测基于操作系统之上实现，只有在计算单元开机且操作系统运行正常情况下才能有效工作。
传统意义上，故障检测仅用于判断系统是否出现故障。本文的故障检测在确定故障的同时给出故障发生的一些位置、特征等信息[2]，包含故障检测和故障定位两个过程，等价于自主计算的系统监控和状态诊断过程。
服务器系统是由一个个计算单元以类似刀片形式聚合在一起形成的，各个计算单元是独立的个体，每个计算单元正常运行是整个系统正常服务的必要不充分条件，因此基于计算单元的带内故障检测是维持整体系统可靠性服务的基础。服务器的自主计算核心结构如图1-1所示。
图1-1自主计算核心结构
系统执行逻辑如下：带内故障检测系统获取监控信息并进行故障分析，将故障信息规格化后通过本地故障管理模块LFM发送到全局故障管理模块GFM；GFM是自主计算的核心单元，其由一系列模块和故障管理知识库、规则库形成，其中诊断器根据LFM传来的系统故障状态和行为信息，确定故障发生的类型、故障源、故障可能的影响范围；分析器根据故障检测、系统执行状态等信息，结合系统故障知识库信息，进行推理而识别出有关状态的发展趋势，实现对未来更大系统故障或系统失效的检测；计划器根据分析和诊断结果，利用系统故障规则库，规划将要执行故障处理行为；执行器执行相应的指令流并调度LFM中的故障管理模块完成故障后处理操作；学习器在系统运行过程中对故障处理过程及系统故障特征进行分析，形成新的故障知识或规则，添加到库中。从该系统结构图
中可以看到，带内故障检测系统是整个自主计算最开始、也是最重要的环节之一，如果故障覆盖率过低、检测错误或者检测无效，将直接影响后续的分析、修复过程。
1.2国内外研究现状
1.2.1带内故障检测概述
带内故障检测针对的对象不是大规模分布式系统软件，而是计算单元。针对计算单元的故障检测主要涉及到单元硬件工作状态、系统cpu、内存、磁盘、网络等资源信息使用情况、操作系统稳健性、系统关键服务的可靠性等方面。一方面，检测对象越详细、检测历史数据越多，检测算法越精确，越能更好的对系统故障进行预测；另一方面对象越详细、历史数据越多，往往要消耗大量的计算和存储资源，降低系统的使用效率，同时检测算法要根据不同的系统对象进行建模、验证。
就描述计算单元状态的数据类型而言，主要分为数值型时间序列和状态型时间序列以及事件型数据三种。数值型时间序列指将检测对象在不同时刻采集到的数值按照时间递增顺序排列而成的数值序列，数值采集时间间隔一般为固定值；状态型时间序列指将检测对象在不同时刻采集到的状态值按照时间递增顺序排列而成的状态序列，这里的状态集是有限的，这种形式只能检测到已发生故障，无法进行故障预测；事件型数据主要基于系统日志实现，用于对系统关键服务的可靠性进行预测，其本身需要syslogd服务的正常运行。
1.2.2带内故障检测技术研究现状
带内故障检测数据采集样本主要分为数值型时间序列和事件型数据两种，目前国内外对这两种类型的数据都进行了充分的研究，在不同方面取得了很多成果。
1.2.2.1 数值型时间序列故障检测方法
最简单的方法是基于阈值检验，即对于某个特定故障检测对象，可以设定若干个阈值，当状态超过阈值时，触发报警并将错误信息进行本地记录。该方法广泛应用于路由器拥塞控制、内存换入换出等应用中。这种方式的优点是简单、直观，当把阈值设定为临近最大压力时，可用于故障预测工作。缺点也很明显：阈值很难得到最优化，影响对象的某些参数因子变化没有规律，因此阈值检验无法准确的进行故障预测[2]，而且容易引发抖动现象。这种方法适合于衡量系统利用率[7]问题以及阈值长度能准确确定[8]的情况下,比如Sally Floyd[9]等人在1993年提出了用于路由器拥塞控制的RED算法，但该算法对其参数maxp的设置很敏感，另外路由器平均队列长度会随着连接数目增大而逐渐增大[10]。文献[11-12]提出自配置的ARED算法，该方法通过网络负载动态调整max p，但是该方法引入了更多的参数；Lakshman[13]等人提出SRED算法，该方法通过统计网络中流的
个数来来调整数据包丢弃概率；Feng Wuchang[14]等人提出BLUE算法，该算法通过链路空闲和缓冲溢出的状况来调整数据包丢弃概率。李金东等人[15]提出了针对RED算法进行非线性平滑的算法；章淼[16]等人对网络端到端拥塞控制发展过程进行了总体概括。
目前针对数值型时间序列数据主要有两种研究策略[2]，时间序列分析法和模式识别分类法。时间序列分析的本质是承认动态数据之间的相关性或依赖关系，并用数学模型来描述这种相关性来实现预测[17]。时间序列分析又分为时域分析[18-19]频域分析[20-21]，前者在时间域上进行分析研究，后者对时间序列做傅里叶变化在频域上做频谱分析。目前时域分析方法愈来愈显示出其重要性和科学性。常用的平稳时间序列模型[22]有自回归模型AR、滑动平均模型MA和自回归滑动平均模型ARMA[23],Hood C J[24]利用自回归模型进行网络流量故障检测。而对于非平稳时间序列，可以通过减去趋势项或者利用序列差分去除单位根转为平稳时间序列[25],Hood C J[26]将非平稳时间序列分割为多个近似平稳的片段，然后利用AR 模型分析，林树宽[27]等人将非平稳时间序列通过经验模式分解为若干个平稳序列本征模式分量，各个分量分别建立预测模型进行预测，之后利用支持向量回归对这些预测模型对进行非线性组合，得到非平稳非线性的时间序列预测模型，孙钦东[28]等人利用自适应自回归模型AAR直接对非平稳时间序列进行分析。
模式识别分类法主要考虑各个检测数值之间的距离特征，通过距离特征对状态进行分类，从而完成故障检测。Klaus Julisch[29]使用聚类分析法得到系统正常工作的状态集，HAMERL Y[30]等人使用贝叶斯分类器完成硬盘故障的检测与诊断过程。
1.2.2.2 事件型数据故障检测方法
系统日志主要用于记录系统发生的硬件和软件错误，系统管理者可以用日志信息来监控系统健康状态、分析系统故障、计划系统维修策略。但是日志具有很高的冗余性，需要对日志记录进行过滤，相关研究有时序模型法、小波分析法、基于规则的分类法、贝叶斯网络模型法、POMDP技术等[31-32]，时序模型法适合预测电信相关的问题[33]，M.F.Buckley[34]等人使用带有启发式的时域模型法来预测计算机系统健康状况，J.R.Quinlan[35]通过递归的将事例空间分割为等价来进行故障预测，D.Heckerman[36]等人通过采用动态信任网络来实现故障根源隔离，该研究已应用于微软操作系统中。Ramendra K[37]通过对拥有350个节点的集群为期1年的日志信息采集，使用动态贝叶斯网络[38]分析事件之间的局部依赖概率并结合时域分析法将系统故障预测用于大规模集群系统中。
1.3本文主要研究内容
虽然针对带内故障检测已经有很多成型的算法，但是目前这些方法只局限于系统某一方面且有很强的局限性，很难扩展，也没有比较成熟的针对计算单元而设计的故障检测模型。本文实现了以下内容：
首先建立适用于带内故障检测的故障检测模型，该模型基于郭长国等人提出的故障监控框架[39]实现。这里通过修改，去掉了平台相关性等部分，同时添加了故障库、系统接口、检测历史信息等模块，加入带内特征和故障检测、故障信息查询、用户动态配置等新元素。
对带内故障检测进行模块细分，系统是由硬件、操作系统核心、应用等组合在一起的整体，为了有效、精确的刻画系统当前健康状况，检测对象需要达到尽可能高的故障覆盖率，同时又必须在系统发生故障前或故障发生时能快速、准确的定位故障，经过对计算单元进行分析，按照耦合度，将故障对象层次化，同层故障模块化，并从整体上形成包含四个独立的故障检测工具的工具集。
在对系统故障进行整体划分后，各个故障模块包含多个故障对象，每个故障对象包括很多故障单元，每个故障单元包含特定的故障检测算法，对上述问题进一步细化，从而形成针对计算单元完整的故障检测系统。
以通用故障检测框架为标准，分别编码实现硬件故障检测工具、内核核心线程故障检测工具、内核数值型故障检测工具、应用系统核心服务故障检测工具等四个独立的工具，其中内核数值型故障检测工具包括cpu故障检测工具、内存故障检测工具、磁盘故障检测工具、网络故障检测工具四个子工具，实现覆盖带内各个层面的故障检测工具链。
在实现基础上，对各个工具进行实验验证，确保针对上述故障检测对象的故障都能被识别，并且确保系统管理员可以获取当前所有的检测历史信息，并能进行故障检测的动态配置。
1.4本文组织结构
第1章绪论部分简述课题来源、目的与意义，分析了带内故障检测的研究现状和本文研究内容。
第2章介绍带内故障检测的划分标准，系统整体检测思路，在此基础上详细介绍带内故障检测通用模型，并给出通用检测模型各部分的详细设计方案。
第3章介绍涵盖硬件层、内核层、应用层的各个故障检测工具的详细检测内容、详细检测原理、详细检测算法、详细检测过程。
第4章完成各个检测工具的实验验证工作。
第2章故障检测模型
2.1面向计算单元的故障划分标准
带内故障检测是基于Linux操作系统之上面向计算单元的检测过程，要实现动态检测过程并且使检测的结果更精确、更全面、更有意义，首先要解决计算单元的故障覆盖率问题，这需要面向计算单元建立一个通用的故障分类标准。
2.1.1故障分类方法
研究对象按照不同标准往往有多种故障分类方法，实际应用中，一般有以下几种故障分类方法：
（1）面向特定软件
这种情况主要面向大规模复杂软件，此时硬件和操作系统本身具有很强的可靠性和容错性能，系统瓶颈和故障主要集中在应用软件上。这种情况下，不同的软件往往有针对性的检测方法，比如朱显杰针对apache服务提出使用决策树进行系统瓶颈检测和基于统计学习实现性能预测[40]。
（2）面向故障模型
故障虽然千变万化，但并非毫无规律，通过对大量的故障进行统计、分析，朱荣、徐拾义等人针对科学计算程序提出计算性、分支型、循环型、功能型、死锁型、测试型共6中故障模型[41]，富浩[42]在其博士论文中针对C语言开发的大型开源软件RTEMS、Apache、PostgreSQL进行bug分析，共形成了内存相关、计算相关、输入输出相关、控制流、竞争类等9种故障模型[52]。
（3）面向部署时机
按照软件测试代码嵌入到软件功能代码的时机，故障可分为静态检测类故障和动态检测类故障。静态检测类故障通过直接分析软件源码来发现其中的错误，杨宇、张健等人比较深入地研究了程序静态分析技术[43-44],叶俊民等将静态分析和故障树方法结合进行故障检测[45]，当前比较成熟的静态分析工具有PREfix[46]、BANE[47]、Metal[48]、ESP[49]、SLAM[50]、Splint[51]等。动态检测类故障是面向软件运行时故障，主要由于软件运行结果和预期不一致造成，主要通过故障检测和故障预测获得，需要利用神经网络[42]、随机过程分析[28]、机器学习[40]、模式识别[2]等多学科知识。
2.1.2面向计算单元的故障分类标准
上面的3种分类方法以不同的视角针对故障或故障检测策略进行分类，不同分类方法中有很多交叉的故障检测方法。本文对计算单元进行综合分析，提出一种基于系统层次的动态故障检测分类标准，如图2-1所示。
图2-1通用故障检测分类
之所以提出这种分类标准，有以下考虑：
（1）计算单元的复杂性
本文的研究对象是计算单元，一个由独立的硬件、固件、操作系统、应用程序集构成的可运行集合，不同的构成单元故障特性很不一样，无法从整体上进行故障建模。
（2）故障模型缺陷
计算单元不同层次表现出的故障现象大不一样，故障模型法需要对所有这些故障进行统计、分类，该方法往往需要结合程序源代码进行分析，而且由于故障表征和故障根源具有一对多映射关系，故障定位难以实现。
（3）故障现象缺陷
故障现象指根据系统当前的运行状态，确定其可能出现的问题，显然这种方式实现比较模糊，且同样定位比较困难，比如某一节点执行切片任务缓慢，可能由于硬件、网络、磁盘、内存、操作系统等多方面造成，检测最终还得定位到这些对象的检测，根据已有故障现象来确定故障原因是没有必要的，通过分级故障检测可以实现上述目的。
采用基于系统层次的动态故障检测分类标准，主要基于下面考虑：
（1）动态故障检测必要性
静态故障检测需要对程序源代码进行分析，工作量大、实现困难，而且容易引入其他错误，这种方式只适合与特定软件，而且系统有些部分无法给予静态故障检测实现。相反，动态故障检测，根据对系统对象的运行时状态、日志记录等利用一些数学方法进行统计、分析，对系统进行故障检测，这种方式实现效率高、且系统运行和系统检测分离，很好的隔离检测对系统本身运行的影响，而且可以对故障检测方法进行动态配置。
（2）故障扩散理论
Algirdas Avizienis等人提出了涉及系统可靠性的3个基本概念：故障、错误、失效[61]并对其传播过程进行了深入的总结，一般而言故障是由编码阶段考虑不
充分或者硬件老化造成，一般处于潜伏状态。当故障激活后产生部件错误，部件错误会通过部件间接口向上层逐渐传递，最终导致系统的失效。故障扩散具有典型的层次特征，由硬件层逐步向操作系统内核、应用程序传递，不会出现相反的传递过程。
（3）层次性数据
实际上，操作系统将系统运行状态信息按照层次、按照对象存储于sysfs文件系统不同的目录文件中，比如，对于硬件温度信息，在/sys/devices/目录下，
对于内核日志，位于/var/log/kern.log文件中，对于apache服务日志信息，则位
于/var/log/httpd/err_log文件中等等。
（4）可实现性
基于系统层次进行动态故障检测，故障分类清晰、故障定位明确、系统可扩展性强、易于动态配置、用户接口良好，是一种比较理想的实现方法。
2.1.3面向计算单元的故障分类
按照系统层次的分类标准，系统整体可分为应用层故障分类、内核层故障分类、硬件层故障分类3个故障子类，如图2-2所示。
图2-2基于系统层次的故障分类
应用层故障子类按照服务的重要性又分为：用户配置服务类故障集、系统关键服务类故障集、系统核心服务类故障集。用户配置服务类主要是系统管理者在该计算节点上自定义的相关服务集，这类服务具有计算单元相关性，不同的计算单元服务可能不一样；系统关键服务类主要涉及该计算节点上运行的系统服务集，这些服务若出现问题将使企业遭受难以估计的损失；系统核心服务类是系统关键服务类和用户配置服务类的基础，只有系统核心服务类正常工作，计算单元才能提供最基本的功能供上层应用使用。
内核层故障子类按照故障检测结果表现形式的不同可分为两类：内核数值型故障、内核非数值型故障，其中内核数值型故障主要以数值来描述检测结果，其按照检测对象的不同又分为cpu故障类、内存故障类、磁盘故障类、网络故障类
四个故障子类；内核非数值型故障主要以离散的状态值或者事件结果来描述检测结果，主要涉及内核核心线程的故障检测。
硬件层故障子类主要面向硬件故障，通过读取硬件传感器的实时监控值，从而获取电压、温度、风扇转速等相关数据，然后进行分析、处理。
2.2故障检测模型
2.2.1故障检测模型需要满足的条件
面向计算单元的带内故障检测系统要满足以下特性：
（1）层次性
计算单元各个层次的相对独立性和整体复杂性决定了带内故障检测系统必需实现为具有层次性的一系列故障检测工具的工具集。这种各工具之间的松散组合方式一方面使得故障检测的动态扩展、配置非常简单；另一方面降低各个故障检测模块之间的相互影响，一个检测模块的失效不会导致整个检测系统的失效。
（2）高内聚和低耦合
带内故障检测系统是基于多层次的故障检测工具集，根据软件设计原理，各检测子模块应该只完成单一的任务，实现模块内高内聚，同时各子模块之间接口尽量简单、一致，实现模块间低耦合。
（3）可扩展性
计算单元会在运行的过程可能部署新的应用、停止旧服务或者修改阈值，带内故障检测系统要随时适应这种变化并能给系统管理员提供各种接口以便灵活控制故障检测过程。这需要考虑两方面：提供通用接口让系统管理员将新的故障检测策略添加到故障检测工具中或将失效的故障检测策略从故障检测工具中去除，这需要静态修改源程序实现，且新修改在下次修改前一直有效；提供通用接口让系统管理员在故障检测工具运行过程中对部分故障检测策略进行动态更新，这种情况无需修改源程序实现，但是下次重启时，这种修改将失效。
（4）系统接口
带内故障检测系统应该提供简单、一致的系统接口，供系统管理员适时查看当前检测数据，了解系统健康状况。系统接口包含三部分：各故障检测对象的历史检测信息，该信息除了用于对将来趋势进行分析外，可供系统管理者查看以便手动进行系统控制；检测到的故障描述信息，该信息用以描述系统某一检测模块发生的故障，系统管理员可以根据这些历史故障信息进行主动的故障策略执行；当前进行故障检测的对象及其相关属性集合，该信息方便系统管理者对当前故障检测情况进行全局把握，为下一步配置提供参考。
2.2.2故障检测模型
郭长国等人在针对40余款故障监控软件进行分析的基础上提出一种运行时软件监控模型[47]，该模型由监控对象、监控实施策略、执行关系、运行时监控、平台依赖性5个部分组成，以系统需求作为输入，经过动态监测过程输出监控结果。本文针对自己的需求在该模型基础上实现了面向计算单元的带内故障检测模型，整体结构如图2-3所示。
图2-3故障检测模型
该模型由六部分组成：故障检测工具、故障检测对象、故障检测算法、历史信息存储、故障库、动态配置接口，各个部分描述如下：
（1）故障检测工具
从整体来看，带内故障检测系统由六个故障检测工具组成，从应用层到硬件层分别为用户配置服务类故障检测工具、系统关键服务类故障检测工具、系统核心服务类故障检测工具、内核数值型故障检测工具、内核线程类故障检测工具、硬件层故障检测工具，每个故障检测工具都是基于故障检测模型独立实现，各自是独立不相关的。
（2）故障检测对象
故障检测对象基于故障检测工具实现，故障检测工具首先将系统整体进行粗粒度划分，故障检测对象然后针对该故障类进行细粒度的划分，故障检测对象可以按照服务进行划分、也可以按照故障类的自然组成进行划分。
（3）故障检测算法
一般而言，每个故障检测对象具有多种不同的故障表征方式，称为故障单元。因此，每个故障检测对象往往具有多个故障单元，不同的故障单元又往往需要不
同的检测方法，故障检测算法的实现首先需要对故障对象的运行状态进行详细的分析，总结出可能的故障单元，然后针对该故障单元，设计特定的故障检测算法。
（4）历史信息存储
历史信息存储部分主要存储周期性故障监控的结果信息和检测到的故障记录信息，每个故障检测对象对应一个故障监控结果文件，一个故障检测工具对应一个故障记录文件，该工具之下的所有故障检测对象共享该文件。考虑到效率和安全的问题，故障监控结果只保留最近的若干条记录在循环内存区中，对于故障记录结果，最近若干条记录保存在内存缓冲区中，其余信息则同步到磁盘文件中长期保存。
（5）故障库
故障库由6个部分组成：所有的故障对象、当前检测的故障对象、所有的故障算法、当前检测的故障算法、所有的故障单元、当前正在检测的故障单元。
其中所有的故障对象、所有的故障算法、所有的故障单元用以描述故障检测工具能检测的所有的相关信息，在故障检测工具编译阶段确定，运行时不再发生变化。当前正在检测的故障对象、当前检测的故障算法、当前正在检测的故障单元用以描述故障检测工具正在进行检测的相关信息，这部分在系统运行阶段可以由管理者进行动态配置，管理员可以根据上述信息进行故障的精细化控制。
（6）动态配置接口
动态配置接口用以增加故障检测的可控性和灵活性，系统管理者可以通过动态配置接口对故障对象、故障检测算法、故障库等进行动态配置，配置后的结果将直接影响后续的故障检测过程，有很强的时效性。
2.3通用故障检测系统设计方案
2.3.1通用数据结构
系统各故障检测工具均基于故障检测模型实现，为了满足该模型所具有通用性、动态可扩展性、简易性，需要实现一个通用的、高可扩展性的结构体集，一种有效地实现方式如图2-4所示。
图2-4通用数据结构
该集合包含3个部分，从上到下介绍如下：
（1）对象地址
故障检测工具是由一个个故障对象组成的集合，每个对象都具有一个对象地址结构，该结构包含对象名称、对象地址、指向下一个对象的指针。每个故障检测周期中，检测线程遍历对象地址单链表结构，对每个检测对象，调用其相应的检测算法。每个单链表最后都包含一个称为log的对象，该对象不是检测对象，用于存储和显示该故障检测工具检测到故障历史记录。
（2）通用故障检测对象
隶属于同一个故障检测工具的检测对象整体上往往具有相似的特征，将这些特征进行抽象从而形成通用检测对象类object_struct，每个对象作为一个类实例，对象的私有部分可以通过通用类的最后变量进行定制。
（3）通用故障检测方法
每个故障检测对象拥有若干不同的故障检测算法，每个算法拥有不同的可动态控制的阈值，检测对象及每个检测算法均提供一个动态启动、停止接口，这些信息包含在通用故障检测方法类method_struct中，通过该结构，可以实现检测对象各检测算法的动态启停、检测阈值的动态控制。
2.3.2通用故障检测过程
通用故障检测过程由两个线程组成：周期性故障检测线程、日志回写线程，这两个线程共同实现故障的检测过程和故障记录信息的磁盘存储过程。各线程工作原理如下：
（1）周期性故障检测线程
该线程主要实现针对检测对象集的周期性故障检测过程，其执行过程如图2-5所示。
图2-5周期性故障检测线程执行流程
线程执行周期默认为30秒，其执行时遍历故障检测对象单链表，对每个检测对象，依次按序调用相应的故障检测算法集中的每个检测算法进行检测，检测结果保存到该对象的历史记录中，默认日志记录的条数为10，以循环缓冲区方
式进行覆盖操作。如果某一个检测算法检测出了故障，将故障以故障描述的形式存储到log内存对象中，并通过usb接口发送到LFM中，进行故障报警。
（2）日志回写线程
如果每次检测到故障时都将故障描述信息存储到磁盘文件中，一方面可能导致频繁的磁盘文件操作，尤其是文件比较大时每次读写具有很大的延迟；另一方面其实管理者最关心的是最近发生的故障记录信息，过多的信息会对管理者造成干扰。而如果每次将故障描述信息保存到内存中，将会损耗大量的系统内存，影响其他程序的运行。在本文设计中，同时使用内存故障记录和磁盘故障文件。默认情况下，内存故障记录的记录数最大为30条，当内存故障记录达到一定标准时进行磁盘文件同步操作。本文采用日志回写线程来解决同步问题，该线程具有两个状态，如图2-6所示。
图2-6日志回写线程
其工作原理如下：该线程一般处于不可中断睡眠状态，以30min为一个周期，如果中途周期性故障检测线程在某次检测过程中检测到故障并将其记录到log内存日志时，发现日志记录超过总记录的1/2，则会主动唤醒日志回写线程，该线程被唤醒后，将内存日志记录中的所有故障描述回写到磁盘文件中，然后重新进入睡眠状态。
2.3.3通用故障单元结构
故障单元是故障检测对象故障表征的结构化描述，故障单元由编译阶段确定并且在运行过程中会实时反馈管理员对故障检测规则所实施的动态修改，管理者可以通过故障单元了解每个故障检测对象的所有故障表征的详细描述。故障单元由六部分组成，具体格式如下所示：<带内故障标志，故障位置，故障对象，故障单元表征，故障检测算法，故障单元阈值>,其中带内故障标志为固定值SYSTEM，表示检测过程基于系统内部；故障位置描述故障所在的系统层次,由APPLICATION、KERNELNONUMBER、KERNELNUMBER、HARDWARE组成；故障对象描述发生故障的检测对象；故障单元表征用以详细描述故障信息；故障检测算法描述某类故障对应的故障检测函数；故障单元阈值定义故障检测时的阈值。