Amazon Kinesis Data Firehose 问题排查 - Amazon Kinesis Data Firehose
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

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

Amazon Kinesis Data Firehose 问题排查

如果在传输或处理数据时 Kinesis Data Firehose 遇到错误,则它会一直重试,直至超过配置的重试持续时间。如果重试持续时间在成功传输数据之前结束,则 Kinesis Data Firehose 会将数据备份到配置的 S3 备份存储桶。如果目标为 Amazon S3 且传输过程失败,或者传输到备份 S3 存储桶失败,则 Kinesis Data Firehose 会继续重试,直至保留期结束。对于 DirectPut 传输流,Kinesis Data Firehose 将记录保留 24 小时。对于其数据源为 Kinesis 数据流的传输流,您可以按照更改数据保留期中的说明更改保留期。

如果数据源是Kinesis数据流, Kinesis Data Firehose 无限期重试以下操作: DescribeStream, GetRecords,和 GetShardIterator.

如果传输流使用 DirectPut,请检查 IncomingBytesIncomingRecords 指标,查看是否有传入流量。如果您正在使用 PutRecordPutRecordBatch,请务必捕获异常并重试。我们建议使用带指数退避的重试策略,并且提供抖动和多次重试功能。此外,如果您使用 PutRecordBatch API,确保您的代码检查的值 FailedPutCount 响应中,即使API调用成功。

如果传输流使用 Kinesis 数据流作为源,请检查源数据流的 IncomingBytesIncomingRecords 指标。此外,请确保为传输流发出 DataReadFromKinesisStream.BytesDataReadFromKinesisStream.Records 指标。

有关使用 CloudWatch 跟踪传输错误的信息,请参阅使用 Kinesis Data Firehose 监控 CloudWatch Logs

数据未传输到 Amazon S3

如果数据未传输到您的 Amazon Simple Storage Service (Amazon S3) 存储桶,请检查以下各项。

数据未传输到 Amazon Redshift

如果数据未传输到您的 Amazon Redshift 集群,请检查以下各项。

数据在加载到 Amazon Redshift 之前,先传输到 S3 存储桶。如果数据未传输至 S3 存储桶,请参阅数据未传输到 Amazon S3

  • 检查 Kinesis Data Firehose DeliveryToRedshift.Success 指标,确保 Kinesis Data Firehose 已尝试将数据从您的 S3 存储桶复制到 Amazon Redshift 集群。有关更多信息,请参阅使用 CloudWatch 指标监控 Kinesis Data Firehose

  • 如果尚未启用错误日志记录功能,则启用它并检查是否存在传输失败错误日志。有关更多信息,请参阅使用 Kinesis Data Firehose 监控 CloudWatch Logs

  • 检查 Amazon Redshift STL_CONNECTION_LOG 表,确定 Kinesis Data Firehose 能否成功建立连接。在该表中,应该能够根据用户名查看连接及其状态。有关更多信息,请参阅 STL_CONNECTION_LOGAmazon Redshift Database Developer Guide.

  • 如果上一个检查表明已建立连接,则检查 Amazon Redshift STL_LOAD_ERRORS 表来确认 COPY 失败的原因。有关更多信息,请参阅 STL_LOAD_ERRORSAmazon Redshift Database Developer Guide.

  • 确保 Kinesis Data Firehose 传输流 中的 Amazon Redshift 配置正确且有效。

  • 确保在 Kinesis Data Firehose 传输流 中指定的 IAM 角色可以访问 Amazon Redshift 从中复制数据的 S3 存储桶以及用于数据转换的 Lambda 函数(如果启用了数据转换)。有关更多信息,请参阅授予 Kinesis Data Firehose 访问 Amazon S3 目标的权限

  • 如果 Amazon Redshift 集群位于虚拟私有云 (VPC) 中,则确保该集群允许从 Kinesis Data Firehose IP 地址进行访问。有关更多信息,请参阅授予 Kinesis Data Firehose 访问 Amazon Redshift 目标的权限

  • 确保 Amazon Redshift 集群可公开访问。

  • 如果您使用数据转换,请确保您的 Lambda 函数决不会返回其负载大小超过 6 MB 的响应。有关更多信息,请参阅 Amazon Kinesis Data Firehose 数据转换

数据未传输到 Amazon Elasticsearch Service

如果数据未传输至您的 Elasticsearch 域,请检查以下各项。

数据可以同时备份到 Amazon S3 存储桶。如果数据未传输至您的 S3 存储桶,请参阅数据未传输到 Amazon S3

数据未传输到 Splunk

如果数据未传输到您的 Splunk 终端节点,请检查以下各项。

  • 如果您的 Splunk 平台在 VPC 中,请确保 Kinesis Data Firehose 可以访问它。有关更多信息,请参阅在 VPC 中访问 Splunk

  • 如果您使用 AWS 负载均衡器,请确保它是 传统负载均衡器。Kinesis Data Firehose 不支持 Application Load Balancer 或 Network Load Balancer。此外,启用基于持续时间的粘性会话,并禁用 Cookie 过期。有关如何执行此操作的信息,请参阅基于持续时间的会话粘性

  • 检查 Splunk 平台要求。适用于 Kinesis Data Firehose 的 Splunk 插件需要 6.6.X 或更高版本的 Splunk 平台。有关更多信息,请参阅适用于 Amazon Kinesis Firehose 的 Splunk 插件

  • 如果 Kinesis Data Firehose 和 HTTP 事件收集器 (HEC) 节点之间有代理(Elastic Load Balancing 或其他),请启用粘性会话来支持 HEC 确认 (ACK)。

  • 确保您使用有效的 HEC 令牌。

  • 确保启用了 HEC 令牌。请参阅 Enable and disable Event Collector tokens

  • 检查是否为发送到 Splunk 的数据正确设置格式。有关更多信息,请参阅为 HTTP 事件收集器的事件设置格式

  • 确保为 HEC 令牌和输入事件配置了有效索引。

  • 如果由于 HEC 节点出现服务器错误而无法上传到 Splunk,将会自动重试该请求。如果所有重试均失败,则会将数据备份到 Amazon S3 中。检查您的数据是否出现在 Amazon S3 中,这表明出现了此类失败。

  • 确保在您的 HEC 令牌上启用了索引器确认。有关更多信息,请参阅启用索引器确认

  • 在您的 Kinesis Data Firehose 传输流的 Splunk 目标配置中提高 HECAcknowledgmentTimeoutInSeconds 的值。

  • 在您的 Kinesis Data Firehose 传输流的 Splunk 目标配置中提高 RetryOptions 下的 DurationInSeconds 的值。

  • 检查 HEC 的运行状况。

  • 如果您使用数据转换,请确保您的 Lambda 函数决不会返回其负载大小超过 6 MB 的响应。有关更多信息,请参阅 Amazon Kinesis Data Firehose 数据转换

  • 确保Splunk参数名为 ackIdleCleanup 设定为 true。默认情况下,它是假的。若要将此参数设置为 true,请执行以下操作:

    • 对于托管 Splunk 云部署,请使用 Splunk 支持门户提交案例。在此情况下,应请求 Splunk 支持人员启用 HTTP 事件收集器,在 inputs.conf 中将 ackIdleCleanup 设置为 true,并创建或修改要用于此插件的负载均衡器。

    • 对于分布式 Splunk Enterprise 部署,请将 inputs.conf 文件中的 ackIdleCleanup 参数设置为 true。对于*nix个用户,此文件位于 $SPLUNK_HOME/etc/apps/splunk_httpinput/local/。对于Windows用户,它位于 %SPLUNK_HOME%\etc\apps\splunk_httpinput\local\.

    • 对于单实例 Splunk Enterprise 部署,请将 inputs.conf 文件中的 ackIdleCleanup 参数设置为 true。对于*nix个用户,此文件位于 $SPLUNK_HOME/etc/apps/splunk_httpinput/local/。对于Windows用户,它位于 %SPLUNK_HOME%\etc\apps\splunk_httpinput\local\.

  • 请参阅 Amazon Kinesis Firehose 的 Splunk 插件故障排除

传输流不可用作 CloudWatch Logs、CloudWatch Events 或 AWS IoT 操作的目标

某些 AWS 服务只能将消息和事件发送到位于同一 AWS 区域中的 Kinesis Data Firehose 传输流。验证您的 Kinesis Data Firehose 传输流是否与其他服务位于同一区域。

数据新鲜度指标增长或未发出数据新鲜度指标

数据新鲜度用于衡量您的数据在传输流中的最新程度。它指的是传输流中最早数据记录的期限,从 Kinesis Data Firehose 接收数据的时间到当前时间进行衡量。Kinesis Data Firehose 提供了可用于监控数据新鲜度的指标。要确定指定目标的数据新鲜度指标,请参阅使用 CloudWatch 指标监控 Kinesis Data Firehose

如果您为所有事件或所有文档启用备份,请监控两个单独的数据新鲜度指标:一个用于主目标,另一个用于备份。

如果未发出数据新鲜度指标,则意味着传输流没有有效的传输。当完全阻止数据传输或没有任何传入数据时,会发生这种情况。

如果数据新鲜度指标在不断增加,则意味着数据传输落后。这可能是由于以下原因之一。

  • 目标无法跟上传输速率。如果由于高流量而导致 Kinesis Data Firehose 临时遇到错误,则传输可能会落后。Amazon S3 以外的目标可能会发生这种情况(Amazon Elasticsearch Service、Amazon Redshift 或 Splunk 可能会发生)。确保您的目标有足够的容量来处理传入流量。

  • 目标非常慢。如果 Kinesis Data Firehose 遇到高延迟,则数据传输可能会落后。监控目标的延迟指标。

  • Lambda 运行地非常慢。这可能导致数据传输速率要低于传输流的数据接收速率。如果可能,请改进 Lambda 函数的效率。例如,如果函数处理网络 IO,请使用多个线程或异步 IO 来增加并行度。此外,考虑增加 Lambda 函数的内存大小,以便相应地增加 CPU 分配。这可能会导致 Lambda 调用更快。有关配置 Lambda 函数的信息,请参阅配置 AWS Lambda 函数

  • 在数据传输过程中出现故障。有关如何使用 Amazon CloudWatch Logs 监控错误的信息,请参阅使用 Kinesis Data Firehose 监控 CloudWatch Logs

  • 如果传输流的数据源是 Kinesis 数据流,则可能会存在限制情况。检查 ThrottledGetRecords, ThrottledGetShardIterator,和 ThrottledDescribeStream 度量。如果有多个使用者附加到 Kinesis 数据流,请考虑以下事项:

    • 如果 ThrottledGetRecordsThrottledGetShardIterator 指标非常高,我们建议您增加为数据流预配置的分片数。

    • 如果 ThrottledDescribeStream 是高的,我们建议您添加 kinesis:listshards 对中配置的角色的权限 KinesisStreamSourceConfiguration.

  • 目标缓冲提示较低。这可能会增加 Kinesis Data Firehose 传输到目标所需的往返次数,从而可能导致传输落后。考虑增大缓冲提示的值。有关更多信息,请参阅 BufferingHints.

  • 当错误频繁发生时,较长的重试持续时间可能会导致传输落后。考虑减小重试持续时间。此外,监控错误并尝试减少这些错误。有关如何使用 Amazon CloudWatch Logs 监控错误的信息,请参阅使用 Kinesis Data Firehose 监控 CloudWatch Logs

  • 如果目标为 Splunk 并且 DeliveryToSplunk.DataFreshness 非常高,但 DeliveryToSplunk.Success 看起来不错,则 Splunk 集群可能很忙。如果可能,请释放 Splunk 集群。或者,请联系 AWS Support,并请求提升 Kinesis Data Firehose 用于与 Splunk 集群通信的通道数量。

记录格式转换为 Apache Parquet 失败

如果您提取包含 Set类型的 DynamoDB 数据,通过 Lambda 将其流式传输到传输流,并使用 AWS Glue 数据目录 将记录格式转换为 Apache Parquet,就会出现这种情况。

当 AWS Glue 爬网程序为 DynamoDB 集数据类型(StringSetNumberSetBinarySet)编写索引时,会在数据目录中将其分别保存为 SET<STRING>SET<BIGINT>SET<BINARY>。但对于 Kinesis Data Firehose,要将数据记录转换为 Apache Parquet 格式,需要 Apache Hive 数据类型。由于集类型并非有效的 Apache Hive 数据类型,所以转换会失败。要进行成功转换,请使用 Apache Hive 数据类型更新数据目录。为此,您可以将数据目录中的 set 更改为 array

要将 AWS Glue 数据目录中的一个或多个数据类型从 set 更改为 array,请执行以下操作:

  1. 登录 AWS 管理控制台并通过以下网址打开 AWS Glue 控制台:https://console.amazonaws.cn/glue/

  2. 在左侧窗格中的数据目录标题下,选择

  3. 在表列表中,选择您需要修改一个或多个数据类型的表的名称。这会将您引导至该表的详细信息页面。

  4. 选择 Edit schema 按钮。

  5. 数据类型列中,选择第一个 set 数据类型。

  6. 列类型下拉列表中,将该类型从 set 更改为 array

  7. ArraySchema 字段中,输入 array<string>, array<int>,或 array<binary>,具体取决于场景的相应数据类型。

  8. 选择 Update.

  9. 重复之前的步骤,将其他 set 类型转换为 array 类型。

  10. 选择 Save.

尽管指标良好,但目标没有数据

如果没有数据接收问题,并且为传输流发出的指标看起来不错,但您在目标中看不到数据,请检查读取器逻辑。确保您的读取器正确解析所有数据。