图表问题排查和限制

编辑

图表问题排查和限制

编辑

为什么结果会缺失?

编辑

Graph API 请求中的默认设置被配置为通过以下策略来过滤掉噪声结果:

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

这些对于从噪声数据中获取“大局”信号很有用,但它们可能会遗漏单个文档的详细信息。如果您需要执行详细的取证分析,您可以调整以下设置以确保图表探索生成所有相关数据

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

我能做些什么来提高性能?

编辑

在默认设置 use_significancetrue 的情况下,Graph API 会对其在探索过程中发现的词条执行后台频率检查。每个唯一的词条都必须在索引中查找其频率,这至少需要一次磁盘寻道。磁盘寻道很昂贵。如果您不需要执行此噪声过滤,将 use_significance 设置为 false 会消除所有这些昂贵的检查(代价是不对词条执行任何质量过滤)。

如果您的数据有噪声,并且需要根据显著性进行过滤,您可以通过以下方式减少频率检查的次数:

  • 减小 sample_size。当匹配质量变化很大时,考虑较少的文档实际上可能更好。
  • 避免具有大量词条的噪声文档。您可以通过允许排名自然地偏向顶部结果样本中较短的文档(请参阅启用规范化)或通过使用您的种子和引导查询显式排除大型文档来实现。
  • 增加频率阈值。许多词条出现的频率非常低,因此即使将频率阈值增加一个也可以大大减少检查背景频率的候选词条的数量。

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

对多个索引的有限支持

编辑

Graph API 可以在单个 API 请求中探索多个索引、类型或别名,但假设它执行的每个“跳跃”都在查询同一组索引。目前,不可能从一个索引的字段中获取一个词条,并使用该值来探索在另一个类型或索引中 *不同字段* 中持有的连接。

一个很好的例子是,如果在名为“weblogs20160101”的索引的 remote_host 字段中找到了 IP 地址,您可能希望在名为“knownthreats”的索引的 ip_address 字段中查找相同的地址。

支持此行为需要额外的映射来指示 weblogs 的 remote_host 字段包含在威胁索引的 ip_address 字段中具有实际意义和含义的值。

由于我们目前不支持这种转换,您必须执行多次调用才能从 weblogs 索引响应中获取值,并将它们构建到对威胁索引的单独请求中。