CN109936479A

CN109936479A - 基于差分检测的控制平面故障诊断系统及其实现方法

Info

Publication number: CN109936479A
Application number: CN201910204272.6A
Authority: CN
Inventors: 陈焰; 于银菠; 李星; 卜凯; 杨剑锋; 冷雪
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2019-03-18
Filing date: 2019-03-18
Publication date: 2019-06-25
Anticipated expiration: 2039-03-18
Also published as: CN109936479B

Abstract

本发明公开了一种差分检测的控制平面故障诊断系统及其实现方法。本发明包括数据采集模块、在线监控模块、离线故障诊断模块和网络事件重放引擎。通过在线监控模块和数据采集模块，获取控制器内部的代码调用、状态变化信息，构建上下文感知的系统行为模型；当前系统无异常时，提取系统行为模型存入参考库中，作为参考模型；当系统发现异常时，根据故障的症状找到发生故障的系统行为模型以及对应的参考模型；随后从上向下地对其进行差分比对，找出异常节点；然后在异常节点处进行静态分析，在代码层面找出故障发生的根源，在模拟环境中通过网络事件重放引擎确认之后，作为故障诊断报告，提交给管理员。本发明能够对故障根源进行定位，且适用性强。

Description

基于差分检测的控制平面故障诊断系统及其实现方法

技术领域

本发明属于计算机互联网领域，具体内容涉及一种软件定义网络中的基于差分检测的控制平面故障诊断系统及其实现方法。

背景技术

软件定义网络(SDN)是一种新型的网络架构，相比于传统七层网络架构，SDN核心的设计在于将控制平面与转发平面分离，将网络自上而下分为应用层、控制层及转发层。网络的所有配置及管理均由控制器集中处理，而转发层的设备仅负责高效转发流量。SDN中网络的集中控制极大地简化了网络管理员的工作，灵活可编程性为上层应用开发提供了广阔空间。

SDN控制器是复杂的多模块的分布式软件系统，由于SDN通过控制平面和转发平面的分离将网络的复杂性都提取到了控制平面，SDN控制器具有复杂的软件架构和事务处理流程，这使得它非常容易出现软件bug、逻辑错误和各种异常情况。尽管控制器的每个稳定版本发布前都经过了一系列复杂的测试，在实际的生产环境中，软件bug和异常还是不可避免的。

SDN网络中，控制器处于极度重要的核心位置，控制平面的软件错误会对整个网络的正常工作造成严重的影响。其中，除了转发层的故障主要来自于交换机中的硬件和位于交换机中的软件agent外，其他故障多来自控制平面。当前的控制平面中不仅存在SDN控制器，也集成了许多SDN应用平面的agent，架构和逻辑更加复杂，容易出现各种软件错误，影响网络的正常功能。

目前，SDN的主要应用场景是数据中心，运营商和云服务领域也在努力的研究、利用和融合SDN的优势。数据中心、运营商对网络服务的质量要求非常高，极其重视网络的可靠性。在这种场景下，极小的软件bug也可能会造成非常严重的后果。当控制器软件平台出现问题时，由于目前控制平面的关键数据收集、异常检测、识别和定位机制并不完善，使用目前的技术进行诊断是困难的。当前对SDN控制器等复杂的多模块分布式软件系统的故障识别和诊断大多通过人工分析大量系统日志的方法来发现并定位问题，然而，对系统日志进行诊断存在数据量大，理解和分析困难的问题，甚至有的错误并不能在日志中得到体现。根据一项研究[1]，一般来说，软件开发人员大约花费一半的时间(49％)进行故障诊断和调试，诊断难以触发的bug需要更多的时间，而且70％的已报告的并发bug需要数天到数月才能被修复。产业界的实际情况也是如此。对于开源的SDN控制器，目前的故障诊断方式依赖于它们开源社区的贡献者，用户发现和提出故障，开发者需要远程地重现故障，理解并修复故障。这使得故障的生命周期不可控，解决的时间较长。如OpenDaylight中75％的故障需要一个月以上的时间来诊断和修复。

学术界对SDN中的故障诊断方面有一定的研究，但都不能很好的解决上述问题。STS[2]使用黑盒测试的方法排查SDN控制器中的故障，并输出一组最小的能够触发故障的外部事件(e.g.,link failures)的输入序列(MCS)。它通过利用HSA实现网络常量检测来检测网络中的常量冲突，然后通过重放日志文件中的记录的外部事件还原出该冲突，并利用增量调试删减无关外部事件，生成最小输入序列。STS可以用于排查出控制器中一些已知(e.g.,Floodlight failover,ONOS Master Election)和未知(e.g.,POX PrematurePacketIn,ONOS database locking,NOX discovery loop,POX Migration Blackhole)的故障。然而，STS诊断效率很低，利用增量调试的方式找出MCS需要几个甚至十几个小时；生成的MCS作为可触发故障的事件序列可以用来描述故障，但是不能够描述出故障的根本原因，仍需要开发者进一步分析；而且，它的使用场景为测试环境，不能及时处理真实生产环境中出现的问题。JURY[3]也是一个使用黑盒测试的诊断工具，主要目标是检测出SDN控制器集群中不同控制器之间的行为差异。它通过输入相同的外部事件，验证各个控制器之间是否具有一致的输出行为，能够发现如ONOS database locking,master election,Undesirable FLOW_MOD等故障。但是JURY针对的目标问题有限，而且也不能指出具体的故障根源。一些研究方案[4-6]使用形式化的方式(如Model checking、SAT solver、SymbolicExecution等)来验证网络策略或者抽象的代码模型的正确性。然而他们依赖手动或者静态分析来对网络策略和代码进行建模，这通常需要较高的时间开销，容易出错，并且难以处理网络行为的动态变化和网络软件的频繁更新。

综上所述，在SDN中缺少可以在实际生产环境中有效诊断控制平面软件故障和异常的机制。相关的故障诊断技术虽能有效指出部分存在的问题，但是无法进行故障根源的定位，指出故障发生的具体环节，使用的场景和针对的问题也缺少通用性。因此，本发明要解决的问题就是设计一个高效的控制平面故障诊断系统，实现对SDN控制平面软件错误导致的实际网络问题的高效的诊断和相应故障根源的精确定位。

发明内容

本发明的目的是针对现有技术的不足，提供一种差分检测的控制平面故障诊断系统及其实现方法。

本发明解决其技术问题所采用的技术方案如下：

基于差分检测的控制平面故障诊断系统，包括数据采集模块、在线监控模块、离线故障诊断模块和网络事件重放引擎，具体模块描述如下：

数据采集模块：负责监测SDN控制平面的行为，记录系统可见的执行信息；能够动态加载到控制器上而不需要对控制器的代码进行修改，进行低开销的高效的动态数据采集；

在线监控模块：在生产环境中对系统状态进行动态监测，收集来自数据采集模块的数据，从中构造系统行为模型；并将正常状态下的系统行为模型作为参考模型，用于与对应的异常行为模型进行差分检测，进行故障诊断；

离线故障诊断模块：根据故障的症状找到发生故障的系统行为模型以及对应的参考模型，随后进行差分检测和根因分析，生成故障诊断报告；

网络事件重放引擎：基于代码的网络事件重放引擎，负责仿真拓扑结构，模拟数据平面的网络设备和应用平面中发送消息的网络应用，根据输入的重放策略生成相应的网络拓扑和产生特定的消息序列；通过调整消息的类型和组成序列，重现出SDN网络异常，辅助异常诊断算法进行异常诊断和定位；

首先通过在线监控模块，利用在控制平面中部署的数据采集模块，获取控制器内部的代码调用、状态变化信息，构建上下文感知的系统行为模型；

当前系统无异常时，提取系统行为模型存入参考库中，作为参考模型；当系统发现异常时，根据故障的症状找到发生故障的系统行为模型以及对应的参考模型；随后从上向下地对其进行差分比对，找出异常节点；然后在异常节点处进行静态分析，在代码层面找出故障发生的根源，在模拟环境中通过网络事件重放引擎确认之后，作为故障诊断报告，提交给管理员。

基于差分检测的控制平面故障诊断系统的实现方法，包括如下步骤：

步骤1、基于字节码插桩的数据监测和收集机制；

步骤2、上下文感知的系统行为模型构建机制；

步骤3、基于差分检测的故障诊断算法。

与现有技术相比，本发明优点有以下几点显著的优势：

1)本发明能够实现对生产环境中，由SDN控制平面软件错误导致的实际网络问题的高效诊断和相应故障根源的精确定位。

2)本发明设计了基于字节码插桩的数据监测和收集机制，提供了简洁的动态插桩机制，能够灵活地部署SDN系统行为跟踪策略，并能够获取动态的SDN控制平面外部输入事件所引发的内部调用。

3)本发明设计了上下文感知的系统行为模型构建机制，为收集到的SDN系统行为数据建立了上下文感知的行为模型，能够准确地推断出在不同的上下文环境中系统的行为信息。

4)本发明设计了基于差分检测的故障诊断算法，为SDN中的故障症状提供了形式化的表达方式，可以便捷地输入故障症状，通过差分检测机制，对于发生的故障提供故障诊断报告，为开发者快速地了解故障的原因提供充足的信息。

5)为实现软件定义网络中基于调用树的控制平面故障诊断系统，本发明设计了其所需要的具体实施细节，包括数据采集模块，在线监控模块，离线故障诊断模块以及网络事件重放引擎的设计方案。

综上所述，本发明能够对故障根源进行定位。通过比较正常情况和异常情况下系统内部的系统行为模型，能够准确定位出故障的根源，实现代码级别的故障诊断。本发明可用于生产环境，目标问题具有通用性。经过对主流控制器平台OpenDaylight汇总Bug的社区OpenDaylight Bugzilla进行的调研，OpenDaylight核心项目中约88％的软件异常会引起内部调用路径的改变，因此，本技术方案理论上可以对绝大多数的SDN控制平面软件故障进行诊断和定位。本发明能够提供细粒度的SDN控制平面内部运行视图。在控制器的字节码上进行插桩，可以灵活地动态改变插桩粒度，结合故障重放引擎，可以获得多粒度的SDN控制平面内部运行视图，对系统内部的运行过程有完整全面的了解。本发明适用性强，且不需要修改控制器源代码。基于字节码的插桩方式避免了对SDN控制器源代码的修改，而且这种插桩方式和与生产环境解耦的网络模拟和重放机制适用于对各类SDN控制器平台(如基于Java的OpenDaylight、ONOS，基于Python的Ryu)的异常诊断，只需要应用不同语言对应的字节码插桩工具即可。

附图说明

图1系统结构图；

图2数据监测和收集机制原理图；

图3插桩规则示意图；

图4控制器任务的调用行为示例图；

图5异构的跟踪图；

图6三种类型的转换函数示意图；

图7模型合并示意图；

图8差分检测示意图。

具体实施方式

本发明为了实现对SDN网络控制平面的故障诊断，需要获得SDN控制平面系统运行时的精确可见性，对于从数据平面和应用平面传递来的内外部事件和消息，SDN控制器会产生一系列的过程调用和处理过程，本发明设计通过定义调系统行为模型来表示控制平面内部的处理流程。当异常出现时，相关的系统行为模型会体现触发异常的相关事件和关键调用过程信息，这些信息可以用来进行故障的识别、诊断和进一步的根因定位。

本发明的架构如图1所示，涉及到两种环境。一方面，在实际生产环境中的控制平面中部署数据采集模块，监视和收集真实的内部执行路径、异常信息和相关真实网络事件；另一方面，在轻量级的模拟环境中重现异常发生的生产环境，通过网络重放引擎实现对SDN应用平面和数据平面的模拟，生成对应的网络事件。这两种环境的结合使用既能保证诊断数据的真实性也能确保诊断结果的精度。

本发明具体实现包括如下步骤：

步骤1、搭建基于差分检测的控制平面故障诊断系统；

该系统包括数据采集模块、在线监控模块、离线故障诊断模块和网络事件重放引擎，具体模块描述如下：

·数据采集模块：负责监测SDN控制平面的行为，记录系统可见的执行信息。能够动态加载到控制器上而不需要对控制器的代码进行修改，进行低开销的高效的动态数据采集。

·在线监控模块：在生产环境中对系统状态进行动态监测，收集来自数据采集模块的数据，从中构造系统行为模型。并将正常状态下的系统行为模型作为参考模型，用于与对应的异常行为模型进行差分检测，进行故障诊断。

·离线故障诊断模块：根据故障的症状找到发生故障的系统行为模型以及对应的参考模型，随后进行差分检测和根因分析，生成故障诊断报告。

·网络事件重放引擎：基于代码的网络事件重放引擎，负责仿真拓扑结构，模拟数据平面的网络设备和应用平面中发送消息的网络应用，根据输入的重放策略生成相应的网络拓扑和产生特定的消息序列(这里消息是指网络事件，如RESTful请求或OpenFlowmessages)。通过调整消息的类型和组成序列，重现出SDN网络异常，辅助异常诊断算法进行异常诊断和定位。

本发明基于差分检测的控制平面故障诊断系统的实现流程如下：

首先通过在线监控模块，利用在控制平面中部署的数据采集模块，获取控制器内部的代码调用，状态变化等信息，构建上下文感知的系统行为模型。当前系统无异常时，提取系统行为模型存入参考库中，作为参考模型。

当发现异常时，根据故障的症状找到发生故障的系统行为模型以及对应的参考模型；随后从上向下地对其进行差分比对，找出异常节点；然后在异常节点处进行静态分析，在代码层面找出故障发生的根源，在模拟环境中通过网络事件重放引擎确认之后，作为故障诊断报告，提交给管理员。

步骤2、基于字节码插桩的数据监测和收集机制

针对目前SDN控制平面内部处理流程关键数据获取困难、调用逻辑不可见的问题及其导致的异常分析和定位的困难性，需要设计高效的数据监测和收集机制。本发明设计的数据监测和收集机制利用字节码插桩方来实现动态系统行为跟踪。字节码是控制器运行时的代码，该机制通过对字节码进行插桩来实现行为跟踪，因而不需要修改控制器源码或者重启控制器。同时，本发明设计了一种基于规则的代码插桩语言来简化动态跟踪的配置。通过对控制器进行插桩，本发明能够收集控制层面的各类代码执行的行为信息，资源消耗，调用状态等，为构建系统行为模型，故障诊断做好准备。

具体的实现方式和工作流程为：

2-1.实现可配置的数据采集模块，并部署在SDN控制器中；

2-2.数据采集模块根据具体的插桩规则对控制器的字节码进行插桩，添加负责运行时数据采集的代码；

2-3.在SDN控制器的实际运行中，数据采集模块将系统的调用信息等数据收集起来，发送给外部的在线监控模块；

以对基于Java的SDN控制器的插桩为例，如图2所示，可以采用ASM实现对字节码的插桩。ASM是一个流行的Java字节码操作和分析框架，它提供了一系列API来帮助开发者完成字节码操作的整个流程，使用Java提供的JVMTI/BCI在Java字节码加载时对其进行修改和操作。

相应的实现方式和工作流程为：

(1)利用ASM实现可配置的数据采集模块，并利用JVMTI将其动态地附加到SDN控制器的JVM上，提供JVM加载的类的相关信息；

(2)在线监控模块提供插桩规则，数据采集模块根据接收到插桩规则在字节码相关位置根据插桩规则插入用于记录调用关系的字节码，即记录调用方法、被调用方法、被调用方法的参数以及调用起止时间等数据信息；

(3)数据采集模块将收集到的数据信息传送给外部的在线监控模块，用于构建系统行为模型。

插桩是将需要新增加的代码植入到现有的代码中去。为了实现上述的动态跟踪，对于管理员来说，存在的挑战是无法确定哪里需要插入代码以及插入什么样的代码，并且他们通常不熟悉字节码。为了解决上述问题，本发明设计了一种插桩语言(插桩规则，in-rule)来接简化插桩的过程，同时可以根据管理员的需求自动生成插桩规则，提高配置的效率。

如图3所示，插桩规则是一个由match和action组成的二元数组。其中，match字段用于匹配字节码，定位插入代码的具体位置，它由三个名称子字段(既module，class和method)和一个位置子字段(call site)组成。这三个名称子字段遵循面向对象编程软件的模块化代码层次结构，用来将in-rule定位到具体的函数代码段中。定位到具体的函数后，本发明利用call site子字段进一步匹配到该函数具体的代码行，它由代码行数(linenumber)、指令(instruction)、以及位置前后信息(before(B)or after(A))组成。action用于定义需要记录的代码运行相关的数据(attributes)，如线程号(thread)、时间戳(timestamp)、调用类型(invocation type)和变量数值(variable values)等。在进行插桩时，Trace Agent会将这些规则翻译成字节码插桩工具(如针对Java Bytecode的ASM)所需要的语言，并利用这些工具进行插桩。

图3为一条in-rule的例子，为了方便理解，这里使用了Java的源代码作为例子，该代码来自OpenDaylight l2switch中处理Packet_In消息的模块，它根据控制器中是否记录了该消息对应的源地址与目的地址来决定是生成Packet_Out消息还是进行数据包广播。这条插桩规则用于记录控制器生成Packet_Out消息时的相关信息，它的match字段可以使插桩程序定位到函数dispatch-Packet的第四行之前的位置来插入代码。在控制器运行时，该in-rule可以记录如线程号、payload、src、dest等信息。

步骤3、上下文感知的系统行为模型构建机制；

将动态跟踪数据建模为系统行为模型会面临三类挑战：(1)由于网络的并发性，控制器需要同时执行处理不同的外部事件的任务，因而收集到的跟踪数据都交错在一起。甚至在同一个任务中，各种异步操作使得执行信息错综复杂，并且没有直接的ID信息用于串联这些异步调用，因而很难将跟踪数据关联起来；(2)由于控制器的分布式特性，如何将来自不同的控制器节点的跟踪数据关联在一起成为数据建模的难点之一，同时潜在的控制器时钟不同步问题会导致来自不同节点的数据之间存在时间戳的差异，而会影响最终关联的正确性；(3)网络控制逻辑的非确定性意味着控制器在不同的系统上下文中表现出不同的行为模式，因而在没有具体上下文时很难推断确定性的执行路径。为了解决上述问题，本发明设计了SDN控制平面系统行为模型构建的机制和上下文感知的调用模型建立机制。

为了处理外部输入事件，控制器同时维护了多个事件处理器，每个事件处理器都会使用多个线程来执行不同的操作。每个操作都在一个线程内由多个同步调用完成，同时还会通过异步调用(如Notification)引发其他的操作。如图4所示，线程1中执行的操作在第三个节点处通过异步调用，发起了线程2中所执行的操作。从中可以看出，每个操作都是由外部输入事件或者异步调用产生的，同一个操作内的同步调用可以按照他们的时间关系(Happen-before)串联成一条调用链，而不同操作之间则可以利用他们的异步调用关系连接在一起，组成完整的调用树。因而，利用上述两种关系，可以将同一个任务中的调用事件构建为了一个树状的跟踪图。

3-1.根据上述的特性，本段介绍了如何处理接收到的跟踪数据，构建跟踪图。主要的问题是在于如何分离交错的跟踪数据以及确定他们之间的时间关系和异步关系。跟踪图构建过程如下：

图节点：每当从数据采集模块中获得一条跟踪消息，本发明首先将该消息转换成跟踪图中的节点。每条消息都是由对应的插桩规则产生的，每条插桩规则定义了一类跟踪消息的结构和数据类型，因而每类跟踪消息可以抽象为一个模板。该模板由一系列不变的关键字和变量名组成(如时间戳、线程、事件类型等)。对于同一个类型的消息，它们之间的差别是这些关键字和变量所对应的参数值的不同。本发明从消息中提取这些数值，并用已有的模板来构建图节点；

链状图：由于来自于多个任务不同的操作的节点混杂在一起，本发明首先利用它们的线程ID来区分。因为任何时刻同一线程只能被一个操作占用，只有该操作完成后，才会被别的操作所占用。因而利用每个操作都有初始节点和结束节点的特点(如Notificationaccept和Notification terminal)，可以将来自于不同的操作的节点区分出来。进而按照节点的时间先后关系构建成调用链，既链状图；

树状跟踪图：有了每个操作的链状图，本发明需要找出它们之间的异步调用关系，将来自同一个任务的链状图关联成该任务的跟踪图，既树状图。不同于同步调用，异步调用没有可以用于关联的ID，同时异步调用有显性和隐形之分，显性的异步调用有特定的调用发起者，而隐形的则没有。如在OpenDaylight中，只有当数据库中一个数据被data changelistener监听时，对于该数据的操作，才会产生异步调用。为了定位异步调用关系，本发明使用了一种多维度的信息管理机制。具体而言，本发明通过代码分析，找出所有可能的异步调用发起点(如Notification publish)，当接收到一条异步调用发起点的跟踪消息时，本发明构建一个多维的数组来定义一个异步调用的存在，其中包含了该发起者的时间类型、线程号、链状图的位置、时间戳、参数集合的哈希值以及链状图在上级父图中的位置。本发明同时也会为新到来的异步接受消息生成同样的数组，并与已有的数据进行多个维度的多模匹配(例如时间戳、调用类型、调用名、调用参数等)，进而确认两者的异步调用关系，最终将它们连接起来，构建为一个完整的跟踪图。如图4所示，线程1中第三个节点匹配到了线程2的开始节点，因而两个链状图可以通过异步关系关联成一个树状图。

由于控制器代码逻辑的不确定性，在不同的上下文信息下，同一个任务可能会产生不同的跟踪图，如图5。造成这种情况的主要的原因在于代码逻辑中包含了很多条件分支语句(如if...else)，这些语句在不同的上下文下会引出不同的代码路径。因此，如何解决这些由于上下文不同而带来的不确定性，合并异构的跟踪图将在本部分中进行讨论。

3-2.本发明首先将每个跟踪图转换为一个有限状态机(finite state machine,FSM)来表示。FSM是由一个多维度数组，W＝(S，Δ，s_i,s_f)；其中：(1)S是一个有限非空的状态集合；(2)Δ是一个状态转换函数的集合，既Δ：s→s′；(3)s_i和s_f是初始和最终状态。状态是指一条跟踪消息所处的状态，由该消息在软件中所处的代码位置和一个转换函数集合(包含了入站和出站转换函数和相关的变量值)组成。转换函数对应调用事件，可以将一个状态转换为另一个状态。

3-3.为了解决异构的跟踪图问题，本发明进一步将同一个任务的FSM合并为一个上下文感知的状态机(context-aware FSM，CAM)。不同于FSM，CAM包含了三种类型的转换函数，如图6所示：(1)直接转换(图6a:concrete transition)是由一对先前和继承状态组成，代表了在同一个链状图中这两个状态的时间顺序关系；(2)多分支转换(图6b:forktransition)具有多个继承状态(一个是直接转换的继承状态V₁，其他则是该状态触发的异步调用的接收者V₂…V_n)，该转换函数用于处理异步调用的关系；(3)条件转换(图6c:conditional transition)在不同的上下文环境下具有不同的继承状态，是上下文感知的，用来建模数据依赖的代码逻辑。具体而言，如果在直接转换函数的一对状态之间的代码存在条件分支，在代码执行时，根据不同的条件值，会执行不同的指令，它就可以被转换成条件转换函数。一个转换函数由成对状态和转换类型组成。而一个条件转换函数则会有一个额外的条件字段，用于感知相关的数据，进而转换到不同的状态上。

利用CAM模型，本发明可以将来自于同一任务的异构调用模型合并为一个统一的上下文感知模型，进而在给定相应的上下文信息时，可以推断出对应的系统行为信息。其合并流程如下：

为了合并两个FSM，本发明首先确认两者是否是异构的，以及异构开始的地方。为此，本发明为每个跟踪树设计了一种基于哈希的骨架树来进行快速匹配和定位差异点。该骨架树的每个节点代表了跟踪树中一条链状图的哈希值，而骨架树的边则代表了链状图之间的异步调用关系。链状图的哈希值是其节点的ID信息按顺序串联而成的本发明的哈希值，而节点的ID信息则是由该节点的模板组成的文本的哈希值。因而，在构建链状图时，本发明会维护一个节点ID串联的文本，并随着新的节点到来而不断增加ID信息；而在构建树状跟踪图时，本发明会将每条新构建的链状图的ID本发明转换为哈希值，并以每条链状图之间的异步关系来构建骨架树。利用骨架树，本发明可以快速确定新来的跟踪图与已有的跟踪图是否存在差异，如果存在，则可以定位到具体的链状图，进而进行合并。

如图7所示，图7中的(a)和(b)是两条异构的跟踪树，在节点S_b之后产生了不同的调用((a)调用了节点S_c，而(b)则调用了节点S_d)。因而，在S_b之后存在条件分支，该条件分支在(a)和(b)中两种上下文下会产生不同的调用。本发明通过静态分析的方式，从控制器的字节码中获取该条件分支以及相关的变量和条件，进而将原先的两个直接转换函数t₁合并为一个条件转换函数ct₁。该转换函数中包含了一个条件分支。在状态S_b中设定不同的参数值，该条件转换函数可以产生不同的继承状态。最终形成如(c)所示的上下文感知的调用模型CAM。

3-4.SDN控制器是事件驱动的，因而它们内部的上下文信息都是由来自于数据和应用平面的外部输入事件产生的。因此，在CAM模型中条件分支的上下文都来自于其本身的输入事件，或者因为先前的输入事件而存储在数据库中。通过挖掘任务模型之间的依赖关系，本发明可以进一步减少SDN系统行为的非确定性，为故障诊断提供更准确的依据信息。

故障通常是上下文依赖的，既在特殊的系统状态下，该故障才会出现。为了挖掘这种模型依赖关系，本发明从条件转换函数中分支条件的上下文反向递推模型间的依赖关系。一种上下文信息可以由单个输入事件引入，也可以由多个输入事件按照特定输入后，合并操作而产生。因而，给定一种上下文信息，本发明在所在模型和已有的模型中迭代地搜索那些对该数值进行插入或更新的相关指令，进而定位出对应的输入事件或者事件序列。如果一个CAM(W₁)中一个条件转换函数的一个上下文是由另外一个CAM模型(W₂)的输入事件产生，则称模型W₁上下文依赖于模型W₂，或者说W₁是上下文依赖于W₂的输入事件。利用这种模型之间的依赖关系，本发明可以进一步扩充CAM模型。

步骤4、基于差分检测的故障诊断算法

针对目前分布式SDN控制平面调用逻辑复杂、软件异常识别、定位、诊断困难低效的现状，需要设计精确高效的故障诊断和根因定位机制。本发明的故障诊断机制是基于差分检测设计的。SDN控制平面的故障通常会引起内部执行路径的异常。因此，当故障发生时，本发明首先根据故障的症状找到发生故障的系统行为模型以及对应的参考模型；随后从上向下地对其进行差分比对，找出异常节点；然后在异常节点处进行静态分析，在代码层面找出故障发生的根源，在模拟环境中通过网络事件重放引擎确认之后，作为故障诊断报告，提交给管理员。一般说来故障诊断通常分为三个部分，首先输入故障症状，然后进行故障诊断，最后输出诊断结果，本章接下来就从这三部分进行详细描述。

4-1.要进行自动化的故障诊断，首先需要将故障症状输入系统。SDN控制平面的故障症状主要表现为两种：(1)对外部输入事件，如REST请求或OpenFlow消息，有错误的或异常的返回；(2)SDN控制器在系统日志中输出错误信息。

本发明将它们使用如下语法进行了形式化表达：

′time′：(′timestamp′|null)

′type′：(′REST′|′log′|′flow′/′rule′)

′request′：(′method′&′url′&′payload′&′response content′&′responsestatus′)

′log′：(′status′&′content′)

′flow′：(′messageType′&′switchlD′&′OFVersion′&′content′)

′rule′：(′switchlD′&′rulelD′&′match′&′action′)

一个故障症状主要由time、type和content三部分组成，根据故障的症状类型，会有不同类型的content。当出现故障时，管理员可以直接查询失败的外部请求，也可以查询控制器所输出的log，这就是type字段的含义。如果所查询内容有时间戳信息，作为time字段输入进来，比如log的时间戳，否则输入null。剩下的content部分根据type的不同，格式也不同。当查询REST请求时，需要输入请求的方法、URL、负载、返回值和返回内容；当查询log时，则要输入log的状态，如error、warning，以及log的内容。

对于外部输入事件类型的故障症状，本发明只需检索对应的外部输入事件，再结合管理员输入的时间戳信息(也可从本发明搜集的数据中得到)，就能定位到出现故障的模型。对于log类型的故障症状，如果包含精确的时间戳，本发明可以在发生在时间戳之前的外部事件中进行搜索，寻找故障模型；如果没有精确的时间戳，本发明从最近的模型开始检索，寻找异常的系统行为模型。

4-2.通过对故障症状的分析找出故障模型和对应的参考模型之后，本发明对其进行对称的比较，找出它们之间的模型差异，定位出差异节点以及对应的上下文信息。最后，本发明从导致异常的上下文入手，找出它们的数据来源，在模拟环境中通过网络事件重放引擎确认之后，作为诊断结果。

以图8为例，假设这是一个日志消息中的错误，将其输入系统后，本发明根据日志内容在控制器字节码中搜索记录日志消息的代码位置，然后识别出对应的外部输入事件(NBI请求I)，该事件触发的调用链包含了日志中记录的方法，它的执行时间也覆盖了日志消息的时间戳。对于I，在当前的挖掘模型中，有两个异构模型(Run 1和2)。它们有不同的运行时上下文，分别为S₁和S₂，而Run 2触发了输入进来的故障。很明显，在上下文S₂的影响下，Run 2中的控制器程序在V_b之后没有沿着正常的执行路径继续执行。因此，为了诊断故障，不仅需要报告出现异常的代码逻辑和位置，还需要报告关键的触发上下文。

4-3.CAM构造机制能够找到节点V_b之后的不同状态作为异构差异点，在出现差异的转换e₁和e₁′处，通过控制流分析，找到造成执行路径差异的条件分支，从条件分支中获得引发执行路径变化的具体上下文，通过对数据流进行回溯分析寻找该上下文的数据来源，并搜索之前的外部输入事件调用链，找到造成这些上下文的有序源输入事件序列。本发明在模拟环境中利用网络事件重放引擎进行delta调试，以消除不相关的上下文。在每次重放中，改变部分上下文并重放改变的输入事件序列以检查是否仍然可以复现故障。最后，输出最小输入事件序列、关键上下文以及相应的执行路径。

4-4.本发明的诊断结果分为三个部分，(1)首先是触发异常的外部输入事件对应的调用树图。(2)第二个是异常调用事件的CAM模型，以及它和对应的参考模型之间的差异，即差异的起始节点和后续的转换。(3)第三个是带来异常的执行路径的条件分支所在的控制流图，该条件分支在图中的位置、对应的上下文信息，以及这些上下文的数据来源。

本发明说的上下文，是指SDN控制器系统中代表系统当前状态，会影响系统执行路径的变量值，比如DB中的数据，外部输入事件的input等。控制器根据这些上下文判断当前的系统和网络状态，对外部事件做出合理的反馈和操作。本发明将上下文的数据来源分为两类，DB read和input。所谓数据来源，是指条件分支中该上下文变量值的原始来源。系统可能对从该数据来源获得的原始数据进行计算、加工，获得该上下文变量值的具体数据，但是对于SDN控制器来说，这些变量值的数据来源只有从数据库中读取和从外部输入事件中获得两种。对于来源是DB read的上下文，虽然它们的直接数据来源是数据库的读取，但背后的真正来源其实是之前的外部输入事件的输入。之前的外部输入事件将数据写到了DB里，当前的执行过程读取了之前写入的数据，影响了现在的系统执行过程。如前文所说，本发明将外部输入事件之间的这种关系称为外部输入事件之间的上下文依赖。本发明也对这种数据依赖进行了挖掘，在诊断结果中除了列举具体的数据来源，还把与该上下文相关的其他外部输入事件列举了出来。

在这个从条件分支回溯寻找关键上下文的数据来源的过程中，还存在跨异步调用的回溯。对于跨异步调用的数据传递，本发明在控制流分析中结合了对调用树图的回溯，通过利用调用树图中标记的异步调用发起者和被调用者，可以把跨异步调用的控制流接续起来，进行上下文数据来源的回溯查找。

总的来看，本发明的诊断结果的三个部分，也对应着故障诊断的三个阶段，通过对输入的故障症状的分析，能够查找到触发异常的外部输入事件，给出其调用树图；通过差分检测，可以找到异常行为模型和参考模型之间的差异；最后，通过控制流分析，可以定位到造成异常的条件分支和相关的上下文，并通过回溯获得上下文变量的数据来源。

Claims

1.基于差分检测的控制平面故障诊断系统，其特征在于包括数据采集模块、在线监控模块、离线故障诊断模块和网络事件重放引擎，具体模块描述如下：

2.根据权利要求1所述的基于差分检测的控制平面故障诊断系统的实现方法，其特征在于包括如下步骤：

步骤1、基于字节码插桩的数据监测和收集机制；

步骤2、上下文感知的系统行为模型构建机制；

步骤3、基于差分检测的故障诊断算法；

所述的步骤1具体实现如下：

利用字节码插桩方式来实现动态系统行为跟踪；并设计有基于规则的代码插桩语言来简化动态跟踪的配置；通过对控制器进行插桩，收集控制层面的各类代码执行的行为信息、资源消耗和调用状态，具体的实现方式和工作流程为：

1-1.实现可配置的数据采集模块，并部署在SDN控制器中；

1-2.在线监控模块提供插桩规则，数据采集模块根据接收到插桩规则对控制器的字节码相关位置根据插桩规则插入用于记录调用关系的字节码，添加负责运行时数据采集的代码；即记录调用方法、被调用方法、被调用方法的参数以及调用起止时间的数据信息；

1-3.在SDN控制器的实际运行中，数据采集模块收集系统的调用信息数据，并发送给外部的在线监控模块，用于构建系统行为模型。

3.根据权利要求2所述的基于差分检测的控制平面故障诊断系统的实现方法，其特征在于所述的插桩规则具体如下：

插桩规则是一个由match和action组成的二元数组；

其中match用于匹配字节码，定位插入代码的具体位置，match字段由三个名称子字段和一个位置子字段组成，三个名称子字段分别为module、class和method，一个位置子字段为call site；三个名称子字段遵循面向对象编程软件的模块化代码层次结构，用来将插桩规则定位到具体的函数代码段中，定位到具体的函数后，利用位置子字段进一步匹配到该函数具体的代码行；

位置子字段由代码行数、指令、以及位置前后信息组成；

action用于定义需要记录的代码运行相关的数据，包括线程号、时间戳、调用类型和变量数值；

在进行插桩时，Trace Agent会将插桩规则翻译成字节码插桩工具所需要的语言，并利用这些工具进行插桩。

4.根据权利要求3所述的基于差分检测的控制平面故障诊断系统的实现方法，其特征在于步骤2具体实现如下：

2-1.构建树状跟踪图：

图节点：每当从数据采集模块中获得一条跟踪消息，首先将该跟踪消息转换成跟踪图中的节点；每条消息都是由对应的插桩规则产生的，每条插桩规则定义了一类跟踪消息的结构和数据类型，因而每类跟踪消息抽象为一个模板；该模板由一系列不变的关键字和变量名组成；对于同一个类型的消息，它们之间的差别是这些关键字和变量所对应的参数值的不同；从消息中提取这些参数值，并用已有的模板来构建图节点；

链状图：由于来自于多个任务不同的操作的节点混杂在一起，首先利用线程ID来区分；利用每个操作都有初始节点和结束节点的特点，将来自于不同的操作的节点区分出来；进而按照节点的时间先后关系构建成调用链，既链状图；

树状跟踪图：根据每个操作的链状图，找出它们之间的异步调用关系，将来自同一个任务的链状图关联成该任务的跟踪图，既树状图；通过代码分析找出所有可能的异步调用发起点，当接收到一条异步调用发起点的跟踪消息时，构建一个多维的数组来定义一个异步调用的存在，其中包含了该发起者的时间类型、线程号、链状图的位置、时间戳、参数集合的哈希值以及链状图在上级父图中的位置；同时为新到来的异步接受消息生成同样的数组，并与已有的数据进行多个维度的多模匹配，进而确认两者的异步调用关系，最终将两者连接起来，构建为一个完整的跟踪图；

2-2.将每个跟踪图转换为一个有限状态机来表示；有限状态机FSM是一个多维度数组W＝(S，Δ，s_i,s_f)，其中S是一个有限非空的状态集合；Δ是一个状态转换函数的集合，既Δ：s→s′；s_i和s_f是初始和最终状态；

2-3.将同一个任务的有限状态机FSM合并为一个上下文感知的状态机CAM，CAM包含了三种类型的转换函数：

(1)直接转换：是由一对先前和继承状态组成，代表了在同一个链状图中这两个状态的时间顺序关系；

(2)多分支转换具有多个继承状态，即一个是直接转换的继承状态V₁，其他则是该状态触发的异步调用的接收者V₂…V_n；该转换函数用于处理异步调用的关系；

(3)条件转换；在不同的上下文环境下具有不同的继承状态，是上下文感知的，用来建模数据依赖的代码逻辑；

具体而言，如果在直接转换函数的一对状态之间的代码存在条件分支，在代码执行时，根据不同的条件值，会执行不同的指令，它就可以被转换成条件转换函数；一个转换函数由成对状态和转换类型组成；而一个条件转换函数则会有一个额外的条件字段，用于感知相关的数据，进而转换到不同的状态上；利用CAM模型，将来自于同一任务的异构调用模型合并为一个统一的上下文感知模型，进而在给定相应的上下文信息时，推断出对应的系统行为信息，其合并流程如下：

首先确认两者是否是异构的，以及异构开始的地方；其次为每个跟踪树设计一种基于哈希的骨架树来进行快速匹配和定位差异点；该骨架树的每个节点代表了跟踪树中一条链状图的哈希值，而骨架树的边则代表了链状图之间的异步调用关系；链状图的哈希值是其节点的ID信息按顺序串联而成的哈希值，而节点的ID信息则是由该节点的模板组成的文本的哈希值；因而，在构建链状图时，需维护一个节点ID串联的文本，并随着新的节点到来而不断增加ID信息；而在构建树状跟踪图时，需将每条新构建的链状图的ID信息转换为哈希值，并以每条链状图之间的异步关系来构建骨架树；利用骨架树快速确定新来的跟踪图与已有的跟踪图是否存在差异，如果存在，则定位到具体的链状图，进而进行合并；

2-4.挖掘任务模型之间的依赖关系，进一步减少SDN系统行为的非确定性，为故障诊断提供更准确的依据信息；

根据给定的一种上下文信息，在所在模型和已有的模型中迭代地搜索那些对该数值进行插入或更新的相关指令，进而定位出对应的输入事件或者事件序列；如果一个CAM(W₁)中一个条件转换函数的一个上下文是由另外一个CAM模型(W₂)的输入事件产生，则称模型W₁上下文依赖于模型W₂，或者说W₁是上下文依赖于W₂的输入事件；利用这种模型之间的依赖关系，进一步扩充CAM模型。

5.根据权利要求4所述的基于差分检测的控制平面故障诊断系统的实现方法，其特征在于步骤3具体实现如下：

首先根据故障的症状找到发生故障的系统行为模型以及对应的参考模型；随后从上向下地对其进行差分比对，找出异常节点；然后在异常节点处进行静态分析，在代码层面找出故障发生的根源，在模拟环境中通过网络事件重放引擎确认之后，作为故障诊断报告，提交给管理员；

3-1.实现自动化的故障诊断：

首先需要将故障症状输入系统；SDN控制平面的故障症状主要表现为两种：(1)对外部输入事件；(2)SDN控制器在系统日志中输出错误信息；

一个故障症状由time、type和content三部分组成，根据故障的症状类型，会有不同类型的content；当出现故障时，管理员可以直接查询失败的外部请求，也可以查询控制器所输出的log，这就是type字段的含义；如果所查询内容有时间戳信息，作为time字段输入进来，否则输入null；剩下的content部分根据type的不同，格式也不同；

对于外部输入事件类型的故障症状，只需检索对应的外部输入事件，再结合管理员输入的时间戳信息，就能定位到出现故障的模型；对于log类型的故障症状，如果包含精确的时间戳，则在发生于时间戳之前的外部事件中进行搜索，寻找故障模型；如果没有精确的时间戳，则从最近的模型开始检索，寻找异常的系统行为模型；

3-2.通过对故障症状的分析找出故障模型和对应的参考模型之后，对两个模型进行对称的比较，找出两者之间的模型差异，定位出差异节点以及对应的上下文信息；最后从导致异常的上下文入手，找出它们的数据来源，在模拟环境中通过网络事件重放引擎确认之后，作为诊断结果；

3-3.CAM构造机制能够找到节点V_b之后的不同状态作为异构差异点，在出现差异的转换e₁和e₁′处，通过控制流分析，找到造成执行路径差异的条件分支，从条件分支中获得引发执行路径变化的具体上下文，通过对数据流进行回溯分析寻找该上下文的数据来源，并搜索之前的外部输入事件调用链，找到造成这些上下文的有序源输入事件序列；最后，输出最小输入事件序列、关键上下文以及相应的执行路径；

3-4.本发明的诊断结果分为三个部分，(1)首先是触发异常的外部输入事件对应的调用树图；(2)第二个是异常调用事件的CAM模型，以及它和对应的参考模型之间的差异，即差异的起始节点和后续的转换；(3)第三个是带来异常的执行路径的条件分支所在的控制流图，该条件分支在图中的位置、对应的上下文信息，以及这些上下文的数据来源。