您的亚马逊 MSK 集群故障排除 - Amazon Managed Streaming for Apache Kafka
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

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

您的亚马逊 MSK 集群故障排除

以下信息可帮助您排查 Amazon MSK 集群存在的问题。您也可以将问题发布到Amazon MSK 论坛

消费者组卡在PreparingRebalancestate

如果您的一个或多个消费者组陷入永久重新平衡状态,则可能是 Apache Kafka 问题卡夫卡,影响 Apache Kafka 版本 2.3.1 和 2.4.1。

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

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

实施静态成员协议

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

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

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

  3. 将更改部署到您的 Kafka 消费者。

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

注意

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

重新启动协调代理节点

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

  1. 标识群组协调员使用kafka-consumer-groups.sh命令。

  2. 重新启动卡住的使用者组的组协调器,使用重新启动代理API 操作。

将代理日志传送到 Amazon CloudWatch Logs 时出错

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

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

如果您得到一个InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded异常,请在您的账户中选择一个现有 Amazon CloudWatch Logs 策略,并将以下 JSON 附加到该策略。

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

如果您尝试将上述 JSON 附加到现有策略,但收到一个错误,指出您已达到所选策略的最大长度,请尝试将 JSON 附加到另一个 Amazon CloudWatch Logs 策略。将 JSON 附加到现有策略后,再次尝试设置将代理日志传送到 Amazon CloudWatch Logs。

无默认安全组

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

集群显示卡在 CREATING 状态

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

集群状态从 CREATING 变为 FAILED

请尝试再次创建集群。

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

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

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

Amazon CLI无法识别 Amazon MSK

如果您有Amazon CLI,但无法识别 Amazon MSK 命令,请升级Amazon CLI到最新版本。有关如何升级Amazon CLI,请参阅安装Amazon Command Line Interface。有关如何使用Amazon CLI运行亚马逊 MSK 命令,请参阅Amazon MSK:工作方式

分区脱机或副本不同步

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

磁盘空间不足

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

内存不足

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

生成器获取 NotLeaderForPartitionException

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

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

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

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

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

集群的主题称为金丝雀和州

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

分区复制失败

确保您没有在集群操作上设置 ACL。

联网问题

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

  1. 使用为亚马逊 MSK 集群获取引导经纪商中介绍的方法之一获取引导代理的地址。

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

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

  4. 使用获取 Amazon MSK 集群的 Apache ZooKeeper 连接字符串中介绍的方法之一获取集群的 Apache ZooKeeper 节点的地址。

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

    telnet Apache-ZooKeeper-node 2181

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

bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties —topic topic

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

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

注意

客户端必须使用专用连接来生成和使用 MSK 群集的数据。亚马逊 MSK 不支持公共终端节点。

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

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

不同 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 问题排查方面的更多指导,请参阅客户端 VPN 问题排查

Amazon Direct Connect

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

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