事件链分析与推理

Question

我的老板说，目前的日志对客户来说是不可接受的。如果出现故障，设备的十几个不同模块都会报告自己的错误，并且都会在日志中登录。故障的原始原因可能隐藏在列表的中间，可能不会出现在列表中(给定模块损坏到无法报告)，或者在其他所有问题都完成后出现得很晚，这些问题都是由原始故障造成的。无论如何，在系统开发人员之外，很少有人能够正确地解释日志并想出实际发生的事情。

我目前的任务是编写一个模块来完成对客户友好的故障报告。也就是说，收集所有在最后~3秒内报告的事件(这大约是故障发生的起源和最后的后续效应之间的最大间隔)，对这些数据进行一些神奇的处理，并给出一条清晰、友好的线路--什么是断的，哪些需要修复。

问题是神奇的部分:如何给出一些故障报告，提出原来的故障来源。没有简单的因果列表。有一些常见的事件链，显示出一定的规律性。

示例：

检测到

• 短路，导致运行方式有限，限制运行不排除故障，因此紧急状态升级，总输出功率的
• 线路被接通。由于没有模块报告在3s内与其接合，因此“未知源或干扰”被认为是系统停止运行的原因，
• 大多数输出模块都没有输出电压。大约1s后，电源监控模块报告电源中断，这是最初的原因。
• 是一个输出模块，它的所有输出线路都没有输出电压。电源模块没有报告。原因是与模块断开的电力线。
• 是一个输出模块，它的输出线路中没有输出电压。没有其他故障报告。原因是导火索烧坏了，输出模块
• 没有返回应用接收状态。不久之后，控制模块报告非法的状态或输出行，(这是因为输出模块实际上没有及时更新状态)。其原因是输出模块(引入故障)，而不是控制模块(由于检测到故障而使系统停止运行)。
• 是输入模块的故障，将设备切换到备份故障安全模式。到目前为止还没有使用的输出模块(故障)会陷入这种模式，并且故障模式会升级到关键模式。最初的原因不是输入，它允许报告与错误有关的错误，但中断operation.
• there的备份输出在最后2秒内不是输出模块中的任何类型的活动。这意味着它坏了，必须输入故障模式。

关于什么是什么原因，没有全面的规则清单。这些规则将在“野外”出现新的故障类型时增加，并进行诊断和修正。其中一些是启发式的--如果这个错误与这些错误同时存在，那么这个错误很可能就是这样。一些错误是无法解决的--一个乏味的模块报告列表就足够了。有些答案是模棱两可的，一组症状可能暗示着两种不同的错误。这与其说是“有保障的解决方案”，不如说是“最大的努力”。

现在对于(过于笼统和模糊的)问题:如何解决这个问题？对于这类问题，是否有具体的算法、方法或广义解？如何编写广义规则集并与其匹配？如何进行软匹配？(比方说，一个输入模块在紧急停机时突然中断，这是一个完全不相关的事件，应该被忽略。)请帮帮忙？

Answer 1

老实说，我只会写一系列简单的规则就可以了。这将是一个痛苦的维护明智，但得到正确的可能是耗时和脆弱的。

如果您坚持，我会让每个错误为每个错误代码删除某种符号/标记-如果您尝试进行一些单词/关键字匹配，这将变得更加困难。然后将输出的令牌输入到某种分类器中。

在本质上，你需要某种规则引擎--不管是模糊的还是精确的。首先想到的是手工建立的贝叶斯网络。这将允许模糊匹配，因为您将计算最可能的“报告”作为您收到的令牌的函数。它还允许您通过指定返回答案的最小概率来设置令牌组的阈值，而这些令牌组并不真正表示任何内容。

您还可以训练一个Bayes网或其他类型的分类器，但是您需要手动标记的大量数据(token1、token2、token3 3->faultxyz)，而且自己做可能更准确。