对您的亚马逊MSK集群进行故障排除 - Amazon Managed Streaming for Apache Kafka

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

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

以下信息可以帮助您解决 Amazon MSK 集群可能遇到的问题。您也可以将问题发布到 AWS re:Post。有关 Amazon MSK Replicator 故障排除,请参阅对MSK复制器进行故障排除

由于复制过载,卷更换会导致磁盘饱和

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

问题

在从卷更换中恢复过来的代理中,一些大小不一的分区可能会先于其他分区重新联机。这可能会出现问题,因为这些分区可能提供来自同一个代理的流量,而这些代理仍在赶上(复制)其他分区。这种复制流量有时会使底层卷吞吐量限制饱和,默认情况下为每秒 250 MiB。当这种饱和度发生时,任何已经被捕获的分区都将受到影响,从而导致ISR与这些被捕分区共享的任何代理在集群中出现延迟(而不仅仅是由于远程ack而导致的领导分区acks=all)。此问题在较大的集群中更为常见,这些群集的分区数量较多,大小各不相同。

建议
  • 要改善复制 I/O 状态,请确保最佳实践线程设置到位。

  • 要降低底层容量饱和的可能性,请启用具有更高吞吐量的预配置存储。对于高吞吐量复制案例,建议将 500 MiB/s 的最小吞吐量值设置为 500 MiB/s,但实际所需的值会因吞吐量和用例而异。 为 Amazon MSK 集群中的代理配置存储吞吐量

  • 要最大限度地减少复制压力,num.replica.fetchers请降低到默认值2

使用器组卡滞在 PreparingRebalance 状态

如果你的一个或多个消费者组处于永久的再平衡状态,则原因可能是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 bug-fix 版本 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例外情况,请在您的账户中选择现有的 A CloudWatch mazon Logs 政策,并在其上附加以下内容JSON。

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

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

无默认安全组

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

集群似乎处于停滞CREATING状态

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

集群状态从变CREATING为 FAILED

请尝试再次创建集群。

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

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

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

AWS CLI 认不出亚马逊 MSK

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

分区脱机或副本不同步

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

磁盘空间不足

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

内存不足

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

制片人获得 NotLeaderForPartitionException

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

复制不足的分区 (URP) 大于零

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

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

  • 如果UnderReplicatedPartitions持续大于 0(包括在低流量时段),则问题可能是您设置了不向经纪人授予主题访问权限的限制性ACLs设置。要复制分区,代理必须同时拥有READ和DESCRIBE主题的权限。DESCRIBE默认情况下是通过READ授权授予的。有关设置的信息ACLs,请参阅授权和 Apache Kafka 文档ACLs中。

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

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

分区复制失败

请确保您尚未设置为 ACLs CLUSTER _ ACTIONS。

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

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

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

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

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

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

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

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

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

    telnet bootstrap-broker port-number

    其中端口号是:

    • 如果集群设置为使用TLS身份验证,则为 9094。

    • 9092 如果集群不使用TLS身份验证。

    • 如果启用了公共访问,则需要不同的端口号。

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

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

如果客户端计算机能够访问代理,则表示没有连接问题。在这种情况下,可以运行以下命令来检查 Apache Kafka 客户端是否设置正确。要获得 bootstrap-brokers,请使用中描述的任何方法获取 Amazon MSK 集群的引导程序代理。Replace(替换) topic 用你的话题的名字。

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

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

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

Amazon EC2 客户端和MSK集群在同一个环境中 VPC

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

Amazon EC2 客户端和MSK集群不同 VPCs

如果客户机和群集处于两个不同的位置VPCs,请确保满足以下条件:

  • 两者互VPCs相监视。

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

  • 两者的路由表设置VPCs正确。

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

本地客户端

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

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

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

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

有关更多 AWS VPN 故障排除指南,请参阅客户端故障排除VPN

AWS Direct Connect

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

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

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

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

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

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

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

有关执行所有 Amazon MSK 操作所需的权限的完整列表,请参阅AWS 托管策略:A mazonMSKFull 访问权限