Zeyan Li 李则言

So, here is the only rule: the larger reconstruction probability, the less likely a point is an anomaly. You should not use absolute values. Reconstruction probability may be positive or...

Apriori用于这个问题是参考这篇论文: Detecting and Localizing End-to-End Performance Degradation for Cellular Data Services Based on TCP Loss Ratio and Round Trip Time. 具体来说就是对所有的leaf attribute combination做一次异常检测, 然后用apriori算法去找`attribute combination -> 异常`这样的关联规则. iDice整体问题是我们关注的问题的一个子问题, 还是适用的. 只是它里面的几个剪枝策略,...

我们判断根因的依据其实是GPS而不是GRE。GPS不止考虑了GRE。我们认为一个属性组合是根因需要满足以下两个条件 1. 这个属性组合尽可能多地覆盖了数据中的异常部分而没有覆盖正常部分 2. 这个属性组合要尽可能简洁。 3. 这个属性组合要满足GRE 条件1和3在GPS公式中很明显；条件2因为我们的搜索算法，没有必要放在GPS公式中（因为我们是搜top-k的组合，如果同一个cuboid中，比根因复杂的属性组合就会覆盖更多的正常数据；而不同的cuboid的结果我们通过succinctness的比较考虑了）。 至于第一步的聚类，本质上就只是为了化简问题（一个多根因的问题->多个单根因的子问题）

GRE是经验性的，不一定所有系统、所有故障都会满足。条件3相比于1和2可以理解为一个正则化项，因为数据中异常检测的不准确等噪声，只用1和2就很容易受到影响。

> 在hotspot方法里，PS值考虑了RE，hotspot方法找的根因必须遵循RE，而不是经验性的认为 > > 所以大佬，您能帮忙解释一下，hotspot方法考虑RE的依据是什么？ > >  HotSpot中RE也是经验性的发现。 HotSpot中的 potential score和Squeeze中的GPS的设计思路其实差不太多，只不过我们将异常和正常部分的距离分开算了再加起来而已（这是为了能够定位anomaly magnitude比较小的根因，论文中的实验也说明了Squeeze在这方面比HotSpot强很多）。虽然HotSpot论文中的故事不是这么写的，但是按我上面说的三个条件去理解这个potential score我觉得也没毛病。

1. 是的，real和predict分别是对应属性组合的真实和预测值 2. 你可以这么理解，如果real和predict差距很大，那么这个属性组合应该是异常的。但是我们的方法中其实没有做异常检测，我们没有去判断一个属性组合是否是正常的。

你好，这个本地文件系统指的就是机器本地的硬盘，一般机器应该都是的。我们的计算集群home目录是网络文件系统，访问大量小文件比较慢，所以我才弄了这个 Zeyan LI 李则言 E-Mail: ***@***.*** Ph.D. student Department of Computer Science Tsinghua University Beijing, China 在 2022年11月17日，18:30，LIULOCKED ***@***.***> 写道：  您好，非常感谢您分享的这篇文章和代码，对我目前研究的方向十分有帮助。 在跟据您这篇文章的代码做复现的时候，有关FDG_config.py里本地文件系统加速训练时一直出现问题 想问一下您，这个本地文件系统是什么，如何获得。 万分感谢 — Reply to this email...

File structure:

1. 是的，可以说是人工选定的。准确来说，我们的实验中的做法，实际上是把我们监控到的所有指标分类成不同的failure class。 2. strucuture-independent是希望让系统中类似的组件能共享模型。GCN的计算是和节点在图上的具体位置有关的，但是GAT就只和周围邻居的特征有关 3. 你可以参考我在这个issue的回答 https://github.com/NetManAIOps/DejaVu/issues/3 4. 我们使用无向图的原因是因为，我们很难通过调用和部署关系确定故障传播的方向。比如service1部署在docker1上，那么docker1上的内存不足问题可以影响service1，但是如果是service1本身存在内存泄漏问题，那么就是service1反过来影响docker1，然后可能再影响docker1上的其他服务。因为这种不确定性，所以我们干脆用了无向图，避开了确定方向的问题。我们这个方法的本质思路，其实是学习故障特征（组件的指标特征和组件间在图上的相对关系）和根因之间的关系，并没有真的去分析故障传播的路径，所以用无向图也能够达到效果。当然，如果有更好的方法， 能得到更准确的故障实例间的因果关系图，应该是更好的。

1. norm指的是归一化之后的指标数据 2. a1+a2=A数据集 3. 归一化方法主要用的是sklearn里面的robust scaler，另外有几个指标是特殊处理的。比如响应时间这种先取了对数 Zeyan LI 李则言 E-Mail: ***@***.*** Ph.D. student Department of Computer Science Tsinghua University Beijing, China 在 2022年9月17日，21:22，adverbial39 ***@***.***> 写道：  另外关于数据集还有几个问题： a1和a2中的metric和metric_norm是什么关系？a2的指标包含a1的，两个集之间有什么关系？ 数据集中的数据是原始数据还是归一化后的数据，如果是归一化后的，请问使用了什么归一化方法？...