赞
踩
这是我读的条理最清晰的一篇文章了!
每个node和edge都包含了很多的信息,这里我们列出一些对因果分析有用的信息:
事件类型,事件发生的时间窗,信息流的方向
本文中提出了一个名词叫做 Point-of-Interest (POI),在文章中大量的使用了这个名词,根据我的理解这应该是一个有问题的事件(也就是说从这个时候开始观测到有问题,算是一个监测点,从这个点开始进行backward分析,试图找到所有对这个事件有影响的所有事件和点并且构造出一个图)。
上图就是一个例子,eAD-1就是那个POI Event,红色线标识的事件是对POI有影响的事件,黑色虚线标识的事件是对POI没有影响的事件。
对Linux和Windows分别使用Kernel audit和ETW进行日志收集,我们观察到一台普通的桌面计算机每天产生超过100万个事件,而一台服务器可能产生10到100倍的量。
结论:Reducing the data volume is key to solving the scalability problem.
For each “key event” there exist a series of “shadowed events” whose causal relations to other events are negligible in the presence of the “key event” ,Therefore,we could significantly reduce the data volume while keeping the causal dependencies intact, by merging or summarizing information in“shadowed events”into“key events”while preserving causal relevant information in the latter.
(对于key event他有许多的shadowed events ,当key event出现的时候,shadowed events可以被忽略掉,所以这种情况就可以进行合并从而减少数据量)
下面给出几个例子,具体算法会在3章节中提到:
这里提一下上图4这种情况,这是双向的情况下,即不管进行backward还是forward都是同样的keyevent和shadowevent。
With further study of our data, we discover that several applications (mostly system daemons) tend to produce intense bursts of events that appears semantically similar, but are not reducible by the perfect causality preserving reduction, due to interleaved dependencies.
For example, process “pcscd” repeatedly interleaves read/write access to a set of files. We name this type of workload “iBurst.”(就是有一些程序会在短时间内突发大量在语义上是类似的事件,对于这种类型的程序进行数据缩减是没法完美的保留因果的)
With iBurst, data reduction is only possible with certain levels of loss in causality. (所以考虑以一种低的因果损失为代价进行缩减)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。