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

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

Amazon MSK 集群故障排除

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

消费者群体陷入困境PreparingRebalancestate

如果您的一个或多个消费者组陷入永久再平衡状态,原因可能是 Apache Kafka 问题KAFKA-9752,该程序会影响 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. 使用重新启动停滞的使用者组的组协调器 RebootBrokerAPI 操作。

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

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

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

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

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

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

无默认安全组

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

集群显示卡在 CREATING 状态

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

集群状态从 CREATING 变为 FAILED

请尝试再次创建集群。

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

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

  • 如果您的生产器和使用器有权访问集群,但仍出现生成和使用数据问题,原因可能是 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

集群有名为 __amazon_msk_canary 和 __amazon_msk_canary_state 的主题

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

分区复制失败

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

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

如果您的集群已开启公共访问权限,但仍无法从 Internet 访问它,请按照以下步骤操作:

  1. 确保集群的安全组的入站规则允许您的 IP 地址和群集的端口。有关群集端口号的列表,请参阅端口信息. 还要确保安全组的出站规则允许出站通信。有关安全组及其入站和出站规则的更多信息,请参阅您的 VPC 的安全组(在 Amazon 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. 使用中介绍的方法之一获得 Apache ZooKeeper Amazon MSK 集群的连接字符串获取集群的 Apache 的地址 ZooKeeper 节点。

  5. 在客户端计算机上运行以下命令,替换Apache-ZooKeeper-节点使用其中一个 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 节点的,请参阅以下几个小节,获得关于客户端计算机设置的指导。

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

如果客户端计算机与 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 问题排查方面的更多指导,请参阅客户端 VPN 问题排查

Amazon Direct Connect

如果客户端使用Amazon Direct Connect,请参阅问题排查Amazon Direct Connect.

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

身份验证失败:连接过多

这些区域有:Failed authentication ... Too many connectserror 表示代理正在保护自己,因为一个或多个 IAM 客户端正在尝试以激进的速率连接到它。为了帮助经纪商接受更高比率的新 IAM 连接,您可以提高reconnect.backoff.ms配置参数。

要了解有关每个代理的新连接的速率限制的更多信息,请参阅Amazon MSK 配额页.

MSK 无服务器:创建集群失败

如果您尝试创建 MSK 无服务器集群但工作流程失败,则可能没有创建 VPC 终端节点的权限。验证您的管理员是否已为您授予创建 VPC 终端节点的权限,方法是允许ec2:CreateVpcEndpointaction.

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