

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

# 排查 Amazon MSK 集群的问题
<a name="troubleshooting"></a>

以下信息可帮助您排查 Amazon MSK 集群可能存在的问题。您也可以将问题发布到 [AWS re:Post](https://repost.aws/)。有关排查 Amazon MSK 复制器问题的信息，请参阅 [排查 MSK 复制器问题](msk-replicator-troubleshooting.md)。

**Topics**
+ [由于复制过载，卷更换导致磁盘饱和](#replication-overload-disk-saturation)
+ [使用器组卡滞在 `PreparingRebalance` 状态](#consumer-group-rebalance)
+ [向 Amazon CloudWatch 日志传送代理日志时出错](#cw-broker-logs-error)
+ [无默认安全组](#troubleshooting-shared-vpc)
+ [集群显示卡在 CREATING 状态](#troubleshooting-cluster-stuck)
+ [集群状态从 CREATING 变为 FAILED](#troubleshooting-cluster-failed)
+ [集群状态为 ACTIVE，但生成器无法发送数据，或者使用器无法接收数据](#troubleshooting-nodata)
+ [AWS CLI 无法识别 Amazon MSK](#troubleshooting-nocli)
+ [分区脱机或副本不同步](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [磁盘空间不足](#troubleshooting-lowdiskspace)
+ [内存不足](#troubleshooting-lowmemory)
+ [制片人获得 NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [复制中的分区（URP）大于零](#troubleshooting-urp)
+ [集群中有名为 \$1\$1amazon\$1msk\$1canary 和 \$1\$1amazon\$1msk\$1canary\$1state 的主题](#amazon_msk_canary)
+ [分区复制失败](#partition_replication_fails)
+ [无法访问已开启公共访问权限的集群](#public-access-issues)
+ [无法通过 IPv6 引导访问集群](#dualstack-issues)
+ [无法从内部访问集群 AWS：网络问题](#networking-trouble)
+ [身份验证失败：连接次数过多](#troubleshoot-too-many-connects)
+ [身份验证失败：会话时间太短](#troubleshoot-session-too-short)
+ [MSK Serverless：集群创建失败](#troubleshoot-serverless-create-cluster-failure)
+ [无法 KafkaVersionsList 在 MSK 配置中更新](#troubleshoot-kafkaversionslist-cfn-update-failure)

## 由于复制过载，卷更换导致磁盘饱和
<a name="replication-overload-disk-saturation"></a>

在计划外卷硬件故障期间，Amazon MSK 可能会用新实例替换该卷。Kafka 通过从集群中的其他代理复制分区来重新填充新卷。一旦分区完成复制并赶上，它们就有资格获得领导权和同步副本（ISR）成员资格。

**问题**  
在从卷更换恢复的代理中，一些不同大小的分区可能会先于其他分区恢复在线。这可能会出现问题，因为这些分区可能正在为来自同一代理的流量提供服务，而该代理仍在追赶（复制）其他分区。此复制流量有时会使底层卷吞吐量限制饱和，默认情况下为每秒 250 MiB。当出现这种饱和时，任何已经赶上的分区都会受到影响，导致集群中与这些赶上的分区共享 ISR 的任何代理（不仅仅是由于远程确认 `acks=all` 导致的领导者分区）出现延迟。此问题在具有大量大小不同的分区的较大集群中更为常见。

**建议**
+ 要改善复制 I/O 状态，请确保[最佳实践线程设置](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)到位。
+ 要降低底层容量饱和的可能性，请启用具有更高吞吐量的预置存储。对于高吞吐量复制案例，建议将最小吞吐量值设置 MiB/s 为 500，但实际所需的值会因吞吐量和用例而异。 [为 Amazon MSK 集群中的标准代理预置存储吞吐量](msk-provision-throughput.md)。
+ 为了最大限度地减少复制压力，请将 `num.replica.fetchers` 降低为默认值 `2`。

## 使用器组卡滞在 `PreparingRebalance` 状态
<a name="consumer-group-rebalance"></a>

如果一个或多个使用器组卡滞在一个永久的再平衡状态，则原因可能是 Apache Kafka 问题 [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752)，这会影响 Apache Kafka 版本 2.3.1 和 2.4.1。

要解决此问题，建议您将集群升级到 [Amazon MSK 错误修复版本 2.4.1.1](supported-kafka-versions.md#2.4.1.1)，其中包含针对此问题的修复程序。有关将现有集群更新到 Amazon MSK 错误修复版本 2.4.1.1 的信息，请参阅[升级 Apache Kafka 版本](version-upgrades.md)。

 在不将集群升级到 Amazon MSK 错误修复版本 2.4.1.1 的情况下解决此问题的方法是，设置要使用 [静态成员协议](#consumer-group-rebalance-static) 的 Kafka 客户端，或者 [识别并重启](#consumer-group-rebalance-reboot) 卡住的使用器组的协调代理节点。

### 实现静态成员协议
<a name="consumer-group-rebalance-static"></a>

要在客户端中实现静态成员协议，请执行以下操作：

1. 将 [Kafka 使用器](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html)配置的 `group.instance.id` 属性设置为可识别组中使用器的静态字符串。

1. 确保配置的其他实例已更新为使用静态字符串。

1. 将更改部署到您的 Kafka 使用器。

如果将客户端配置中的会话超时设置为允许使用器在不过早触发使用器组重新平衡的情况下恢复的持续时间，则使用静态成员协议会更有效。例如，如果您的使用器应用程序可以容忍 5 分钟不可用，则会话超时的合理值为 4 分钟，而不是默认的 10 秒。

**注意**  
使用静态成员协议只会降低遇到此问题的可能性。即使使用静态成员协议，您仍可能遇到此问题。

### 重启协调代理节点
<a name="consumer-group-rebalance-reboot"></a>

要重启协调代理节点，请执行以下操作：

1. 使用 `kafka-consumer-groups.sh` 命令识别组协调器。

1. 使用 [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API 操作重新启动卡住的消费者组的群组协调器。

## 向 Amazon CloudWatch 日志传送代理日志时出错
<a name="cw-broker-logs-error"></a>

当您尝试将集群设置为向 Amazon Logs 发送代理 CloudWatch 日志时，可能会遇到两个例外情况之一。

如果遇到 `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` 异常，请重试，但使用以 `/aws/vendedlogs/` 开头的日志组。有关更多信息，请参阅[启用从某些 Amazon Web Services 进行日志记录](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)。

如果您遇到异`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded`常，请选择您账户中的现有 Ama CloudWatch zon Logs 政策，并在其中附加以下 JSON。

```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```

如果您尝试将上述 JSON 附加到现有策略中，但收到错误提示您已达到所选策略的最大长度，请尝试将 JSON 附加到您的另一个 Amazon L CloudWatch ogs 策略中。将 JSON 附加到现有策略后，请再次尝试将代理日志传输设置为 Amazon Logs。 CloudWatch 

## 无默认安全组
<a name="troubleshooting-shared-vpc"></a>

如果您尝试创建集群，并收到错误指示没有默认安全组，则可能是因为您使用的是共享 VPC。请向管理员申请向您授予描述此 VPC 上的安全组的权限，然后重试。有关允许此操作的策略示例，请参阅 [Amazon EC2：允许以编程方式在控制台中管理与特定 VPC 关联的 EC2 安全组](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html)。

## 集群显示卡在 CREATING 状态
<a name="troubleshooting-cluster-stuck"></a>

有时，集群创建可能需要长达 30 分钟。请等待 30 分钟，然后再次检查集群的状态。

## 集群状态从 CREATING 变为 FAILED
<a name="troubleshooting-cluster-failed"></a>

请尝试再次创建集群。

## 集群状态为 ACTIVE，但生成器无法发送数据，或者使用器无法接收数据
<a name="troubleshooting-nodata"></a>
+ 如果集群创建成功（集群状态为 `ACTIVE`），但您无法发送或接收数据，请确保生成器和使用器应用程序有权访问集群。有关更多信息，请参阅[步骤 3：创建客户端计算机](create-client-machine.md)中的指南。
+ 如果您的生产器和使用器有权访问集群，但仍出现生成和使用数据问题，原因可能是 [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697)，这会影响 Apache Kafka 2.1.0 版本，并可能导致一个或多个代理发生死锁。请考虑迁移到 Apache Kafka 2.2.1，该版本不受此错误影响。有关如何迁移的信息，请参阅[将 Kafka 工作负载迁移至 Amazon MSK 集群](migration.md)。

## AWS CLI 无法识别 Amazon MSK
<a name="troubleshooting-nocli"></a>

如果您已 AWS CLI 安装但它无法识别 Amazon MSK 命令，请 AWS CLI 将您的命令升级到最新版本。有关如何升级的详细说明 AWS CLI，请参阅[安装 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。有关如何使用运行 Amazon MSK 命令的信息，请参阅[Amazon MSK 的关键功能和概念](operations.md)。 AWS CLI 

## 分区脱机或副本不同步
<a name="troubleshooting-offlinepartition-outofsyncreplicas"></a>

这些可能是磁盘空间不足的症状。请参阅[磁盘空间不足](#troubleshooting-lowdiskspace)。

## 磁盘空间不足
<a name="troubleshooting-lowdiskspace"></a>

请参阅以下有关管理磁盘空间的最佳实践：[监控磁盘空间](bestpractices.md#bestpractices-monitor-disk-space)和[调整数据保留参数](bestpractices.md#bestpractices-retention-period)。

## 内存不足
<a name="troubleshooting-lowmemory"></a>

如果您发现 `MemoryUsed` 指标太高或 `MemoryFree` 太低，这并不意味着存在问题。Apache Kafka 的设计初衷是充分利用内存，并以最佳方式管理内存。

## 制片人获得 NotLeaderForPartitionException
<a name="troubleshooting-NotLeaderForPartitionException"></a>

这往往是临时错误。将生成器的 `retries` 配置参数设置为高于其当前值的值。

## 复制中的分区（URP）大于零
<a name="troubleshooting-urp"></a>

`UnderReplicatedPartitions` 指标是要监控的重要指标。在正常运行的 MSK 集群中，此指标的值为 0。如果它大于零，这可能是由以下某个原因所致。
+ 如果 `UnderReplicatedPartitions` 是峰值，问题可能在于该集群的大小配置不合适，无法处理传入和传出流量。请参阅[标准代理的最佳实践](bestpractices.md)。
+ 如果`UnderReplicatedPartitions`持续大于 0，包括在低流量时段，则问题可能是您设置了不向经纪人授予主题访问权限的限制 ACLs 。要复制分区，必须向代理授予 READ 和 DESCRIBE 主题的权限。默认情况下，将随 READ 授权一起授予 DESCRIBE 权限。有关设置的信息 ACLs，请参阅[授权和](https://kafka.apache.org/documentation/#security_authz) Apache Kafka 文档 ACLs中。

## 集群中有名为 \$1\$1amazon\$1msk\$1canary 和 \$1\$1amazon\$1msk\$1canary\$1state 的主题
<a name="amazon_msk_canary"></a>

您可能会看到，MSK 集群有一个名为 `__amazon_msk_canary` 的主题，而另一个主题的名称为 `__amazon_msk_canary_state`。这些是 Amazon MSK 创建并用于集群运行状况和诊断指标的内部主题。这些主题无法删除，不过大小可以忽略不计。

## 分区复制失败
<a name="partition_replication_fails"></a>

确保您尚未在 CLUSTER\$1ACTI ACLs ONS 上进行设置。

## 无法访问已开启公共访问权限的集群
<a name="public-access-issues"></a>

如果您的集群已开启公共访问权限，但您仍然无法通过互联网访问它，请按照以下步骤操作：

1. 确保集群安全组的入站规则允许您的 IP 地址和集群端口。有关集群端口号的列表，请参阅[端口信息](port-info.md)。还要确保安全组的出站规则允许出站通信。有关安全组及其入站和出站规则的更多信息，请参阅《Amazon VPC 用户指南》中的[您的 VPC 的安全组](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。

1. 确保集群 VPC 网络 ACL 的入站规则中允许您的 IP 地址和集群端口。与安全组不同，网络 ACLs 是无状态的。这意味着您必须配置入站和出站规则。在出站规则中，允许所有流量（端口范围：0-65535）发送到您的 IP 地址。有关更多信息，请参阅《Amazon VPC 用户指南》中的[添加和删除规则](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)。

1. 确保您使用的是公共访问引导代理字符串来访问集群。开启了公共访问权限的 MSK 集群有两个不同的引导代理字符串，一个用于公共访问，另一个用于从 AWS内部访问。有关更多信息，请参阅 [使用获取引导程序代理 AWS 管理控制台](get-bootstrap-console.md)。

## 无法通过 IPv6 引导访问集群
<a name="dualstack-issues"></a>

如果您在使用提供的 IPv6 引导字符串连接到集群时遇到问题，请按照以下步骤操作：

1.  确保您的客户端同时分配了 IPv4 和 IPv6 地址。您的客户端应用程序必须在同时启用 IPv4 和 IPv6 寻址并正确配置的子网中运行。检查您的 VPC 是否同时具有 IPv4 CIDR 块和关联的 IPv6 CIDR 块，确认您的子网同时启用了 IPv4 和 IPv6 地址，并验证您的 EC2 实例或客户端环境是否同时 IPv4 分配了地址和地址。 IPv6 有关更多信息，请参阅 Amazon VPC 用户指南中的[您的 VPCs 和子网的 IP 地址](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html)。

1.  确保安全组的入站和出站规则中存在相关 IPv6 端口。添加入站规则以允许来自您的 IPv6 地址的集群端口上的流量，并配置出站规则以允许 IPv6 流量。有关具体的端口号，请参阅 MSK 文档中的[端口信息](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html)。如果在双堆栈模式下运行 IPv4 ，请记住更新两者的 IPv6 规则。有关安全组及其入站和出站规则的更多信息，请参阅《Amazon VPC 用户指南》中的[您的 VPC 的安全组](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)。

1.  确保 JVM 属性配置正确以获得 IPv6 支持。在您的客户端应用程序中，设置`java.net.preferIPv6Addresses`为`true`和`java.net.preferIPv4Stack`为`false`。这些设置可以配置为系统属性或 JVM 参数。进行这些更改后，请重新启动应用程序以使其生效。

## 无法从内部访问集群 AWS：网络问题
<a name="networking-trouble"></a>

如果您的 Apache Kafka 应用程序无法与 MSK 集群成功通信，可以先执行以下连接测试。

1. 使用[获取 Amazon MSK 集群的引导代理](msk-get-bootstrap-brokers.md)中介绍的方法之一获取引导代理的地址。

1. 在以下命令中，*bootstrap-broker*替换为您在上一步中获得的经纪人地址之一。如果集群设置为使用 TLS 身份验证，则替换*port-number*为 9094。如果集群不使用 TLS 身份验证，请*port-number*替换为 9092。从客户端计算机运行命令。

   ```
   telnet bootstrap-broker port-number
   ```

   其中 port-number 为：
   + 如果将集群设置为使用 TLS 身份验证，则为 9094。
   + 如果集群不使用 TLS 身份验证则为 9092。
   + 如果启用了公共访问，则需要其他端口号。

   从客户端计算机运行命令。

1. 对所有引导代理重复运行上面的命令。

如果客户端计算机能够访问代理，则表示没有连接问题。在这种情况下，可以运行以下命令来检查 Apache Kafka 客户端是否设置正确。要获取*bootstrap-brokers*，请使用中描述的任何方法[获取 Amazon MSK 集群的引导代理](msk-get-bootstrap-brokers.md)。*topic*替换为主题的名称。

```
<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```

如果上一个命令成功，则表示客户端设置正确。如果仍然无法从应用程序创建和使用，请在应用程序级别调试问题。

如果客户端计算机无法访问代理，请参阅以下几个小节，获得关于客户端计算机设置的指导。

### 同一 VPC 中的 Amazon EC2 客户端和 MSK 集群
<a name="troubleshoot-ec2-client-in-cluster-vpc"></a>

如果客户端计算机与 MSK 集群位于同一 VPC 中，请确保集群安全组具有接受来自客户端计算机安全组的流量的入站规则。有关设置这些规则的信息，请参阅[安全组规则](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)。有关如何从与集群位于同一 VPC 中的 Amazon EC2 实例访问集群的示例，请参阅[开始使用 Amazon MSK](getting-started.md)。

### Amazon EC2 客户端和 MSK 集群不同 VPCs
<a name="troubleshoot-peering-connection"></a>

如果客户机和群集处于两个不同的位置 VPCs，请确保满足以下条件：
+ 两者互 VPCs 相监视。
+ 对等连接处于活动状态。
+ 两者的路由表设置 VPCs 正确。

有关 VPC 对等连接的信息，请参阅[使用 VPC 对等连接](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html)。

### 本地客户端
<a name="troubleshoot-on-prem-client"></a>

如果本地客户端设置为使用连接到 MSK 集群 Site-to-Site VPN，请确保满足以下条件：
+ VPN 连接状态为 `UP`。有关如何检查 VPN 连接状态的信息，请参阅[如何检查 VPN 隧道的当前状态？](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/)。
+ 集群 VPC 的路由表包含目标格式为 `Virtual private gateway(vgw-xxxxxxxx)` 的本地 CIDR 的路由。
+ MSK 集群的安全组允许端口 2181、端口 9092（如果您的集群接受明文流量）和端口 9094（如果您的集群接受 TLS 加密的流量）上的流量传输。

有关更多 Site-to-Site VPN 故障排除指南，请参阅 [Client VPN 故障排除](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html)。

### Direct Connect
<a name="troubleshoot-direct-connect"></a>

如果客户端使用 Direct Connect，请参阅[故障排除 Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html)。

如果上述问题排查指导未能解决此问题，请确保没有防火墙阻止网络流量。若要进一步调试，请使用 `tcpdump` 和 `Wireshark` 等工具来分析流量，并确保流量到达 MSK 集群。

## 身份验证失败：连接次数过多
<a name="troubleshoot-too-many-connects"></a>

`Failed authentication ... Too many connects` 错误表明代理正在保护自己，因为一个或多个 IAM 客户端正试图以激进的速度连接到它。为帮助代理接受更高的新 IAM 连接速率，您可以增加 [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms) 配置参数。

要详细了解每个代理的新连接的速率限制，请参阅 [Amazon MSK 限额](limits.md)页面。

## 身份验证失败：会话时间太短
<a name="troubleshoot-session-too-short"></a>

当客户端尝试使用即将过期的 IAM 凭证连接到集群时，就会发生 `Failed authentication ... Session too short` 错误。请务必检查 IAM 凭证的刷新方式。最有可能的原因是，替换凭证的时间太接近会话到期时间，这会导致服务器端出现问题和身份验证失败。

## MSK Serverless：集群创建失败
<a name="troubleshoot-serverless-create-cluster-failure"></a>

如果您尝试创建 MSK Serverless 集群，但工作流程失败，则您可能无权创建 VPC 端点。通过允许 `ec2:CreateVpcEndpoint` 操作，验证您的管理员是否已授予您创建 VPC 端点的权限。

有关执行所有 Amazon MSK 操作所需的完整权限列表，请参阅 [AWS 托管策略：Amazon A MSKFull ccess](security-iam-awsmanpol-AmazonMSKFullAccess.md)。

## 无法 KafkaVersionsList 在 MSK 配置中更新
<a name="troubleshoot-kafkaversionslist-cfn-update-failure"></a>

更新[AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)资源中的[KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)属性时，更新失败并显示以下错误。

```
Resource of type 'AWS::MSK::Configuration' with identifier '<identifierName>' already exists.
```

更新`KafkaVersionsList`属性时，在删除旧配置之前，使用更新的属性 AWS CloudFormation 重新创建新配置。 CloudFormation 堆栈更新失败，因为新配置使用的名称与现有配置相同。这样的更新需要[替换资源](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement)。要成功更新 `KafkaVersionsList`，还必须在同一操作中更新[名称](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name)属性。

此外，如果您的配置附加到使用 AWS 管理控制台 或创建的任何群集 AWS CLI，请将以下内容添加到您的配置资源中，以防止[资源删除尝试失败](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)。

```
UpdateReplacePolicy: Retain
```

更新成功后，请转至 Amazon MSK 控制台并删除旧配置。有关 MSK 配置的信息，请参阅 [预置 Amazon MSK 配置](msk-configuration.md)。