处理数据传输失败 - Amazon Data Firehose

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

处理数据传输失败

每个 Amazon Data Firehose 目的地都有自己的数据传输失败处理流程。

在设置 Firehose 流时,对于许多目的地(例如 OpenSearch Splunk 和HTTP终端节点),您还会设置一个 S3 存储桶,用于备份未能交付的数据。有关 Firehose 在传输失败时如何备份数据的更多信息,请参阅此页的相关目的地部分。有关如何授予对 S3 存储桶的访问权限以备份无法传输的数据的更多信息,请参阅授予 Firehose 访问 Amazon S3 目的地的权限。当 Firehose(a)无法将数据传输到流目的地,并且(b)无法将数据写入传输失败的备份 S3 存储桶时,实际上会暂停流传输,直到数据可以传输到目的地或写入备份 S3 位置。

Amazon S3

到 S3 存储桶的数据传输可能会由于某些原因而失败。例如,该存储桶可能已不存在,Amazon Data Firehose 担任的IAM角色可能无法访问该存储桶、网络出现故障或类似事件。在此类情况下,Amazon Data Firehose 会在 24 小时内持续重试,直到传输成功。Amazon Data Firehose 的最长数据存储时间为 24 小时。如果数据传输失败超过 24 小时,数据将丢失。

由于各种原因,向 S3 存储桶传输数据可能会失败,例如:

  • 该存储桶已不存在。

  • Amazon Data Firehose 担任的IAM角色无法访问存储桶。

  • 网络问题。

  • S3 错误,例如 HTTP 500 或其他API故障。

在这些情况下,Amazon Data Firehose 将重试配送:

  • DirectPut 来源:重试最长可持续 24 小时。

  • Kinesis Data Streams MSK 或 Amazon 来源:重试会无限期持续下去,具体取决于直播中定义的保留策略。

只有在 Lambda 处理或 parquet 转换失败时,Amazon Data Firehose 才会将失败的记录传送到 S3 错误存储桶。其他失败情况将导致持续重试 S3,直到达到保留期为止。当 Firehose 成功将记录传送到 S3 时,它会创建一个 S3 对象文件;在部分记录失败的情况下,它会自动重试传送,并使用成功处理的记录更新同一 S3 对象文件。

Amazon Redshift

对于 Amazon Redshift 目的地,您可以在创建 Firehose 流时指定重试持续时间(0–7200 秒)。

将数据传输到 Amazon Redshift 预置集群或 Amazon Redshift Serverless 工作组时,可能会因为以下几个原因而失败。例如,Firehose 流的集群配置不正确、集群或工作组正在维护或网络故障。在此类情况下,Amazon Data Firehose 会在指定的持续时间内重试,并跳过特定批次的 Amazon S3 对象。跳过的对象的信息会以清单文件的形式传输到您的 S3 存储桶中的 errors/ 文件夹内,您可以利用该清单文件进行手动回填。有关如何使用清单文件手动进行COPY数据处理的信息,请参阅使用清单指定数据文件

Amazon OpenSearch 服务和 OpenSearch无服务器

对于 OpenSearch 服务和 OpenSearch 无服务器目标,您可以在 Firehose 直播创建期间指定重试持续时间(0—7200 秒)。

由于多种原因,向您的 OpenSearch 服务集群或 OpenSearch 无服务器集合传输数据可能会失败。例如,您的 Firehose 流可能存在错误的 OpenSearch 服务集群或 OpenSearch 无服务器集合配置、 OpenSearch 正在维护的服务集群 OpenSearch 或无服务器集合、网络故障或类似事件。在此类情况下,Amazon Data Firehose 会在指定的持续时间内重试,并跳过特定的索引请求。跳过的文档会传输到您的 S3 存储桶中的 AmazonOpenSearchService_failed/ 文件夹内,您可以利用它进行手动回填。

对于 S OpenSearch ervice,每个文档都JSON采用以下格式:

{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Service)", "errorMessage": "(error message returned by OpenSearch Service)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "esDocumentId": "(intended OpenSearch Service document ID)", "esIndexName": "(intended OpenSearch Service index name)", "esTypeName": "(intended OpenSearch Service type name)", "rawData": "(base64-encoded document data)" }

对于 OpenSearch 无服务器,每个文档都JSON采用以下格式:

{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Serverless)", "errorMessage": "(error message returned by OpenSearch Serverless)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "osDocumentId": "(intended OpenSearch Serverless document ID)", "osIndexName": "(intended OpenSearch Serverless index name)", "rawData": "(base64-encoded document data)" }

Splunk

当 Amazon Data Firehose 向 Splunk 发送数据时,会等待 Splunk 的确认。如果出现错误或未在确认超时期限内收到确认,Amazon Data Firehose 将启动重试持续时间计数器。它将不断重试,直到重试持续时间到期。重试持续时间到期后,Amazon Data Firehose 将这种情况视为数据传输失败,并将数据备份到 Amazon S3 存储桶。

每次 Amazon Data Firehose 向 Splunk 发送数据时,无论是首次尝试还是重试,都会重新启动确认超时计数器。然后,等待 Splunk 的确认。即使重试持续时间已过,Amazon Data Firehose 仍会等待确认,直到收到确认或确认超时。如果确认超时,Amazon Data Firehose 会检查重试计数器是否还有剩余时间。如果有剩余时间,它将再次重试并重复该逻辑,直到收到确认或确定重试时间已到期。

未收到确认并不是可能出现的唯一一类数据传输错误。有关其他类型的数据传输错误的信息,请参阅 Splunk 数据传输错误。如果重试持续时间大于 0,任何数据传输错误都会触发重试逻辑。

下面是一个错误记录示例。

{ "attemptsMade": 0, "arrivalTimestamp": 1506035354675, "errorCode": "Splunk.AckTimeout", "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.", "attemptEndingTimestamp": 13626284715507, "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==", "EventId": "49577193928114147339600778471082492393164139877200035842.0" }

HTTP端点目的地

当 Amazon Data Firehose 向HTTP终端节点目标发送数据时,它会等待该目标的响应。如果出现错误或未在响应超时期限内收到响应,Amazon Data Firehose 将启动重试持续时间计数器。它将不断重试,直到重试持续时间到期。重试持续时间到期后,Amazon Data Firehose 将这种情况视为数据传输失败,并将数据备份到 Amazon S3 存储桶。

每次 Amazon Data Firehose 向HTTP终端节点目标发送数据时,无论是初次尝试还是重试,都会重新启动响应超时计数器。然后,它会等待来自HTTP终端节点目的地的响应。即使重试持续时间已过,Amazon Data Firehose 仍会等待响应,直到收到响应或响应超时。如果响应超时,Amazon Data Firehose 会检查重试计数器是否还有剩余时间。如果还有时间,会再次重试并重复逻辑,直到收到响应或确定重试时间已过期。

未收到响应并不是唯一可能发生的数据传输错误类型。有关其他类型的数据传输错误的信息,请参阅HTTP端点数据传输错误

下面是一个错误记录示例。

{ "attemptsMade":5, "arrivalTimestamp":1594265943615, "errorCode":"HttpEndpoint.DestinationException", "errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", "attemptEndingTimestamp":1594266081318, "rawData":"c2FtcGxlIHJhdyBkYXRh", "subsequenceNumber":0, "dataId":"49607357361271740811418664280693044274821622880012337186.0" }

Snowflake

对于 Snowflake 目的地,在创建 Firehose 流时,您可以指定可选的重试持续时间(0–7200 秒)。重试持续时间的默认值是 60 秒。

向 Snowflake 表传输数据可能会失败,原因有很多,例如 Snowflake 目的地配置不正确、Snowflake 中断、网络故障等。重试策略不适用于不可重试的错误。例如,如果 Snowflake 因为表格中缺少多一列而拒绝了你的JSON有效载荷,那么 Firehose 就不会尝试再次交付它。相反,它会为由于 S3 错误存储桶的JSON有效负载问题而导致的所有插入失败创建备份。

同样,如果由于角色、表或数据库错误而导致传输失败,则 Firehose 不会重试并将数据写入您的 S3 存储桶。重试持续时间仅适用于因 Snowflake 服务问题、临时网络故障等导致的失败。在此类情况下,Firehose 会在指定的持续时间内重试,然后再将它们传输到 S3。失败的记录将传输在 snowflake-failed/ 文件夹中,您可以使用该文件夹进行手动回填。

以下是您传送到 S3 JSON 的每条记录的示例。

{ "attemptsMade": 3, "arrivalTimestamp": 1594265943615, "errorCode": "Snowflake.InvalidColumns", "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation", "attemptEndingTimestamp": 1712937865543, "rawData": "c2FtcGxlIHJhdyBkYXRh" }