我的老板说，当前状态的日志对客户来说是不可接受的。如果发生故障，设备中的十几个不同模块会报告各自的错误，并且都记录在日志中。故障的根本原因可能埋藏在列表的中间，可能根本没有出现在列表中（因为模块损坏太严重而无法报告），或者在其他所有模块报告了由根本故障引起的后果后才出现。无论如何，除了系统开发人员之外，很少有人能够正确解释日志并弄清楚实际发生了什么。

我现在的任务是编写一个客户友好的故障报告模块。也就是说，收集过去约 3 秒钟内报告的所有事件（这大约是从故障发生到最后产生的后遗症之间的最大间隔），对这些数据进行一些神奇的处理，并得出一个清晰友好的行，说明哪里坏了，需要修复。

问题在于“神奇”的部分：如何在给定数量的故障报告的情况下，找出故障的原始来源。没有简单的因果关系列表。只有经常出现的事件链显示出一定的规律性。

例子：

• 检测到短路，导致限制操作模式，限制操作模式无法消除故障，因此紧急状态升级，总输出功率断开。
• 安全线被启用。自安全线启用后的 3 秒内，没有模块报告启用它，因此将“未知来源或干扰”归因于系统停止的原因。
• 大多数输出模块报告没有输出电压。大约 1 秒后，电源监控模块报告电源已关闭，这是根本原因。
• 一个输出模块报告其所有输出线都没有输出电压。没有来自电源模块的报告。原因是电源线与模块断开连接。
• 一个输出模块报告其一条输出线没有输出电压。没有报告其他故障。原因是保险丝烧断。
• 一个输出模块没有报告应用收到的状态。此后不久，控制模块报告非法状态或输出线（这是因为输出模块确实没有及时更新状态）。原因是输出模块（导致故障的原因），而不是控制模块（由于检测到故障而停止了系统）。
• 输入模块的故障将设备切换到备用故障安全模式。一个到目前为止未使用的输出模块（有故障）在这种模式下被启用，并且故障模式升级为关键。最初的原因不是输入，允许输入报告有关故障的误报，而是中止操作的损坏的备用输出。
• 在过去的 2 秒钟内，输出模块没有任何活动。这意味着它已损坏，必须进入故障模式。

没有关于什么导致什么的全面规则列表。这些规则将在“野外”发生并诊断和修复新的故障类型时添加。其中一些是启发式的 – 如果此错误伴随这些错误，则故障很可能是这样。有些故障无法解决 – 一份平淡的模块报告清单就足够了。有些答案会模棱两可，一组症状可能表明两种不同的故障。这更多的是一种“尽最大努力”而不是“保证解决方案”。

现在提出（过于笼统和模糊的）问题：如何解决这个问题？是否有针对此类问题的特定算法、方法或通用解决方案？如何编写通用的规则集并进行匹配？如何进行软匹配？（例如，一个输入模块在紧急停止过程中突然发生故障，这是一个完全无关的事件，应该忽略。）请帮忙？

回答：

说实话，我只会编写一系列简单的规则来完成它。维护起来会很痛苦，但是要正确完成这项工作可能会很耗时且脆弱。

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

核心在于，您需要某种规则引擎 – 无论是模糊的还是精确的。首先想到的是手动构建的贝叶斯网络。这将允许模糊匹配，因为您可以将最可能的“报告”计算为收到的令牌的函数。它还允许您通过指定返回答案的最小概率来为实际上不指示任何内容的令牌组设置阈值。

您也可以训练贝叶斯网络或其他类型的分类器，但是您需要相当多的手动标记的数据（token1,token2,token3->faultxyz），并且自己做可能会更准确。