[论文笔记]Automated Identification of Failure Causes in System Logs

今天用了下午和晚上的时间又读了一遍下面这篇文章：

L. Mariani, and F. Pastore, “Automated Identification of Failure Causes in System Logs,” in Proceedings of the 2008 19th International Symposium on Software Reliability Engineering, 2008.

 

记得第一次读这篇文章还是在从北京回西安的软座车上，文章作者所在实验室的网站是：http://www.lta.disco.unimib.it/lta/index.php

我们已经系统地读过了他们很多篇文章了。总得来说这个实验室也比较高产，出文章的效率和质量都比较高。

 

言归正传，这次看论文仔细了很多，文章将基于系统日志的故障原因定位分为了三个步骤：1.monitoring 2.model generation 3.failure analysis

其中主要的创新点在第二步model generation，又分为event detection，data transformation，model inference三个步骤。

其中第一小步骤event detection主要解决的问题是在不知道系统日志具体格式的情况下怎么日志中的变量值和事件名区分开。

第二小步骤data transformation主要解决的问题是怎样将具体的变量值转化成多个内部相关的集合，每个集合被称作data flow cluster，作者提出了三种策略，分别叫做Global Ordering，Relative to Instantiation，Relative to Access。Global Ordering适用于同样一个变量集合被多次使用，Relative to Instantiation适用于新的变量被创建后使用次数很少的情况；Relative to Access适用于变量被创建后多次使用的情况。作者这一点创新很有意思，但是并没有说明这三种策略的完备性。

第三小步骤model inference，主要是基于前两步的结果，使用他们自己提出的k-Behavior算法[1]进行FSA模型的生成，由于我对k-Behavior算法本来就不甚了解，所以不清楚他们是怎么用k-Behavior算法结合第二步的data flow cluster的？

在文章的后面，主要介绍怎么使用FSA模型进行故障原因定位，不是简单的对比failing runs和FSA模型是否匹配，因为这样一旦不匹配发生后，后面的序列是肯定匹配不上的。作者采用的方法是借鉴k-Behavior算法中扩充模型的思想，将每次模型的扩充点记录下来，然后提供给tester。

我想知道这样做是否对causes进行了优先级的排序，从文章的叙述来看，应该是没有做到这一点。那么这种方法的实用性还是要打点折扣的。

上面就是这篇文章的主要阅读感受，提出的三点问题可能是我对作者的意思还没有彻底领悟。不过这篇文章也算读的时间比较长的了。

 

[参考文献]:

1. L. Mariani, and M. Pezze, “Dynamic Detection of COTS Component Incompatibility,” IEEE Softw., vol. 24, no. 5, pp. 76-85, 2007.