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

# 常见问题
<a name="troubleshoot-common-issues"></a>

以下是一些问题排查技巧，可帮助您解决使用 Firehose 流时遇到的常见问题。

## Firehose 流不可用
<a name="firehose-unavailable"></a>

Firehose 流不能用作 CloudWatch 日志、 CloudWatch 事件或物 Amazon 联网操作的目标，因为某些 Amazon 服务只能向相同的 Firehose 流发送消息和事件。 Amazon Web Services 区域验证您的 Firehose 流是否与其他服务位于同一区域。

## 目的地没有数据
<a name="no-data-destination"></a>

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

## 数据新鲜度指标增长或未发出数据新鲜度指标
<a name="data-freshness-metric-not-emitted"></a>

数据新鲜度用于衡量您的数据在 Firehose 流中的最新程度。这是指 Firehose 流中最早数据记录的期限，从 Firehose 摄取数据到现在的时间计算。Firehose 提供了可用于监控数据新鲜度的指标。要确定指定目标的数据新鲜度指标，请参阅[使用指标监控亚马逊 Data Firehose CloudWatch](monitoring-with-cloudwatch-metrics.md)。

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

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

如果数据新鲜度指标在不断增加，则意味着数据传输落后。这可能是由于以下原因之一。
+ 目标无法跟上传输速率。如果由于高流量而导致 Firehose 临时遇到错误，则传输可能会落后。这可能发生在亚马逊 S3 以外的目的地（ OpenSearch服务、Amazon Redshift 或 Splunk 也可能发生这种情况）。确保您的目标有足够的容量来处理传入流量。
+ 目标非常慢。如果 Firehose 遇到高延迟，则数据传输可能会落后。监控目标的延迟指标。
+ Lambda 函数运行缓慢。这可能导致数据传输速率要低于 Firehose 流的数据摄取速率。如果可能，请提高 Lambda 函数的效率。例如，如果函数处理网络 IO，请使用多个线程或异步 IO 来增加并行度。此外，考虑增加 Lambda 函数的内存大小，以便相应地增加 CPU 分配。这可能会加快 Lambda 的调用速度。有关配置 Lambda 函数的信息，请参阅配置 Lam [bda Amazon](https://docs.amazonaws.cn/lambda/latest/dg/resource-model.html) 函数。
+ 在数据传输过程中出现故障。有关如何使用 Amazon Logs 监控错误 CloudWatch 的信息，请参阅[使用 CloudWatch 日志监控亚马逊 Data Firehose](monitoring-with-cloudwatch-logs.md)。
+ 如果 Firehose 流的数据来源是 Kinesis 数据流，则可能会存在限制情况。检查 `ThrottledGetRecords`、`ThrottledGetShardIterator` 和 `ThrottledDescribeStream` 指标。如果有多个使用者附加到 Kinesis 数据流，请考虑以下事项：
  + 如果 `ThrottledGetRecords` 和 `ThrottledGetShardIterator` 指标非常高，我们建议您增加为数据流预配置的分片数。
  + 如果`ThrottledDescribeStream`为高，我们建议您为中配置的角色添加`kinesis:listshards`权限[KinesisStreamSourceConfiguration](https://docs.amazonaws.cn/firehose/latest/APIReference/API_CreateDeliveryStream.html#Firehose-CreateDeliveryStream-request-KinesisStreamSourceConfiguration)。
+ 目标缓冲提示较低。这可能会增加 Firehose 传输到目的地所需的往返次数，从而可能导致传输滞后。考虑增大缓冲提示的值。有关更多信息，请参阅 [BufferingHints](https://docs.amazonaws.cn/firehose/latest/APIReference/API_BufferingHints.html)。
+ 当错误频繁发生时，较长的重试持续时间可能会导致传输落后。考虑减小重试持续时间。此外，监控错误并尝试减少这些错误。有关如何使用 Amazon Logs 监控错误 CloudWatch 的信息，请参阅[使用 CloudWatch 日志监控亚马逊 Data Firehose](monitoring-with-cloudwatch-logs.md)。
+ 如果目标为 Splunk 并且 `DeliveryToSplunk.DataFreshness` 非常高，但 `DeliveryToSplunk.Success` 看起来不错，则 Splunk 集群可能很忙。如果可能，请释放 Splunk 集群。或者，请联系 Amazon Support，请求增加 Firehose 用来与 Splunk 集群通信的通道数量。

## 记录格式转换为 Apache Parquet 失败
<a name="apache-parquet-conversion-fails"></a>

如果您获取包含`Set`该类型的 DynamoDB 数据，通过 Lambda 将其流式传输到 Fire Amazon Glue Data Catalog hose 流，然后使用将记录格式转换为 Apache Parquet，就会发生这种情况。

当 Amazon Glue Crawler 为 DynamoDB 集数据类型`StringSet`（`NumberSet`、`BinarySet`和）编制索引时，它会将它们分别存储在数据目录中`SET<STRING>`，即`SET<BIGINT>`、和。`SET<BINARY>`但对于 Firehose，要将数据记录转换为 Apache Parquet 格式，需要 Apache Hive 数据类型。由于集类型并非有效的 Apache Hive 数据类型，所以转换会失败。要进行成功转换，请使用 Apache Hive 数据类型更新数据目录。为此，您可以将数据目录中的 `set` 更改为 `array`。

**在中将一种或多种数据类型从`集合`更改为`数组` Amazon Glue 数据目录**

1. 登录 Amazon Web Services 管理控制台 并打开 Amazon Glue 控制台，网址为[https://console.aws.amazon.com/glue/](https://console.amazonaws.cn/glue/)。

1. 在左侧窗格中的**数据目录**标题下，选择**表**。

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

1. 选择详细信息页面右上角的**编辑架构**按钮。

1. 在**数据类型**列中，选择第一个 `set` 数据类型。

1. 在**列类型**下拉列表中，将该类型从 `set` 更改为 `array`。

1. 根据您的**ArraySchema**场景的相应数据类型`array<binary>`，在该字段中输`array<string>`入、或。`array<int>`

1. 选择**更新**。

1. 重复之前的步骤，将其他 `set` 类型转换为 `array` 类型。

1. 选择**保存**。

## Lambda 的已转换对象缺少字段
<a name="lambda-data-transformation-missing-fields"></a>

当您使用 Lambda 数据转换将 JSON 数据更改为 Parquet 对象时，某些字段可能会在转换后缺失。如果您的 JSON 对象有大写字母并且区分大小写设置为 `false`，则会发生这种情况，这可能会导致数据转换后的 JSON 密钥不匹配，从而导致 S3 存储桶中生成的 Parquet 对象中缺少数据。

要解决此问题，请确保将 hose 配置将 `deserializationOption: case.insensitive` 设置为 `true`，以便 JSON 密钥在转换后匹配。