对 Amazon MSK 集群进行问题排查 - Amazon Managed Streaming for Apache Kafka
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

对 Amazon MSK 集群进行问题排查

以下信息可帮助您排查 Amazon MSK 集群可能存在的问题。您也可以将问题发布到 Amazon Web Services re:Post

使用器组卡滞在 PreparingRebalance 状态

如果一个或多个使用器组卡滞在一个永久的再平衡状态,则原因可能是 Apache Kafka 问题 KAFKA-9752,这会影响 Apache Kafka 版本 2.3.1 和 2.4.1。

要解决此问题,建议您将集群升级到 Amazon MSK 错误修复版本 2.4.1.1,其中包含针对此问题的修复程序。有关将现有集群更新到 Amazon MSK 错误修复版本 2.4.1.1 的信息,请参阅 更新 Apache Kafka 版本

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

实现静态成员协议

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

  1. Kafka 使用器配置的 group.instance.id 属性设置为可识别组中使用器的静态字符串。

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

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

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

注意

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

重启协调代理节点

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

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

  2. 使用 RebootBrokerAPI 操作重新启动卡住的消费者组的群组协调器。

向 Amazon CloudWatch 日志传送代理日志时出错

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

如果遇到 InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded 异常,请重试,但使用以 /aws/vendedlogs/ 开头的日志组。有关更多信息,请参阅启用从某些 Amazon Web Services 进行日志记录

如果您遇到异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

无默认安全组

如果您尝试创建集群,并收到错误指示没有默认安全组,则可能是因为您使用的是共享 VPC。请向管理员申请向您授予描述此 VPC 上的安全组的权限,然后重试。有关允许此操作的策略示例,请参阅 Amazon EC2:允许以编程方式在控制台中管理与特定 VPC 关联的 EC2 安全组

集群显示卡在 CREATING 状态

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

集群状态从 CREATING 变为 FAILED

请尝试再次创建集群。

集群状态为 ACTIVE,但生成器无法发送数据,或者使用器无法接收数据

  • 如果集群创建成功(集群状态为 ACTIVE),但您无法发送或接收数据,请确保生成器和使用器应用程序有权访问集群。有关更多信息,请参阅步骤 3:创建客户端计算机中的指南。

  • 如果您的生产器和使用器有权访问集群,但仍出现生成和使用数据问题,原因可能是 KAFKA-7697,这会影响 Apache Kafka 2.1.0 版本,并可能导致一个或多个代理发生死锁。请考虑迁移到 Apache Kafka 2.2.1,该版本不受此错误影响。有关如何迁移的信息,请参阅迁移到 Amazon MSK 集群

Amazon CLI 无法识别 Amazon MSK

如果您已 Amazon CLI 安装但它无法识别 Amazon MSK 命令,请 Amazon CLI 将您的命令升级到最新版本。有关如何升级的详细说明 Amazon CLI,请参阅安装 Amazon Command Line Interface。有关如何使用运行 Amazon MSK 命令的信息,请参阅Amazon MSK 的工作原理。 Amazon CLI

分区脱机或副本不同步

这些可能是磁盘空间不足的症状。请参阅 磁盘空间不足

磁盘空间不足

请参阅以下有关管理磁盘空间的最佳实践:监控磁盘空间调整数据保留参数

内存不足

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

制片人获得 NotLeaderForPartitionException

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

复制中的分区(URP)大于零

UnderReplicatedPartitions 指标是要监控的重要指标。在正常运行的 MSK 集群中,此指标的值为 0。如果它大于零,这可能是由以下某个原因所致。

  • 如果 UnderReplicatedPartitions 是峰值,问题可能在于该集群的大小配置不合适,无法处理传入和传出流量。请参阅 最佳实践

  • 如果 UnderReplicatedPartitions 始终大于 0(包括在低流量期间),问题可能在于您设置了限制性 ACL,该 ACL 未向代理授予主题访问权限。要复制分区,必须向代理授予 READ 和 DESCRIBE 主题的权限。默认情况下,将随 READ 授权一起授予 DESCRIBE 权限。有关设置 ACL 的信息,请参阅 Apache Kafka 文档中的授权和 ACL

集群中有名为 __amazon_msk_canary 和 __amazon_msk_canary_state 的主题

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

分区复制失败

确保您尚未在 CLUSTER_ACTIONS 上设置 ACL。

无法访问已开启公共访问权限的集群

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

  1. 确保集群安全组的入站规则允许您的 IP 地址和集群端口。有关集群端口号的列表,请参阅 端口信息。还要确保安全组的出站规则允许出站通信。有关安全组及其入站和出站规则的更多信息,请参阅《Amazon VPC 用户指南》中的您的 VPC 的安全组

  2. 确保集群 VPC 网络 ACL 的入站规则中允许您的 IP 地址和集群端口。与安全组不同,网络 ACL 无状态。这意味着您必须配置入站和出站规则。在出站规则中,允许所有流量(端口范围:0-65535)发送到您的 IP 地址。有关更多信息,请参阅《Amazon VPC 用户指南》中的添加和删除规则

  3. 确保您使用的是公共访问引导代理字符串来访问集群。开启了公共访问权限的 MSK 集群有两个不同的引导代理字符串,一个用于公共访问,另一个用于从 Amazon内部访问。有关更多信息,请参阅 使用获取引导程序代理 Amazon Web Services Management Console

无法从内部访问集群 Amazon:网络问题

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

  1. 使用获取 Amazon MSK 集群的引导代理中介绍的方法之一获取引导代理的地址。

  2. 在以下命令中,将 bootstrap-broker 替换为您在上一步中获得的某个代理地址。如果将集群设置为使用 TLS 身份验证,则将 port-number 替换为 9094。如果集群不使用 TLS 身份验证,请将 port-number 替换为 9092。从客户端计算机运行命令。

    telnet bootstrap-broker port-number
  3. 对所有引导代理重复运行上面的命令。

  4. 使用中获取亚马逊 MSK 集群的 Apache ZooKeeper 连接字符串描述的任何方法获取集群 Apache ZooKeeper 节点的地址。

  5. 在客户端计算机上运行以下命令,将 Apache ZooKeeper-nod e 替换为您在上一步中获得的其中一个 Apache ZooKeeper 节点的地址。数字 2181 是端口号。对所有 Apache ZooKeeper 节点重复此操作。

    telnet Apache-ZooKeeper-node 2181

如果客户端计算机能够访问代理和 Apache ZooKeeper 节点,则表示没有连接问题。在这种情况下,可以运行以下命令来检查 Apache Kafka 客户端是否设置正确。要获取 bootstrap-brokers,可使用获取 Amazon MSK 集群的引导代理中介绍的方法之一。将 topic 替换为您的主题名称。

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

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

如果客户端计算机无法访问代理和 Apache ZooKeeper 节点,请参阅以下小节以获取基于您的客户端计算机设置的指导。

同一 VPC 中的 Amazon EC2 客户端和 MSK 集群

如果客户端计算机与 MSK 集群位于同一 VPC 中,请确保集群安全组具有接受来自客户端计算机安全组的流量的入站规则。有关设置这些规则的信息,请参阅安全组规则。有关如何从与集群位于同一 VPC 中的 Amazon EC2 实例访问集群的示例,请参阅 开始使用 Amazon MSK

位于不同 VPC 中的 Amazon EC2 客户端和 MSK 集群

如果客户端计算机和集群位于两个不同的 VPC 中,请确保满足以下条件:

  • 这两个 VPC 是对等连接的。

  • 对等连接处于活动状态。

  • 这两个 VPC 的路由表已正确设置。

有关 VPC 对等连接的信息,请参阅使用 VPC 对等连接

本地客户端

如果本地客户端设置为使用连接到 MSK 集群 Amazon VPN,请确保满足以下条件:

  • VPN 连接状态为 UP。有关如何检查 VPN 连接状态的信息,请参阅如何检查 VPN 隧道的当前状态?

  • 集群 VPC 的路由表包含目标格式为 Virtual private gateway(vgw-xxxxxxxx) 的本地 CIDR 的路由。

  • MSK 集群的安全组允许端口 2181、端口 9092(如果您的集群接受明文流量)和端口 9094(如果您的集群接受 TLS 加密的流量)上的流量传输。

有关更多 Amazon VPN 故障排除指南,请参阅 Client VPN 故障排除

Amazon Direct Connect

如果客户端使用 Amazon Direct Connect,请参阅故障排除 Amazon Direct Connect

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

身份验证失败:连接次数过多

Failed authentication ... Too many connects 错误表明代理正在保护自己,因为一个或多个 IAM 客户端正试图以激进的速度连接到它。为帮助代理接受更高的新 IAM 连接速率,您可以增加 reconnect.backoff.ms 配置参数。

要详细了解每个代理的新连接的速率限制,请参阅 Amazon MSK 限额 页面。

MSK Serverless:集群创建失败

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

有关执行所有 Amazon MSK 操作所需的完整权限列表,请参阅 Amazon 托管策略:AmazonMSK FullAccess