故障排除和限制

Elastic Stack Serverless

Graph API 请求中的默认设置通过使用以下策略进行配置，以消除嘈杂的结果：

• 只查看查询最相关文档的样本
• 只考虑与样本具有显著统计相关性的词条
• 只考虑至少有 3 个文档断言该连接的词条对

这些是获取嘈杂数据中“大局”信号的有用默认值，但它们可能会错过单个文档的详细信息。如果您需要执行详细的取证分析，可以调整以下设置，以确保图探索产生所有相关数据：

• 将 sample_size 增加到更大的文档数量，以分析每个分片上的更多数据。
• 将 use_significance 设置为 false，以检索词条，而不考虑与样本的任何统计相关性。
• 将顶点的 min_doc_count 设置为 1，以确保只需要一个文档来断言关系。

当 use_significance 的默认设置为 true 时，Graph API 会在探索过程中对发现的词条执行后台频率检查。每个唯一词条都需要在其索引中查找频率，这至少需要一次磁盘寻道。磁盘寻道成本很高。如果您不需要执行这种噪声过滤，将 use_significance 设置为 false 可以消除所有这些昂贵的检查（但会牺牲任何质量过滤）。

如果您的数据很嘈杂，并且您需要根据显着性进行过滤，则可以通过以下方式减少频率检查的数量：

• 减小 sample_size。当匹配的质量差异很大时，考虑更少的文档实际上可能更好。
• 避免包含大量词条的嘈杂文档。您可以通过允许排名自然地在顶级结果样本中偏好较短的文档（请参阅 启用 norms）或通过在 seed 和引导查询中显式排除大型文档来实现。
• 提高频率阈值。许多词条的出现频率非常低，因此即使将频率阈值提高一倍，也可以大大减少需要检查其后台频率的候选词条数量。

请记住，所有这些选项都会减少分析的信息范围，并可能增加错过有趣细节的可能性。但是，丢失的信息倾向于与较低质量的文档和较低频率的词条相关联，这可能是一个可以接受的权衡。

Graph API 可以在单个 API 请求中探索多个索引、类型或别名，但其假设是它执行的每个“跳”都在查询同一组索引。目前，无法将从一个索引的字段中找到的词条用于探索另一种类型或索引中持有的不同字段中的连接。

一个很好的例子是，如果在名为“weblogs20160101”的索引的 remote_host 字段中找到 IP 地址，您可能希望通过查找该地址在名为“knownthreats”的索引的 ip_address 字段中的出现来跟进。

支持这种行为需要额外的映射来指示 weblogs 的 remote_host 字段包含在 threats 索引的 ip_address 字段中具有货币和意义的（有效）值。

由于我们目前不支持此翻译，您需要执行多次调用，将值从 weblogs 索引响应中提取出来，并将其构建到对 threats 索引的单独请求中。