转换检查点的运作方式
编辑转换检查点的运作方式编辑
每次转换检查源索引并创建或更新目标索引时,它都会生成一个*检查点*。
如果您的转换只运行一次,那么逻辑上只有一个检查点。但是,如果您的转换持续运行,它会在提取和转换新的源数据时创建检查点。转换的 sync
属性通过指定时间字段来配置检查点。
要创建检查点,持续转换会执行以下操作:
-
检查源索引的更改。
转换使用简单的定期计时器检查源索引的更改。此检查基于转换的
frequency
属性中定义的间隔执行。如果源索引保持不变,或者检查点已在进行中,则它会等待下一个计时器。
如果发现更改,则会创建检查点。
-
识别哪些实体和/或时间桶已更改。
转换会搜索在上一个检查点和新检查点之间哪些实体或时间桶发生了变化。转换使用这些值来同步源索引和目标索引,操作次数比完全重新运行要少。
-
使用更改更新目标索引(数据框)。
转换将与新的或已更改的实体或时间桶相关的更改应用于目标索引。更改集可以分页。转换执行类似于批处理转换操作的复合聚合,但它还会注入基于上一步的查询过滤器,以减少工作量。应用所有更改后,检查点即完成。
此检查点过程涉及集群上的搜索和索引活动。在开发转换时,我们尝试优先考虑对性能的控制。我们认为,转换花费更长时间完成比快速完成并优先占用资源更可取。话虽如此,集群仍然需要足够的资源来支持复合聚合搜索及其结果的索引。
如果集群由于转换而遇到不合适的性能下降,请停止转换并参考性能注意事项。
使用提取时间戳同步转换编辑
在大多数情况下,强烈建议使用源索引的提取时间戳来同步转换。这是转换能够识别新更改的最佳方式。如果您的数据源遵循ECS 标准,则您可能已经拥有event.ingested
字段。在这种情况下,请使用 event.ingested
作为转换的 sync
.time
.field
属性。
如果您没有 event.ingested
字段或该字段未填充,则可以使用提取管道进行设置。使用提取管道 API(如下例所示)或通过 Kibana 在堆栈管理 > 提取管道下创建提取管道。使用set
处理器设置字段并将其与提取时间戳的值相关联。
response = client.ingest.put_pipeline( id: 'set_ingest_time', body: { description: 'Set ingest timestamp.', processors: [ { set: { field: 'event.ingested', value: '{{{_ingest.timestamp}}}' } } ] } ) puts response
PUT _ingest/pipeline/set_ingest_time { "description": "Set ingest timestamp.", "processors": [ { "set": { "field": "event.ingested", "value": "{{{_ingest.timestamp}}}" } } ] }
创建提取管道后,将其应用于转换的源索引。管道会将字段 event.ingested
添加到每个文档中,并将其值设置为提取时间戳。使用创建转换 API(对于新转换)或更新转换 API(对于现有转换)将转换的 sync
.time
.field
属性配置为使用该字段。 event.ingested
字段用于同步转换。
有关如何使用提取管道的更多信息,请参阅将管道添加到索引请求和提取管道。
更改检测启发式方法编辑
当转换在连续模式下运行时,它会在新数据传入时更新目标索引中的文档。转换使用一组称为更改检测的启发式方法来更新目标索引,从而减少操作次数。
在此示例中,数据按主机名分组。更改检测会检测哪些主机名已更改,例如主机 A
、C
和 G
,并且仅更新具有这些主机的文档,而不会更新存储有关主机 B
、D
或任何其他未更改的主机的信息的文档。
当使用 date_histogram
按时间桶分组时,可以对时间桶应用另一种启发式方法。更改检测会检测哪些时间桶已更改,并且仅更新这些时间桶。
错误处理编辑
转换中的失败通常与搜索或索引有关。为了提高转换的弹性,聚合搜索和已更改实体搜索的游标位置会在内存中跟踪并定期持久化。
检查点故障可以分为以下几类:
- 临时故障:将重试检查点。如果连续发生 10 次故障,则转换将处于失败状态。例如,当出现分片故障并且查询仅返回部分结果时,可能会发生这种情况。
- 不可恢复的故障:转换立即失败。例如,当找不到源索引时,就会发生这种情况。
- 调整故障:转换将使用调整后的设置重试。例如,如果在复合聚合期间发生父断路器内存错误,则转换将收到部分结果。聚合搜索将使用较少的桶数重试。此重试按照转换的
frequency
属性中定义的间隔执行。如果搜索重试到达到最小桶数,则会发生不可恢复的故障。
如果运行转换的节点失败,则转换将从最近持久化的游标位置重新启动。此恢复过程可能会重复转换已经完成的一些工作,但它可以确保数据一致性。