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

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

排查亚马逊 MSK 集群

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

消费者群体陷入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 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),但您无法发送或接收数据,请确保生成器和使用器应用程序有权访问集群。有关更多信息,请参阅第 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。

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

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

  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. 使用为亚马逊 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 实例访问集群的示例,请参阅开始使用 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 connects错误表示经纪商正在保护自己,因为一个或多个 IAM 客户端试图以激进的速度连接到它。为了帮助经纪商接受更高的新 IAM 连接率,您可以增加reconnect.backoff.ms配置参数。

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