处理延迟数据
延迟数据是指延迟索引的文档。也就是说，这些数据所关联的时间点，您的数据馈送（datafeed）已经处理过了，因此它们从未被您的异常检测作业所分析。
创建数据馈送时，您可以指定 query_delay 设置。此设置使数据馈送能够在实时时间之后等待一段时间，这意味着在此期间的任何“延迟”数据在数据馈送尝试收集它们之前已完全索引。但是，如果设置得太低，数据馈送可能会在数据被索引之前查询数据，从而导致错过该文档。相反，如果设置得太高，分析会偏离实时时间。所达到的平衡取决于每个用例和集群的环境因素。
如果您收到一条显示 Datafeed missed XXXX documents due to ingest latency 的错误消息，请考虑增加 query_delay 的值。如果这没有帮助，请调查摄取延迟及其原因。您可以通过比较事件时间戳和摄取时间戳来完成此操作。高延迟通常是由突发的已摄取文档、摄取管道配置错误或系统时钟未对齐引起的。
如果数据是随机延迟的（从而导致分析中缺失），某些类型的函数的结果实际上不会受到影响。在这些情况下，最终结果是可以接受的，因为延迟的数据是随机分布的。例如，大数据集合中某个字段的 mean（平均值）指标。在这种情况下，检查延迟数据可能不会带来太大好处。但是，如果数据持续延迟，使用 low_count 函数的异常检测作业可能会产生误报。在这种情况下，查看数据是否在记录异常后才到达会很有用，这样您就可以确定下一步的行动方针。
除了 query_delay 字段外，还有一个延迟数据检查配置，它使您能够配置数据馈送以查找过去出现的延迟数据。每 15 分钟或每 check_window（以较小者为准），数据馈送就会对配置的索引触发一次文档搜索。此搜索会查看一个长度为 check_window 的时间跨度，该跨度以最新的已完成存储桶（finalized bucket）结束。该时间跨度被划分为若干存储桶，其长度等于相关异常检测作业的存储桶跨度（bucket span）。然后，将这些存储桶的 doc_count 与作业的已完成分析存储桶进行比较，以查看自分析以来是否有数据到达。如果确实因摄取延迟而导致数据缺失，最终用户会收到通知。例如，您可以在 Kibana 中看到这些延迟发生时段的注释（annotations）
在以下情况下，延迟数据检查将无法正常工作
- 如果数据馈送使用过滤数据的聚合，
- 如果数据馈送使用聚合，并且作业的
analysis_config没有将其summary_count_field_name设置为doc_count， - 如果数据馈送未使用聚合，并且
summary_count_field_name设置为任何值。
如果数据馈送正在使用聚合，请将作业的 summary_count_field_name 设置为 doc_count。如果 summary_count_field_name 设置为 doc_count 以外的任何值，则必须禁用该数据馈送的延迟数据检查。
在异常检测作业管理页面的 Annotations（注释）选项卡上，还有另一个用于可视化延迟数据的工具
最常见的处理方法是什么都不做。对于许多函数和情况，忽略这些数据是可以接受的。然而，如果延迟数据的数量太多，或者情况需要，下一步要考虑的行动是增加数据馈送的 query_delay。这种增加的延迟为数据索引留出了更多时间。但是，如果您有实时性限制，那么增加延迟可能并不理想。在这种情况下，您必须调整以提高索引速度。