Amazon Kinesis Data Firehose

向 Amazon S3 传输数据的频率由您为传输流配置的 Amazon S3 缓冲区大小和缓冲间隔值决定。Kinesis Data Firehose 在将传入数据传输到 Amazon S3 之前缓冲该数据。您可以配置 Amazon S3 缓冲区大小（1—128 MB）或缓冲间隔（60—900 秒）的值。满足的条件首先会触发数据传输到 Amazon S3。当向目标传输的数据落后于向传输流写入数据时，Kinesis Data Firehose 会动态增加缓冲区大小。之后，它将跟上并确保所有数据都传输到目标。

从 Amazon S3 到 Amazon Redshift 的数据COPY操作频率取决于您的 Amazon Redshift 集群完成COPY命令的速度。如果还有数据需要复制，则 Kinesis Data Firehose 将在上一个COPY命令由 Amazon Redshift 成功完成后立即COPY发出新命令。

向 OpenSearch 服务传输数据的频率由您为传输流配置的 OpenSearch 服务缓冲区大小和缓冲间隔值决定。Kinesis Data Firehose 在将传入数据传输到 OpenSearch S3 之前缓冲该数据。您可以配置 OpenSearch 服务缓冲区大小（1—100 MB）或缓冲间隔（60—900 秒）的值，满足的条件会首先触发向 OpenSearch 服务传输数据。

向 OpenSearch Serverless 传输数据的频率由您为传输流配置的 OpenSearch 无服务器缓冲区大小和缓冲间隔值决定。Kinesis Data Firehose 在将传入数据传输到 OpenSearch Serverlese 之前缓冲该数据。您可以配置 OpenSearch无服务器缓冲区大小（1—100 MB）或缓冲间隔（60—900 秒）的值，满足的条件会首先触发向 OpenSearch 无服务器传输数据。

Kinesis Data Firehose 在将传入数据传输到 Splunk 之前缓冲该数据。缓冲区大小为 5 MB，缓冲间隔为 60 秒。先满足的条件将触发到 Splunk 的数据传输操作。无法配置缓冲区大小和间隔。这些数字是最佳的。

Kinesis Data Firehose 在将传入数据传输到指定的 HTTP 端点目标之前缓冲该数据。目标的推荐缓冲区大小因服务提供商而异。例如，Datadog 的推荐缓冲区大小为 4，New Relic MiBs 和 Sumo Logic 的推荐缓冲区大小为 1 MiB。有关其推荐缓冲区大小的更多信息，请联系您选择其终端节点作为数据目的地的第三方服务提供商。

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

对于 Amazon Redshift 目的地，您可以在创建传送流时指定重试持续时间（0—7200 秒）。

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

对于 OpenSearch 服务和 OpenSearch 无服务器目标，可以在创建传输流时指定重试持续时间（0—7200 秒）。

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

对于 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 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)"
}
                    

当 Kinesis Data Firehose 向 Splunk 发送数据时，它会等待 Splunk 的确认。如果发生错误，或者确认未在确认超时期限内到达，Kinesis Data Firehose 将启动重试持续时间计数器。它将不断重试，直到重试持续时间到期。之后，Kinesis Data Firehose 认为这是数据传输失败，并将数据备份到你的 Amazon S3 存储桶中。

每当 Kinesis Data Firehose 向 Splunk 发送数据时，无论是初次尝试还是重试，它都会重新启动确认超时计数器。然后，等待 Splunk 的确认。即使重试时间到期，Kinesis Data Firehose 仍会等待确认，直到收到确认或达到确认超时为止。如果确认超时，Kinesis 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. Kinesis Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.",
  "attemptEndingTimestamp": 13626284715507,
  "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==",
  "EventId": "49577193928114147339600778471082492393164139877200035842.0"
}

当 Kinesis Data Firehose 将数据发送到 HTTP 端点目标时，它会等待来自该目标的响应。如果发生错误，或者响应未在响应超时期限内到达，Kinesis Data Firehose 将启动重试持续时间计数器。它将不断重试，直到重试持续时间到期。之后，Kinesis Data Firehose 认为这是数据传输失败，并将数据备份到你的 Amazon S3 存储桶中。

每当 Kinesis Data Firehose 向 HTTP 端点目标发送数据时，无论是初次尝试还是重试，它都会重新启动响应超时计数器。然后，它等待来自 HTTP 端点目标的响应。即使重试时间到期，Kinesis Data Firehose 仍会等待响应，直到收到响应或达到响应超时为止。如果响应超时，Kinesis 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"
}