基本事实、隐藏事实、间接事实、常量、词汇

基本事实

一条典型的追踪记录是一段详细的叙述，伴随一个问题描述，列出关键信息。因此，任何追踪分析的第一步就是检查追踪中是否包含基本事实。如果这些事实不明显或与问题描述不符，说明该追踪可能并非在问题发生时记录的，或是来自另一台计算机，或是在不同条件下生成的。

以下是一个示例：用户 test01 无法连接到终端服务环境中的发布应用程序。我们查看追踪记录，发现如下语句：

我们可以确信这条追踪是针对用户 test01 的，特别是当我们预期或看到类似的追踪语句时。如果未发现此类语句，则可能推测追踪记录的时间有误，例如问题已发生但已被解决。

我们建议采用以下基本事实分类：

• 功能事实：用户期望出现一个输入数据的对话框。
• 非功能事实：CPU 使用率达到 100%。
• 识别事实：包括应用程序名称、PID、用户名等。

隐含事实

前述模式（如基本事实和词汇索引）用于将问题描述映射到软件执行产物（如追踪和日志）。而间接事实分析模式则用于应对问题描述不完整的情况。然而，为了实现分析的完整性，我们还需要另一种模式，用于从日志映射到故障排查和调试建议。

通过追踪和日志分析所揭示的事实称为隐含事实。当然，这类事实可能有很多，通常是在将分析范围缩小至特定的活动线程、邻接线程、消息上下文、消息集合或数据流模式后才被发现。这一模式的需求源于对 Malcolm McCaffery 的追踪案例研究进行基于模式的分析过程中。其示意图如下：

间接事实

在某些情况下，当基本事实缺失时，我们仍可从消息文本及其他模式中推断出间接事实。例如，在某次事件中，我们关注某个特定进程名的所有消息，但问题描述中缺少其 PID。幸运的是，我们从另一个完全不同的来源的消息中获取了该进程的 PID。

追踪常量

每条追踪或日志都有其自身的常量集合，这些值属于全局命名空间，如 TRUE/FALSE、NULL、异常值，以及常见的错误常量如“access denied”。追踪常量可能依赖于实现话语。此外，还存在仅属于单个追踪的局部常量，例如用户名和 IP 地址。它们在一个日志中可能反复出现，但在另一个日志中可能发生变化。属于局部命名空间的常量可能是词汇索引和基本事实的一部分。通常，追踪常量不被视为消息不变量。

每条追踪或日志都有其自身的常量集合——属于全局命名空间的值，如 TRUE/FALSE、NULL、异常值，以及常见的错误常量如“access denied”。追踪常量可能依赖于实现话语。此外，还存在仅属于单个追踪的局部常量，如用户名和 IP 地址。它们在一个日志中可能反复出现，但在另一个日志中可能发生变化。属于局部命名空间的常量可能是词汇索引和基本事实的一部分。通常，追踪常量不被视为消息不变量。

词汇索引

当你面对一千万条在 10:44:15 到 10:46:55 之间记录的追踪消息，平均每秒产生 7,000 条消息，来自数十个模块，并且只有一个简短的问题描述时，你会怎么做？一种解决方案是尝试搜索与问题描述相关的特定词汇。例如，若问题是周期性重新认证，可以搜索关键词“password”或来自故障排查领域词汇表中的类似词。因此，拥有一个词汇索引来辅助查找非常有帮助。在我们的追踪示例中，搜索“password”直接定位到授权模块的小型活动区域，起始于消息编号 #180,010，最后一个“password”出现在消息 #180,490，这将初始分析范围缩小至仅 500 条消息。注意，书籍与其索引之间的关系，与追踪作为软件叙事与其词汇索引之间的关系极为相似。

当你面对一千万条在 10:44:15 到 10:46:55 之间记录的追踪消息，平均每秒产生 7,000 条消息，来自数十个模块，并且只有一个简短的问题描述时，你会怎么做？一种解决方案是尝试搜索与问题描述相关的特定词汇。例如，若问题是周期性重新认证，可以搜索关键词“password”或来自故障排查领域词汇表中的类似词。因此，拥有一个词汇索引来辅助查找非常有帮助。在我们的追踪示例中，搜索“password”直接定位到授权模块的小型活动区域，起始于消息编号 #180,010，最后一个“password”出现在消息 #180,490，这将初始分析范围缩小至仅 500 条消息。注意，书籍与其索引之间的关系，与追踪作为软件叙事与其词汇索引之间的关系极为相似。