在 RHEL 中使用 AMQ Streams


Red Hat AMQ Streams 2.1

在 Red Hat Enterprise Linux 中配置和管理 AMQ Streams 2.1 的部署

摘要

配置使用 AMQ Streams 部署的 operator 和 Kafka 组件,以构建大规模消息传递网络。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

第 1 章 AMQ Streams 概述

Red Hat AMQ Streams 是一个可大规模扩展的、分布式和高性能数据流平台,它基于 Apache ZooKeeper 和 Apache Kafka 项目。

主要组件包括:

Kafka Broker

负责将记录从生成客户端到使用客户端的消息传递代理。

Apache ZooKeeper 是 Kafka 的一个核心依赖项,为高度可靠的分布式协调提供集群协调服务。

Kafka Streams API
用于编写 流处理器 应用的 API。
Producer 和 Consumer APIs
基于 Java 的 API,用于向 Kafka 代理生成和使用信息。
Kafka Bridge
AMQ Streams Kafka Bridge 提供了一个 RESTful 接口,它允许基于 HTTP 的客户端与 Kafka 集群交互。
Kafka Connect
使用 Connector 插件在 Kafka 代理和其他系统间流传输数据的工具包。
Kafka MirrorMaker
在两个 Kafka 集群或数据中心之间复制数据。
Kafka Exporter
用于监控 Kafka 指标数据的导出器。

Kafka 代理的集群是 hub 连接所有这些组件。代理使用 Apache ZooKeeper 存储配置数据和集群协调。在运行 Apache Kafka 之前,Apache ZooKeeper 集群必须就绪。

图 1.1. AMQ Streams 架构

1.1. 使用 Kafka Bridge 与 Kafka 集群连接

您可以使用 AMQ Streams Kafka Bridge API 来创建和管理消费者,并通过 HTTP 而不是原生 Kafka 协议发送和接收记录。

设置 Kafka Bridge 时,您可以配置对 Kafka 集群的 HTTP 访问。然后,您可以使用 Kafka Bridge 来生成和消费来自集群的消息,以及通过其 REST 接口执行其他操作。

1.2. Kafka 功能

Kafka 的底层数据流处理功能和组件架构可以提供:

  • 微服务和其他应用,以极高吞吐量和低延迟共享数据
  • 消息排序保证
  • 从数据存储中递归/恢复消息,以重新构建应用程序状态
  • 使用键值日志时,消息压缩以删除旧记录
  • 集群配置中的水平可扩展性
  • 复制数据以控制容错
  • 保留大量数据以即时访问

1.3. Kafka 用例

Kafka 的功能使其适合:

  • 事件驱动的构架
  • 事件提供,将更改捕获为作为事件日志的应用程序状态
  • 消息代理
  • 网站活动跟踪
  • 通过指标数据进行操作监控
  • 日志聚合和聚合
  • 为分布式系统提交日志
  • 流处理,以便应用程序实时响应数据

1.4. 支持的配置

要在受支持的配置中运行,AMQ Streams 必须在受支持的操作系统的受支持的 JVM 版本中运行。

如需更多信息,请参阅 https://access.redhat.com/articles/6644711

1.5. 文档惯例

user-replaced 值

用户替换的值(也称为 可替换值)显示为包括在尖括号 (< >) 中的斜体字符。下划线(_)用于多词语值。如果值引用代码或命令,也使用 monospace

例如,在以下代码中,您要将 <bootstrap_address><topic_name> 替换为您自己的地址和主题名称:

bin/kafka-console-consumer.sh --bootstrap-server <bootstrap_address> --topic <topic_name> --from-beginning
Copy to Clipboard Toggle word wrap

第 2 章 开始使用

2.1. AMQ Streams 发布

AMQ Streams 作为单一 ZIP 文件发布。此 ZIP 文件包含 AMQ Streams 组件:

  • Apache ZooKeeper
  • Apache Kafka
  • Apache Kafka Connect
  • Apache Kafka MirrorMaker
  • Kafka Bridge
  • Kafka Exporter

2.2. 下载 AMQ Streams 归档

可以从红帽网站下载 AMQ Streams 的归档发布。您可以按照以下步骤下载发行版的副本。

流程

  • 从 AMQ Streams 软件下载页面 下载最新版本的 Red Hat AMQ Streams 存档。

2.3. 安装 AMQ Streams

按照以下步骤在 Red Hat Enterprise Linux 上安装最新版本的 AMQ Streams。

有关将现有集群升级到 AMQ Streams 2.1 的说明,请参阅 AMQ Streams 和 Kafka 升级

先决条件

流程

  1. 添加新的 kafka 用户和组。

    sudo groupadd kafka
    sudo useradd -g kafka kafka
    sudo passwd kafka
    Copy to Clipboard Toggle word wrap
  2. 创建目录 /opt/kafka

    sudo mkdir /opt/kafka
    Copy to Clipboard Toggle word wrap
  3. 创建一个临时目录,并提取 AMQ Streams ZIP 文件的内容。

    mkdir /tmp/kafka
    unzip amq-streams_y.y-x.x.x.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap
  4. 将提取的内容移到 /opt/kafka 目录中,并删除临时目录。

    sudo mv /tmp/kafka/kafka_y.y-x.x.x/* /opt/kafka/
    rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap
  5. /opt/kafka 目录的所有权更改为 kafka 用户。

    sudo chown -R kafka:kafka /opt/kafka
    Copy to Clipboard Toggle word wrap
  6. 创建用于存储 ZooKeeper 数据的 /var/lib/zookeeper 目录,并将其所有权设置为 kafka 用户。

    sudo mkdir /var/lib/zookeeper
    sudo chown -R kafka:kafka /var/lib/zookeeper
    Copy to Clipboard Toggle word wrap
  7. 创建用于存储 Kafka 数据的目录 /var/lib/kafka,并将其所有权设置为 kafka 用户。

    sudo mkdir /var/lib/kafka
    sudo chown -R kafka:kafka /var/lib/kafka
    Copy to Clipboard Toggle word wrap

2.4. 数据存储注意事项

有效的数据存储基础架构对于 AMQ Streams 的最佳性能至关重要。

AMQ Streams 需要块存储,并可搭配基于云的块存储解决方案,如 Amazon Elastic Block Store (EBS)。不建议使用文件存储。

尽可能选择本地存储。如果本地存储不可用,您可以使用可通过光纤通道或 iSCSI 等协议访问的存储区域网络(SAN)。

2.4.1. Apache Kafka 和 ZooKeeper 存储支持

为 Apache Kafka 和 ZooKeeper 使用单独的磁盘。

Kafka 支持 JBOD (Just a Bunch of Disks)存储,这是多个磁盘或卷的数据存储配置。JBOD 为 Kafka 代理提供更高的数据存储。它还可以提高性能。

虽然使用固态驱动器 (SSD) 并不是必须的,但它可以在大型集群中提高 Kafka 的性能,其中数据会异步发送到多个主题,并从多个主题接收。SSD 与 ZooKeeper 特别有效,这需要快速、低延迟数据访问。

注意

您不需要置备复制存储,因为 Kafka 和 ZooKeeper 都有内置数据复制。

2.4.2. 文件系统

建议您将存储系统配置为使用 XFS 文件系统。AMQ Streams 也与 ext4 文件系统兼容,但这可能需要额外配置才能获得最佳结果。

其他资源

2.5. 运行单一节点 AMQ Streams 集群

此流程演示了如何运行由单个 Apache ZooKeeper 节点和单个 Apache Kafka 节点组成的基本 AMQ Streams 集群,它们在同一主机上运行。默认配置文件用于 ZooKeeper 和 Kafka。

警告

单一节点 AMQ Streams 集群不提供可靠性和高可用性,仅适用于开发目的。

先决条件

  • AMQ Streams 安装在主机上

运行集群

  1. 编辑 ZooKeeper 配置文件 /opt/kafka/config/zookeeper.properties。将 dataDir 选项设置为 /var/lib/zookeeper/:

    dataDir=/var/lib/zookeeper/
    Copy to Clipboard Toggle word wrap
  2. 编辑 Kafka 配置文件 /opt/kafka/config/server.properties。将 log.dirs 选项设置为 /var/lib/kafka/

    log.dirs=/var/lib/kafka/
    Copy to Clipboard Toggle word wrap
  3. 切换到 kafka 用户:

    su - kafka
    Copy to Clipboard Toggle word wrap
  4. 启动 ZooKeeper:

    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap
  5. 检查 ZooKeeper 是否正在运行:

    jcmd | grep zookeeper
    Copy to Clipboard Toggle word wrap

    返回:

    number org.apache.zookeeper.server.quorum.QuorumPeerMain /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap
  6. 启动 Kafka:

    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  7. 检查 Kafka 是否正在运行:

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

    返回:

    number kafka.Kafka /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

其他资源

2.6. 使用集群

此流程描述了如何启动 Kafka 控制台生成者和消费者客户端,并使用它们发送和接收多个信息。

步骤 1 中会自动创建一个新主题。Topic auto-creation 使用 auto.create.topics.enable 配置属性(默认为 true )进行控制。另外,您可以在使用集群前配置和创建主题。如需更多信息,请参阅 主题

流程

  1. 启动 Kafka 控制台制作者并将其配置为将信息发送到新主题:

    /opt/kafka/bin/kafka-console-producer.sh --broker-list <bootstrap-address> --topic <topic-name>
    Copy to Clipboard Toggle word wrap

    例如:

    /opt/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-topic
    Copy to Clipboard Toggle word wrap
  2. 在控制台中输入多个信息。按 Enter 将每个消息发送到您的新主题:

    >message 1
    >message 2
    >message 3
    >message 4
    Copy to Clipboard Toggle word wrap

    当 Kafka 自动创建新主题时,您可能会收到主题不存在的警告:

    WARN Error while fetching metadata with correlation id 39 :
    {4-3-16-topic1=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
    Copy to Clipboard Toggle word wrap

    在发送进一步消息后,该警告不应重新显示。

  3. 在新的终端窗口中,启动 Kafka 控制台消费者,并将其配置为从您的新主题开始读取消息。

    /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server <bootstrap-address> --topic <topic-name> --from-beginning
    Copy to Clipboard Toggle word wrap

    例如:

    /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-topic --from-beginning
    Copy to Clipboard Toggle word wrap

    传入的消息显示在消费者控制台中。

  4. 切换到制作者控制台并发送其他消息。检查它们是否在使用者控制台中显示。
  5. 停止 Kafka 控制台制作者,然后按 Ctrl+C

2.7. 停止 AMQ Streams 服务

您可以通过运行脚本来停止 Kafka 和 ZooKeeper 服务。所有到 Kafka 和 ZooKeeper 服务的连接都将被终止。

先决条件

  • AMQ Streams 安装在主机上
  • ZooKeeper 和 Kafka 已启动并正在运行

流程

  1. 停止 Kafka 代理。

    su - kafka
    /opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap
  2. 确认 Kafka 代理已停止。

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap
  3. 停止 ZooKeeper。

    su - kafka
    /opt/kafka/bin/zookeeper-server-stop.sh
    Copy to Clipboard Toggle word wrap

2.8. 配置 AMQ Streams

先决条件

  • AMQ Streams 已下载并安装在主机上

流程

  1. 在文本编辑器中打开 ZooKeeper 和 Kafka 代理配置文件。配置文件位于 :

    ZooKeeper
    /opt/kafka/config/zookeeper.properties
    Kafka
    /opt/kafka/config/server.properties
  2. 编辑配置选项。配置文件采用 Java 属性格式。每个配置选项都应该使用以下格式分开的行:

    <option> = <value>
    Copy to Clipboard Toggle word wrap

    #! 开头的行将被视为注释,将被 AMQ Streams 组件忽略。

    # This is a comment
    Copy to Clipboard Toggle word wrap

    可以使用 \ 在换行 / carriage 返回前直接将值分成多行。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
        username="bob" \
        password="bobs-password";
    Copy to Clipboard Toggle word wrap
  3. 保存更改
  4. 重启 ZooKeeper 或 Kafka 代理
  5. 在集群的所有节点上重复此步骤。

2.9. 从环境变量加载配置值

使用 Environment Variables Configuration Provider 插件从环境变量加载配置数据。您可以使用 Environment Variables Configuration Provider,例如从环境变量加载证书或 JAAS 配置。

您可以使用供应商为所有 Kafka 组件加载配置数据,包括生成者和消费者。例如,使用供应商为 Kafka Connect 连接器配置提供凭证。

先决条件

  • AMQ Streams 已下载并安装在主机上
  • 来自 AMQ Streams 归档的环境变量配置提供程序 JAR 文件

流程

  1. 将 Environment Variables Configuration Provider JAR 文件添加到 Kafka libs 目录。
  2. 在 Kafka 组件的配置属性文件中初始化 Environment Variables Configuration Provider。例如,要初始化 Kafka 的供应商,请将配置添加到 server.properties 文件中。

    配置以启用 Environment Variables Configuration Provider

    config.providers=env
    config.providers.env.class=io.strimzi.kafka.EnvVarConfigProvider
    Copy to Clipboard Toggle word wrap

  3. 添加配置到属性文件,以从环境变量加载数据。

    配置以从环境变量加载数据

    option=${env:MY_ENV_VAR_NAME}
    Copy to Clipboard Toggle word wrap

    使用大写或大写环境变量命名约定,如 MY_ENV_VAR_NAME

  4. 保存更改。
  5. 重启 Kafka 组件。

第 3 章 配置 ZooKeeper

Kafka 使用 ZooKeeper 存储配置数据和集群协调。强烈建议您运行复制 ZooKeeper 实例的集群。

3.1. 基本配置

最重要的 ZooKeeper 配置选项是:

tickTime
ZooKeeper 的基本时间单位(以毫秒为单位)。它用于心跳和会话超时。例如,最小会话超时将是两个 ticks。
dataDir
ZooKeeper 存储其事务日志及其内存数据库的快照的目录。这应该设置为在安装过程中创建的 /var/lib/zookeeper/ 目录。
clientPort
客户端可以连接的端口号。默认值为 2181

名为 config/zookeeper.properties 的 ZooKeeper 配置文件示例位于 AMQ Streams 安装目录中。建议您将 dataDir 目录放在单独的磁盘设备中,以最小化 ZooKeeper 中的延迟。

zookeeper 配置文件应该位于 /opt/kafka/config/zookeeper.properties 中。可在下面找到配置文件的基本示例。该配置文件必须可由 kafka 用户读取。

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
Copy to Clipboard Toggle word wrap

3.2. zookeeper 集群配置

在大多数生产环境中,建议您部署复制 ZooKeeper 实例的集群。稳定且高度可用的 ZooKeeper 集群对于运行可靠的 ZooKeeper 服务非常重要。ZooKeeper 集群也称为 ensembles

ZooKeeper 集群通常由奇数个节点组成。ZooKeeper 要求集群中的大多数节点都已启动并在运行。例如:

  • 在具有三个节点的集群中,至少有两个节点必须启动并在运行。这意味着它可以容许一个节点被停机。
  • 在由五个节点组成的集群中,必须至少有三个节点可用。这意味着它可以容许两个节点处于 down 状态。
  • 在由 7 个节点组成的集群中,必须至少有四个节点可用。这意味着它可以容许三个节点被停机。

在 ZooKeeper 集群中拥有更多节点可以提供更好的弹性和可靠性。

ZooKeeper 可以在带有偶数节点的集群中运行。但是,额外的节点不会增加集群的弹性。具有四个节点的集群至少需要三个节点可用,且只能容忍一个节点被停机。因此,它具有与只有三个节点的集群相同的弹性。

理想情况下,不同的 ZooKeeper 节点应该位于不同的数据中心或网络片段中。增加 ZooKeeper 节点数量会增加集群同步上消耗的工作负载。对于大多数 Kafka 用例,有 3、5 或 7 节点的 ZooKeeper 集群应该足够了。

警告

具有 3 个节点的 ZooKeeper 集群只能容忍 1 个不可用的节点。这意味着,如果在 ZooKeeper 集群的其他节点上进行维护,集群节点会崩溃。

重复的 ZooKeeper 配置支持独立配置支持所有配置选项。为集群配置添加附加选项:

initLimit
允许后续者连接到集群领导机的时间长度。将时间指定为多个 ticks (更多详情请参阅 tickTime 选项 )。
syncLimit
跟随者可以位于领导机后的时间长度。将时间指定为多个 ticks (更多详情请参阅 tickTime 选项 )。
reconfigEnabled
启用或禁用动态重新配置。必须启用才能向 ZooKeeper 集群添加或删除服务器。
standaloneEnabled
启用或禁用独立模式,其中 ZooKeeper 只使用一个服务器运行。

除了以上选项外,每个配置文件还应包含应该是 ZooKeeper 集群成员的服务器列表。服务器记录应以 server.id=hostname:port1:port2 格式指定,其中:

id
ZooKeeper 集群节点的 ID。
hostname
节点侦听连接的主机名或 IP 地址。
port1
用于集群内通信的端口号。
port2
用于领导选举机制的端口号。

以下是具有三个节点的 ZooKeeper 集群配置文件示例:

tickTime=2000
dataDir=/var/lib/zookeeper/
initLimit=5
syncLimit=2
reconfigEnabled=true
standaloneEnabled=false

server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181
Copy to Clipboard Toggle word wrap
注意

在 ZooKeeper 3.5.7 中,必须在使用前将 四个字母单词 添加到 allow 列表中。如需更多信息,请参阅 ZooKeeper 文档

myid 文件

ZooKeeper 集群中的每个节点都必须被分配一个唯一 ID。每个节点的 ID 必须在 myid 文件中配置,并存储在 dataDir 文件夹中,如 /var/lib/zookeeper/myid 文件应当仅包含一个将写入 ID 用作文本的一行。ID 可以是从 1 到 255 的任何整数。您必须在每个集群节点上手动创建此文件。使用此文件,每个 ZooKeeper 实例将使用配置文件中的相应 server. 行的配置来配置其监听程序。它还将使用所有其他 server. 行来识别其他群集成员。

在上例中,有三个节点,因此每个节点都有一个不同的 myid,值分别为 123

3.3. 运行多节点 ZooKeeper 集群

此流程演示了如何将 ZooKeeper 配置为多节点集群。

注意

在 ZooKeeper 3.5.7 中,必须在使用前将 四个字母单词 添加到 allow 列表中。如需更多信息,请参阅 ZooKeeper 文档

先决条件

  • AMQ Streams 安装在用作 ZooKeeper 集群节点的所有主机上。

运行集群

  1. /var/lib/zookeeper/ 中创建 myid 文件。为第一个 ZooKeeper 节点输入 ID 1,为第二个 ZooKeeper 节点输入 2,以此类推。

    su - kafka
    echo "<NodeID>" > /var/lib/zookeeper/myid
    Copy to Clipboard Toggle word wrap

    例如:

    su - kafka
    echo "1" > /var/lib/zookeeper/myid
    Copy to Clipboard Toggle word wrap
  2. 编辑 ZooKeeper /opt/kafka/config/zookeeper.properties 配置文件:

    • 将选项 dataDir 设置为 /var/lib/zookeeper/
    • 配置 initLimitsyncLimit 选项。
    • 配置 reconfigEnabledstandaloneEnabled 选项。
    • 添加所有 ZooKeeper 节点的列表。该列表还应包含当前的节点。

      具有五个成员的 ZooKeeper 集群节点配置示例

      tickTime=2000
      dataDir=/var/lib/zookeeper/
      initLimit=5
      syncLimit=2
      reconfigEnabled=true
      standaloneEnabled=false
      listener.security.protocol.map=PLAINTEXT:PLAINTEXT,REPLICATION:PLAINTEXT
      
      server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
      server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
      server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181
      server.4=172.17.0.4:2888:3888:participant;172.17.0.4:2181
      server.5=172.17.0.5:2888:3888:participant;172.17.0.5:2181
      Copy to Clipboard Toggle word wrap

  3. 使用默认配置文件启动 ZooKeeper。

    su - kafka
    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap
  4. 验证 ZooKeeper 是否正在运行。

    jcmd | grep zookeeper
    Copy to Clipboard Toggle word wrap
  5. 在集群的所有节点上重复此步骤。
  6. 当集群的所有节点都启动并运行后,使用 ncat 实用程序向每个节点发送 stat 命令,以验证所有节点是否都是集群的成员。

    使用 ncat stat 检查节点状态

    echo stat | ncat localhost 2181
    Copy to Clipboard Toggle word wrap

    要使用包括四个字母的命令,如 dump,需要在 zookeeper.properties 中指定 4lw.commands.whitelist=*

    在输出中,您应该会看到节点为 leaderfollower 的信息。

    ncat 命令的输出示例

    ZooKeeper version: 3.4.13-2d71af4dbe22557fda74f9a9b4309b15a7487f03, built on 06/29/2018 00:39 GMT
    Clients:
     /0:0:0:0:0:0:0:1:59726[0](queued=0,recved=1,sent=0)
    
    Latency min/avg/max: 0/0/0
    Received: 2
    Sent: 1
    Connections: 1
    Outstanding: 0
    Zxid: 0x200000000
    Mode: follower
    Node count: 4
    Copy to Clipboard Toggle word wrap

其他资源

3.4. 身份验证

默认情况下,Zoo ZooKeeper 不使用任何类型的身份验证并允许匿名连接。但是,它支持 Java 认证和授权服务(JAAS),可用于使用简单身份验证和安全层 (SASL) 设置身份验证。ZooKeeper 支持在本地存储的凭证中使用 DIGEST-MD5 SASL 机制进行身份验证。

3.4.1. 使用 SASL 进行身份验证

JAAS 使用单独的配置文件进行配置。建议将 JAAS 配置文件放在与 ZooKeeper 配置相同的目录中(/opt/kafka/config/)。推荐的文件名是 zookeeper-jaas.conf。当将 ZooKeeper 集群与多个节点搭配使用时,必须在所有集群节点上创建 JAAS 配置文件。

JAAS 使用上下文进行配置。服务器和客户端等单独部分始终使用单独的 上下文 进行配置。上下文是一个 配置选项,其格式如下:

ContextName {
       param1
       param2;
};
Copy to Clipboard Toggle word wrap

SASL 身份验证为服务器到服务器通信(实例 ZooKeeper 实例之间的沟通)和客户端到服务器通信( Kafka 和 ZooKeeper 之间相互通信)单独配置。服务器到服务器身份验证只适用于带有多个节点的 ZooKeeper 集群。

服务器到服务器身份验证

对于服务器到服务器身份验证,JAAS 配置文件包含两个部分:

  • 服务器配置
  • 客户端配置

使用 DIGEST-MD5 SASL 机制时,Qorum Server 上下文用于配置身份验证服务器。它必须包含所有用户名,以允许以未加密的形式与其密码连接。第二个上下文 QuorumLearner 必须为内置在 ZooKeeper 中的客户端配置。它还包含未加密的形式的密码。以下是 DIGEST-MD5 机制的 JAAS 配置文件示例:

QuorumServer {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       user_zookeeper="123456";
};

QuorumLearner {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       username="zookeeper"
       password="123456";
};
Copy to Clipboard Toggle word wrap

除了 JAAS 配置文件外,还必须通过指定以下选项在常规 ZooKeeper 配置文件中启用 server-to-server 身份验证:

quorum.auth.enableSasl=true
quorum.auth.learnerRequireSasl=true
quorum.auth.serverRequireSasl=true
quorum.auth.learner.loginContext=QuorumLearner
quorum.auth.server.loginContext=QuorumServer
quorum.cnxn.threads.size=20
Copy to Clipboard Toggle word wrap

使用 KAFKA_OPTS 环境变量将 JAAS 配置文件作为 Java 属性传递给 ZooKeeper 服务器:

su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

有关服务器到服务器身份验证的更多信息,请参阅 ZooKeeper wiki

客户端到服务器身份验证

客户端到服务器身份验证配置在与服务器到服务器身份验证相同的 JAAS 文件中。但是,与服务器到服务器身份验证不同,它仅包含服务器配置。配置的客户端部分必须在客户端中进行。有关如何配置 Kafka 代理以使用身份验证连接到 ZooKeeper 的详情,请参考 Kafka 安装 部分。

将服务器上下文添加到 JAAS 配置文件中,以配置客户端到服务器身份验证。对于 DIGEST-MD5 机制,它会配置所有用户名和密码:

Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    user_super="123456"
    user_kafka="123456"
    user_someoneelse="123456";
};
Copy to Clipboard Toggle word wrap

配置 JAAS 上下文后,通过添加以下行在 ZooKeeper 配置文件中启用客户端到服务器身份验证:

requireClientAuthScheme=sasl
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.2=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.3=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
Copy to Clipboard Toggle word wrap

您必须为属于 ZooKeeper 集群的每个服务器添加 authProvider. <ID > 属性。

使用 KAFKA_OPTS 环境变量将 JAAS 配置文件作为 Java 属性传递给 ZooKeeper 服务器:

su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

有关在 Kafka 代理中配置 ZooKeeper 身份验证的更多信息,请参阅 第 4.6 节 “ZooKeeper 身份验证”

此流程描述了如何在 ZooKeeper 集群节点间使用 SASL DIGEST-MD5 机制启用身份验证。

先决条件

  • AMQ Streams 安装在主机上
  • ZooKeeper 集群 配置了多个 节点。

启用 SASL DIGEST-MD5 身份验证

  1. 在所有 ZooKeeper 节点上,创建或编辑 /opt/kafka/config/zookeeper-jaas.conf JAAS 配置文件并添加以下上下文:

    QuorumServer {
           org.apache.zookeeper.server.auth.DigestLoginModule required
           user_<Username>="<Password>";
    };
    
    QuorumLearner {
           org.apache.zookeeper.server.auth.DigestLoginModule required
           username="<Username>"
           password="<Password>";
    };
    Copy to Clipboard Toggle word wrap

    在 JAAS 上下文中,用户名和密码都必须相同。例如:

    QuorumServer {
           org.apache.zookeeper.server.auth.DigestLoginModule required
           user_zookeeper="123456";
    };
    
    QuorumLearner {
           org.apache.zookeeper.server.auth.DigestLoginModule required
           username="zookeeper"
           password="123456";
    };
    Copy to Clipboard Toggle word wrap
  2. 在所有 ZooKeeper 节点上,编辑 /opt/kafka/config/zookeeper.properties ZooKeeper 配置文件并设置以下选项:

    quorum.auth.enableSasl=true
    quorum.auth.learnerRequireSasl=true
    quorum.auth.serverRequireSasl=true
    quorum.auth.learner.loginContext=QuorumLearner
    quorum.auth.server.loginContext=QuorumServer
    quorum.cnxn.threads.size=20
    Copy to Clipboard Toggle word wrap
  3. 逐一重启所有 ZooKeeper 节点。要将 JAAS 配置传递给 ZooKeeper,请使用 KAFKA_OPTS 环境变量。

    su - kafka
    export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

其他资源

此流程描述了如何使用 ZooKeeper 客户端和 ZooKeeper 之间的 SASL DIGEST-MD5 机制启用身份验证。

先决条件

启用 SASL DIGEST-MD5 身份验证

  1. 在所有 ZooKeeper 节点上,创建或编辑 /opt/kafka/config/zookeeper-jaas.conf JAAS 配置文件并添加以下上下文:

    Server {
        org.apache.zookeeper.server.auth.DigestLoginModule required
        user_super="<SuperUserPassword>"
        user<Username1>_="<Password1>" user<USername2>_="<Password2>";
    };
    Copy to Clipboard Toggle word wrap

    超级用户 自动具有 priviledges 管理员。该文件可以包含多个用户,但 Kafka 代理只需要一个额外的用户。Kafka 用户的建议名称为 kafka

    以下示例显示了 客户端到服务器 身份验证的服务器上下文:

    Server {
        org.apache.zookeeper.server.auth.DigestLoginModule required
        user_super="123456"
        user_kafka="123456";
    };
    Copy to Clipboard Toggle word wrap
  2. 在所有 ZooKeeper 节点上,编辑 /opt/kafka/config/zookeeper.properties ZooKeeper 配置文件并设置以下选项:

    requireClientAuthScheme=sasl
    authProvider.<IdOfBroker1>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    authProvider.<IdOfBroker2>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    authProvider.<IdOfBroker3>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    Copy to Clipboard Toggle word wrap

    必须为作为 ZooKeeper 集群一部分的每个节点添加 authProvider. <ID > 属性。一个三节点 ZooKeeper 集群配置示例必须类似如下:

    requireClientAuthScheme=sasl
    authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    authProvider.2=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    authProvider.3=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    Copy to Clipboard Toggle word wrap
  3. 逐一重启所有 ZooKeeper 节点。要将 JAAS 配置传递给 ZooKeeper,请使用 KAFKA_OPTS 环境变量。

    su - kafka
    export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

其他资源

3.5. 授权

ZooKeeper 支持访问控制列表(ACL)来保护存储在其中的数据。Kafka 代理可以自动为他们创建的所有 ZooKeeper 记录配置 ACL 权限,因此没有其他 ZooKeeper 用户都可以修改它们。

有关在 Kafka 代理中启用 ZooKeeper ACL 的详情,请参考 第 4.8 节 “ZooKeeper 授权”

3.6. TLS

ZooKeeper 支持 TLS 进行加密或身份验证。

3.7. 其他配置选项

您可以根据您的用例设置以下额外 ZooKeeper 配置选项:

maxClientCnxns
到 ZooKeeper 集群的单个成员的最大并发客户端连接数。
autopurge.snapRetainCount
ZooKeeper 的 in-memory 数据库的快照数量,该数据库将被保留。默认值为 3
autopurge.purgeInterval
清除快照的时间间隔(以小时为单位)。默认值为 0, 这个选项被禁用。

所有可用的配置选项都可在 ZooKeeper 文档 中找到。

3.8. 日志记录

ZooKeeper 使用 log4j 作为其日志基础架构。日志记录配置默认从 log4j.properties 配置文件读取,该文件应放在 /opt/kafka/config/ 目录中或 classpath 中。可以使用 Java 属性 log4j.configuration 更改配置文件的位置和名称,该配置可使用 KAFKA_LOG4J_OPTS 环境变量传递给 ZooKeeper:

su - kafka
export KAFKA_LOG4J_OPTS="-Dlog4j.configuration=file:/my/path/to/log4j.properties"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

有关 Log4j 配置的更多信息,请参阅 Log4j 文档

第 4 章 配置 Kafka

Kafka 使用属性文件来存储静态配置。配置文件的建议位置为 /opt/kafka/config/server.properties。该配置文件必须可由 kafka 用户读取。

AMQ Streams 附带了一个示例配置文件,它突出显示了该产品的基本和高级功能。它可以在 AMQ Streams 安装目录中的 config/server.properties 下找到。

本章解释了最重要的配置选项。有关支持的 Kafka 代理配置选项的完整列表,请参阅 附录 A, 代理配置参数

4.1. ZooKeeper

Kafka 代理需要 ZooKeeper 存储其配置的一些部分,并协调集群(例如,决定哪个节点是哪个分区的领导)。ZooKeeper 集群的连接详情保存在配置文件中。字段 zookeeper.connect 包含 zookeeper 集群成员的主机名和端口列表。

例如:

zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
Copy to Clipboard Toggle word wrap

Kafka 将使用这些地址来连接到 ZooKeeper 集群。使用这个配置,所有 Kafka znodes 都会直接在 ZooKeeper 数据库的根目录中创建。因此,此类 ZooKeeper 集群只能用于单个 Kafka 集群。要将多个 Kafka 集群配置为使用单个 ZooKeeper 集群,在 Kafka 配置文件中 ZooKeeper 连接字符串末尾指定基本(前缀)路径:

zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181/my-cluster-1
Copy to Clipboard Toggle word wrap

4.2. 监听器

监听器用于连接到 Kafka 代理。每个 Kafka 代理都可以配置为使用多个监听程序。每个侦听器都需要不同的配置,以便它可以侦听不同的端口或网络接口。

要配置监听程序,请编辑配置文件中的 监听程序 属性(/opt/kafka/config/server.properties)。以逗号分隔列表的形式将 监听程序添加到监听程序 属性。配置每个属性,如下所示:

<listenerName>://<hostname>:<port>
Copy to Clipboard Toggle word wrap

如果 <hostname> 为空,则 Kafka 将使用 java.net.InetAddress.getCanonicalHostName() 类作为主机名。

多个监听器的配置示例

listeners=internal-1://:9092,internal-2://:9093,replication://:9094
Copy to Clipboard Toggle word wrap

当 Kafka 客户端连接到 Kafka 集群时,它首先连接到 bootstrap 服务器,这是集群节点之一。bootstrap 服务器为客户端提供集群中所有代理的列表,客户端会单独连接到每个代理。代理列表基于配置 的监听程序

advertised 监听程序

另外,您可以使用 advertised.listeners 属性为客户端提供不同于监听程序属性中给出的一系列不同的监听程序地址。如果其他网络基础架构(如代理)在客户端和代理之间,或者会使用外部 DNS 名称而不是 IP 地址,这很有用。

advertised.listeners 属性的格式与 listeners 属性相同。

公告监听程序的配置示例

listeners=internal-1://:9092,internal-2://:9093
advertised.listeners=internal-1://my-broker-1.my-domain.com:1234,internal-2://my-broker-1.my-domain.com:1235
Copy to Clipboard Toggle word wrap

注意

公告的监听程序的名称必须与监听程序属性中列出的名称匹配。

inter-broker 监听程序

inter-broker 监听程序 用于 Kafka 代理之间的通信。需要代理间通信:

  • 在不同代理间协调工作负载
  • 在存储在不同代理中的分区间复制消息
  • 处理控制器中的管理任务,如分区领导变化

inter-broker 侦听器可以分配给您选择的端口。当配置了多个监听程序时,您可以在 inter.broker.listener.name 属性中定义 inter-broker 监听程序的名称。

在这里,inter-broker 侦听器被命名为 REPLICATION

listeners=REPLICATION://0.0.0.0:9091
inter.broker.listener.name=REPLICATION
Copy to Clipboard Toggle word wrap

control plane 监听程序

默认情况下,控制器和其他代理之间的通信使用 inter-broker 侦听器。控制器负责协调管理任务,如分区领导变化。

您可以为控制器连接启用专用 control plane 侦听器。control plane 侦听器可以分配给您选择的端口。

要启用 control plane 侦听程序,请使用监听程序名称配置 control.plane.listener.name 属性:

listeners=CONTROLLER://0.0.0.0:9090,REPLICATION://0.0.0.0:9091
...
control.plane.listener.name=CONTROLLER
Copy to Clipboard Toggle word wrap

启用 control plane 侦听程序可能会提高集群性能,因为控制器通信不会因为代理中的数据复制不会延迟。数据复制通过 inter-broker 侦听器继续。

如果没有配置 control.plane.listener,控制器连接将使用 inter-broker 侦听器

如需更多信息,请参阅 附录 A, 代理配置参数

4.3. 提交日志

Apache Kafka 将其从制作者接收的所有记录存储在提交日志中。提交日志包含 Kafka 需要提供的记录形式的实际数据。这些不是记录代理所执行的操作的应用程序日志文件。

日志目录

您可以使用 log.dirs 属性文件配置日志目录,将提交日志存储在一个或多个日志目录中。它应设置为在安装过程中创建的 /var/lib/kafka 目录:

log.dirs=/var/lib/kafka
Copy to Clipboard Toggle word wrap

出于性能考虑,您可以将 log.dirs 配置为多个目录,并将其每个目录放在不同的物理设备中,以提高磁盘 I/O 性能。例如:

log.dirs=/var/lib/kafka1,/var/lib/kafka2,/var/lib/kafka3
Copy to Clipboard Toggle word wrap

4.4. 代理 ID

代理 ID 是集群中每个代理的唯一标识符。您可以分配一个大于或等于 0 的整数作为代理 ID。代理 ID 用于在重启或崩溃后识别代理,因此 id 稳定且不会随时间变化。代理 ID 在代理属性文件中配置:

broker.id=1
Copy to Clipboard Toggle word wrap

4.5. 运行多节点 Kafka 集群

这个步骤描述了如何配置和运行 Kafka 作为多节点集群。

先决条件

运行集群

对于 AMQ Streams 集群中的每个 Kafka 代理:

  1. 编辑 /opt/kafka/config/server.properties Kafka 配置文件,如下所示:

    • 在第一个代理中,将 broker.id 设置为 0,在第二个代理中,将其设置为 1,以此类推。
    • zookeeper.connect 选项中配置连接到 ZooKeeper 的详情。
    • 配置 Kafka 侦听程序。
    • 设置提交日志应存储在 logs.dir 目录中的目录。

      在这里,我们看到 Kafka 代理的示例配置:

      broker.id=0
      zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
      listeners=REPLICATION://:9091,PLAINTEXT://:9092
      listener.security.protocol.map=PLAINTEXT:PLAINTEXT,REPLICATION:PLAINTEXT
      inter.broker.listener.name=REPLICATION
      log.dirs=/var/lib/kafka
      Copy to Clipboard Toggle word wrap

      在典型的安装中,每个 Kafka 代理在相同的硬件上运行,只有 broker.id 配置属性在每个代理配置间有所不同。

  2. 使用默认配置文件启动 Kafka 代理。

    su - kafka
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  3. 验证 Kafka 代理是否正在运行。

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap

验证代理

当集群的所有节点都启动并运行后,使用 ncat 实用程序向其中一个 ZooKeeper 节点发送 dump 命令来验证所有节点是否为 Kafka 集群的成员。该命令打印 ZooKeeper 中注册的所有 Kafka 代理。

  1. 使用 ncat stat 检查节点状态。

    echo dump | ncat zoo1.my-domain.com 2181
    Copy to Clipboard Toggle word wrap

    输出应包含您刚才配置和启动的所有 Kafka 代理。

    带有 3 个节点的 Kafka 集群的 ncat 命令的输出示例:

    SessionTracker dump:
    org.apache.zookeeper.server.quorum.LearnerSessionTracker@28848ab9
    ephemeral nodes dump:
    Sessions with Ephemerals (3):
    0x20000015dd00000:
            /brokers/ids/1
    0x10000015dc70000:
            /controller
            /brokers/ids/0
    0x10000015dc70001:
            /brokers/ids/2
    Copy to Clipboard Toggle word wrap

其他资源

4.6. ZooKeeper 身份验证

默认情况下,ZooZ 和 Kafka 之间的连接不会被身份验证。但是,Kafka 和 ZooKeeper 支持 Java 认证和授权服务(JAAS),可用于使用简单身份验证和安全层(SASL)设置身份验证。ZooKeeper 支持在本地存储的凭证中使用 DIGEST-MD5 SASL 机制进行身份验证。

4.6.1. JAAS 配置

ZooKeeper 连接的 SASL 身份验证必须在 JAAS 配置文件中配置。默认情况下,Kafka 将使用名为 Client 的 JAAS 上下文连接到 ZooKeeper。Client 上下文应该在 /opt/kafka/config/jass.conf 文件中配置。上下文必须启用 PLAIN SASL 身份验证,如下例所示:

Client {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="kafka"
    password="123456";
};
Copy to Clipboard Toggle word wrap

4.6.2. 启用 ZooKeeper 身份验证

这个流程描述了如何在连接到 ZooKeeper 时使用 SASL DIGEST-MD5 机制启用身份验证。

先决条件

启用 SASL DIGEST-MD5 身份验证

  1. 在所有 Kafka 代理节点上,创建或编辑 /opt/kafka/config/jaas.conf JAAS 配置文件并添加以下上下文:

    Client {
        org.apache.kafka.common.security.plain.PlainLoginModule required
        username="<Username>"
        password="<Password>";
    };
    Copy to Clipboard Toggle word wrap

    用户名和密码应该与 ZooKeeper 中配置相同。

    以下示例显示了 Client 上下文:

    Client {
        org.apache.kafka.common.security.plain.PlainLoginModule required
        username="kafka"
        password="123456";
    };
    Copy to Clipboard Toggle word wrap
  2. 逐一重启所有 Kafka 代理节点。要将 JAAS 配置传递给 Kafka 代理,请使用 KAFKA_OPTS 环境变量。

    su - kafka
    export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

其他资源

4.7. 授权

Kafka 代理中的授权使用授权器插件实现。

在本节中,我们描述了如何使用 Kafka 提供的 AclAuthorizer 插件。

或者,您可以使用自己的授权插件。例如,如果您使用 基于 OAuth 2.0 令牌的身份验证,您可以使用 OAuth 2.0 授权

4.7.1. 简单 ACL 授权器

Authorizer 插件(包括 AclAuthorizer )通过 authorizer.class.name 属性启用:

authorizer.class.name=kafka.security.auth.AclAuthorizer
Copy to Clipboard Toggle word wrap

所选授权器需要完全限定名称。对于 AclAuthorizer,完全限定名称为 kafka.security.auth.AclAuthorizer

4.7.1.1. ACL 规则

AclAuthorizer 使用 ACL 规则来管理 Kafka 代理的访问。

ACL 规则的格式定义:

主体 P 允许/拒绝来自主机 H 的 Kafka 资源 R 中的操作 O

例如,可以设置一个规则以便用户:

John 可以查看 主机 127.0.0.1中的主题 注释

Host 是 John 进行连接的机器的 IP 地址。

在大多数情况下,用户是生成者或消费者应用程序:

Consumer01 可以对来自主机 127.0.0.1 的消费者组账户写入权限。

如果没有 ACL 规则

如果给定资源没有 ACL 规则,则所有操作都会被拒绝。通过在 Kafka 配置文件 /opt/kafka/config/server.properties 中将属性 allow.everyone.if.no.acl.found 设置为 true 来更改此行为。

4.7.1.2. 主体

principal(主体)代表用户的身份。ID 格式取决于客户端用来连接到 Kafka 的身份验证机制:

  • 在没有身份验证的情况下连接时,user :ANONYMOUS.
  • 使用简单身份验证机制(如 PLAIN 或 SCRAM)连接时,user:< username >。

    例如 User:admin or User:user1

  • 使用 TLS 客户端身份验证 连接时,user:<DistinguishedName >。

    例如 User:CN=user1,O=MyCompany,L=Prague,C=CZ

  • 使用 Kerberos 连接时,user:<Kerberos username >。

DistinguishedName 是与客户端证书区分的名称。

Kerberos 用户名是 Kerberos 主体的主要部分,在使用 Kerberos 连接时默认使用它。您可以使用 sasl.kerberos.principal.to.local.rules 属性来配置 Kafka 主体如何从 Kerberos 主体构建。

4.7.1.3. 用户身份验证

要使用授权,您需要启用身份验证并供您的客户端使用。否则,所有连接都将具有主体 User:ANONYMOUS

有关身份验证方法的更多信息,请参阅加密和身份验证

4.7.1.4. 超级用户

超级用户被允许执行所有操作,无论 ACL 规则是什么。

超级用户使用属性 super.users 在 Kafka 配置文件中定义。

例如:

super.users=User:admin,User:operator
Copy to Clipboard Toggle word wrap
4.7.1.5. 副本代理身份验证

启用授权后,它将适用于所有监听程序和所有连接。这包括用于在代理间复制数据的 inter-broker 连接。如果启用授权,请确保使用身份验证进行代理连接,并授予代理使用足够权利的用户。例如,如果代理之间的身份验证使用 kafka-broker 用户,则超级用户配置必须包含用户名 super.users=User:kafka-broker

4.7.1.6. 支持的资源

您可以将 Kafka ACL 应用到这些资源类型:

  • topics
  • 消费者组
  • 集群
  • TransactionId
  • DelegationToken
4.7.1.7. 支持的操作

AclAuthorizer 授权对资源的操作。

下表中带有 X 的字段标记每个资源支持的操作。

Expand
表 4.1. 资源支持的操作
 topics消费者组集群

X

X

 

X

  

创建

  

X

删除

X

  

更改

X

  

Describe

X

X

X

ClusterAction

  

X

All

X

X

X

4.7.1.8. ACL 管理选项

ACL 规则使用 bin/kafka-acls.sh 工具进行管理,该工具作为 Kafka 发布软件包的一部分提供。

使用 kafka-acls.sh 参数选项来添加、列出和删除 ACL 规则,并执行其他功能。

参数需要双假设惯例,如 --add

Expand
选项类型描述默认

add

操作

添加 ACL 规则。

 

remove

操作

删除 ACL 规则。

 

list

操作

列出 ACL 规则。

 

authorizer

操作

授权者的完全限定类名称。

kafka.security.auth.AclAuthorizer

authorizer-properties

Configuration

传递给授权器进行初始化的键/值对。

对于 AclAuthorizer,示例值为:zookeeper.connect=zoo1.my-domain.com:2181

 

bootstrap-server

资源

主机/端口对以连接到 Kafka 集群。

使用这个选项或 authorizer 选项,不能同时使用它们。

command-config

资源

要传递给 Admin Client 的配置文件,与 bootstrap-server 参数结合使用。

 

cluster

资源

将集群指定为 ACL 资源。

 

topic

资源

将主题名称指定为 ACL 资源。

一个星号(*),用作通配符转换为 所有主题

单个命令可以指定多个 --topic 选项。

 

group

资源

将消费者组名称指定为 ACL 资源。

单个命令可以指定多个 --group 选项。

 

transactional-id

资源

将事务 ID 指定为 ACL 资源。

事务发送意味着,生产者发送到多个分区的所有消息都必须成功发送或不发送它们。

使用通配符星号 (*) 代表所有 ID

 

delegation-token

资源

将委托令牌指定为 ACL 资源。

使用通配符星号 (*) 代表所有令牌

 

resource-pattern-type

Configuration

指定 add 参数的资源模式,或为 listremove 参数指定资源模式过滤器值。

使用 literalprefixed 作为一个资源名称的资源特征类型。

使用 anymatch 作为资源模式过滤器值,或者特定模式类型过滤器。

literal

allow-principal

主体

添加到允许 ACL 规则的主体。

单个命令可以指定多个 --allow-principal 选项。

 

deny-principal

主体

添加到拒绝 ACL 规则的主体。

单个命令可以指定多个 --deny-principal 选项。

 

主体

主体

list 参数一起使用的主体名称,用于返回主体的 ACL 列表。

单个命令可以指定多个 --principal 选项。

 

allow-host

主机

允许访问 --allow-principal 中列出的主体的 IP 地址。

不支持主机名或 CIDR 范围。

如果指定了 --allow-principal,则默认为 * 代表"所有主机"。

deny-host

主机

拒绝访问 --deny-principal 中列出的主体的 IP 地址。

不支持主机名或 CIDR 范围。

如果指定了 --deny-principal,则默认为 * 代表"所有主机"。

operation

操作

允许或拒绝操作。

单个命令可以指定多个Multiple --operation 选项。

All

producer

快捷键

允许或拒绝消息制作者需要的所有操作的快捷方式(主题中为 WRITE 和 DESCRIBE,集群中为 CREATE)。

 

consumer

快捷键

允许或拒绝消息消费者所需的所有操作的快捷方式(主题为READ 和 DESCRIBE,READ on consumer group)。

 

idempotent

快捷键

--producer 参数一起使用时启用 idempotence 的快捷方式,以便消息精确向分区发送一次。

如果制作者被授权根据特定的事务 ID 发送消息,则会自动启用 Idepmotence。

 

force

快捷键

接受所有查询且不提示的快捷方式。

 

4.7.2. 启用授权

此流程描述了如何为 Kafka 代理中的授权启用 AclAuthorizer 插件。

先决条件

流程

  1. 编辑 /opt/kafka/config/server.properties Kafka 配置文件,以使用 AclAuthorizer

    authorizer.class.name=kafka.security.auth.AclAuthorizer
    Copy to Clipboard Toggle word wrap
  2. (重新)启动 Kafka 代理。

其他资源

4.7.3. 添加 ACL 规则

AclAuthorizer 使用访问控制列表(ACL),它定义了一组规则来描述用户可以执行的操作。

此流程描述了如何在 Kafka 代理中使用 AclAuthorizer 插件时添加 ACL 规则。

使用 kafka-acls.sh 工具添加规则,并存储在 ZooKeeper 中。

先决条件

流程

  1. 使用 --add 选项运行 kafka-acls.sh

    示例:

    • 允许使用 MyConsumerGroup 消费者组从 myTopic 读取 user1user2 访问权限。

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2
      
      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2
      
      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
      Copy to Clipboard Toggle word wrap
    • 拒绝 user1 访问从 IP 地址主机 127.0.0.1 读取 myTopic

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
      Copy to Clipboard Toggle word wrap
    • 添加 user1 作为带有 MyConsumerGroupmyTopic 的消费者。

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
      Copy to Clipboard Toggle word wrap

其他资源

4.7.4. 列出 ACL 规则

此流程描述了如何在 Kafka 代理中使用 AclAuthorizer 插件时列出现有的 ACL 规则。

使用 kafka-acls.sh 实用程序列出规则。

先决条件

流程

  • 使用 --list 选项运行 kafka-acls.sh

    例如:

    $ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --list --topic myTopic
    
    Current ACLs for resource `Topic:myTopic`:
    
    User:user1 has Allow permission for operations: Read from hosts: *
    User:user2 has Allow permission for operations: Read from hosts: *
    User:user2 has Deny permission for operations: Read from hosts: 127.0.0.1
    User:user1 has Allow permission for operations: Describe from hosts: *
    User:user2 has Allow permission for operations: Describe from hosts: *
    User:user2 has Deny permission for operations: Describe from hosts: 127.0.0.1
    Copy to Clipboard Toggle word wrap

其他资源

4.7.5. 删除 ACL 规则

此流程描述了如何在 Kafka 代理中使用 AclAuthorizer 插件时删除 ACL 规则。

使用 kafka-acls.sh 工具删除规则。

先决条件

流程

  • 使用 --remove 选项运行 kafka-acls.sh

    示例:

  • 删除 ACL,允许 user1user2 使用 MyConsumerGroup 消费者组从 myTopic 读取。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2
    
    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2
    
    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
    Copy to Clipboard Toggle word wrap
  • 删除 ACL 添加 user1 作为带有 MyConsumerGroupmyTopic 的消费者。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
    Copy to Clipboard Toggle word wrap
  • 删除 ACL 拒绝 user1 从 IP 地址主机 127.0.0.1 读取 myTopic 的访问。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
    Copy to Clipboard Toggle word wrap

其他资源

4.8. ZooKeeper 授权

当在 Kafka 和 ZooKeeper 之间启用身份验证时,您可以使用 ZooKeeper 访问控制列表(ACL)规则自动控制对存储在 ZooKeeper 中的 Kafka 元数据的访问。

4.8.1. ACL 配置

ZooKeeper ACL 规则的强制由 config/server.properties Kafka 配置文件中的 zookeeper.set.acl 属性控制。

属性默认被禁用,并通过设置为 true 来启用:

zookeeper.set.acl=true
Copy to Clipboard Toggle word wrap

如果启用了 ACL 规则,当在 ZooKeeper 中创建 znode 时,只有创建它的 Kafka 用户才可以修改或删除它。所有其他用户都具有只读访问权限。

Kafka 仅为新创建的 ZooKeeper znodes 设置 ACL 规则。如果只在集群首次启动后启用 ACL,zookeeper-security-migration.sh 工具可以在所有现有 znodes 上设置 ACL。

ZooKeeper 中数据的机密性

ZooKeeper 中存储的数据包括:

  • 主题名称及其配置
  • 当使用 SASL SCRAM 身份验证时,salted 和 hash 用户凭证。

但是 ZooKeeper 不存储使用 Kafka 发送和接收的任何记录。ZooKeeper 中存储的数据被认为是非机密。

如果要将数据视为机密(例如,主题名称包含客户 ID),则唯一可用于保护的选项会隔离网络级别的 ZooKeeper,并只允许访问 Kafka 代理。

4.8.2. 为新的 Kafka 集群启用 ZooKeeper ACL

此流程描述了如何在新 Kafka 集群的 Kafka 配置中启用 ZooKeeper ACL。仅在 Kafka 集群首次启动前使用此流程。有关在已在运行的集群中启用 ZooKeeper ACL,请参阅 第 4.8.3 节 “在现有 Kafka 集群中启用 ZooKeeper ACL”

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。
  • zookeeper 集群 已配置并运行
  • ZooKeeper 中启用了 客户端到服务器身份验证。
  • 在 Kafka 代理中,ZooKeeper 身份验证被启用
  • Kafka 代理还没有启动。

流程

  1. 编辑 /opt/kafka/config/server.properties Kafka 配置文件,在所有集群节点上将 zookeeper.set.acl 字段设置为 true

    zookeeper.set.acl=true
    Copy to Clipboard Toggle word wrap
  2. 启动 Kafka 代理。

4.8.3. 在现有 Kafka 集群中启用 ZooKeeper ACL

此流程描述了如何在 Kafka 配置中为正在运行的 Kafka 集群启用 ZooKeeper ACL。使用 zookeeper-security-migration.sh 工具,在所有存在的 znodes 中设置 ZooKeeper ACL。zookeeper-security-migration.sh 可作为 AMQ Streams 的一部分,并可在 bin 目录中找到。

先决条件

启用 ZooKeeper ACL

  1. 编辑 /opt/kafka/config/server.properties Kafka 配置文件,在所有集群节点上将 zookeeper.set.acl 字段设置为 true

    zookeeper.set.acl=true
    Copy to Clipboard Toggle word wrap
  2. 逐一重启所有 Kafka 代理。
  3. 使用 zookeeper-security-migration.sh 工具在所有现有 ZooKeeper znodes 中设置 ACL。

    su - kafka
    cd /opt/kafka
    KAFKA_OPTS="-Djava.security.auth.login.config=./config/jaas.conf"; ./bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=<ZooKeeperURL>
    exit
    Copy to Clipboard Toggle word wrap

    例如:

    su - kafka
    cd /opt/kafka
    KAFKA_OPTS="-Djava.security.auth.login.config=./config/jaas.conf"; ./bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=zoo1.my-domain.com:2181
    exit
    Copy to Clipboard Toggle word wrap

4.9. 加密和身份验证

AMQ Streams 支持加密和身份验证,它们被配置为监听程序配置的一部分。

4.9.1. 侦听器配置

Kafka 代理中的加密和验证会针对每个监听程序进行配置。有关 Kafka 侦听器配置的更多信息,请参阅 第 4.2 节 “监听器”

Kafka 代理中的每个监听程序都使用自己的安全协议配置。配置属性 listener.security.protocol.map 定义哪个监听程序使用哪个安全协议。它将每个侦听器名称映射到其安全协议。支持的安全协议有:

PLAINTEXT
无加密或身份验证的监听程序。
SSL
使用 TLS 加密(可选)使用 TLS 客户端证书进行身份验证的监听程序。
SASL_PLAINTEXT
没有加密的监听程序,但使用基于 SASL 的身份验证。
SASL_SSL
带有基于 TLS 的加密和基于 SASL 的验证的监听程序。

根据以下 监听程序配置

listeners=INT1://:9092,INT2://:9093,REPLICATION://:9094
Copy to Clipboard Toggle word wrap

listener.security.protocol.map 可能如下所示:

listener.security.protocol.map=INT1:SASL_PLAINTEXT,INT2:SASL_SSL,REPLICATION:SSL
Copy to Clipboard Toggle word wrap

这会将侦听器 INT1 配置为使用带有 SASL 身份验证的未加密的连接,侦听器 INT2 使用 SASL 身份验证的加密连接,以及 REPLICATION 接口以使用 TLS 加密(可能与 TLS 客户端身份验证一起使用)。相同的安全协议可以多次使用。以下示例也是有效的配置:

listener.security.protocol.map=INT1:SSL,INT2:SSL,REPLICATION:SSL
Copy to Clipboard Toggle word wrap

这样的配置会将 TLS 加密和 TLS 身份验证用于所有接口。以下章节将更详细地说明如何配置 TLS 和 SASL。

4.9.2. TLS 加密

Kafka 支持 TLS 来加密与 Kafka 客户端的通信。

要使用 TLS 加密和服务器身份验证,必须提供包含私钥和公钥的密钥存储。这通常使用 Java Keystore (JKS)格式的文件来完成。此文件的路径在 ssl.keystore.location 属性中设置。ssl.keystore.password 属性应该用于设置保护密钥存储的密码。例如:

ssl.keystore.location=/path/to/keystore/server-1.jks
ssl.keystore.password=123456
Copy to Clipboard Toggle word wrap

在某些情况下,使用额外的密码来保护私钥。可以使用 ssl.key.password 属性设置此类密码。

Kafka 可以使用由证书颁发机构和自签名密钥签名的密钥。使用由证书颁发机构签名的密钥应始终是首选的方法。为了允许客户端验证其正在连接的 Kafka 代理的身份,证书应始终包含公告的主机名 (CN) 或 Subject Alternative Name(SAN)。

可以将不同的 SSL 配置用于不同的监听程序。所有以 ssl 开头的选项都可以加一个 listener.name.<NameOfTheListener>. 前缀,其中的监听程序的名称必须始终为小写。这将覆盖该特定监听器的默认 SSL 配置。以下示例演示了如何为不同的监听程序使用不同的 SSL 配置:

listeners=INT1://:9092,INT2://:9093,REPLICATION://:9094
listener.security.protocol.map=INT1:SSL,INT2:SSL,REPLICATION:SSL

# Default configuration - will be used for listeners INT1 and INT2
ssl.keystore.location=/path/to/keystore/server-1.jks
ssl.keystore.password=123456

# Different configuration for listener REPLICATION
listener.name.replication.ssl.keystore.location=/path/to/keystore/server-1.jks
listener.name.replication.ssl.keystore.password=123456
Copy to Clipboard Toggle word wrap

其他 TLS 配置选项

除了上面描述的主要 TLS 配置选项外,Kafka 还支持很多选项来微调 TLS 配置。例如,启用或禁用 TLS / SSL 协议或密码套件:

ssl.cipher.suites
启用的密码套件列表。每个密码套件都是用于 TLS 连接的身份验证、加密、MAC 和密钥交换算法的组合。默认情况下启用所有可用的密码套件。
ssl.enabled.protocols
已启用的 TLS/SSL 协议列表。默认为 TLSv1.2,TLSv1.1,TLSv1

有关支持的 Kafka 代理配置选项的完整列表,请参阅 附录 A, 代理配置参数

4.9.3. 启用 TLS 加密

这个步骤描述了如何在 Kafka 代理中启用加密。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。

流程

  1. 为集群中的所有 Kafka 代理生成 TLS 证书。证书应该在其 Common Name 或 Subject Alternative Name 中有其公告和 bootstrap 地址。
  2. 编辑所有集群节点上的 /opt/kafka/config/server.properties Kafka 配置文件:

    • 更改 listener.security.protocol.map 字段,为您要使用 TLS 加密的监听程序指定 SSL 协议。
    • 使用代理证书将 ssl.keystore.location 选项设置为 JKS 密钥存储的路径。
    • ssl.keystore.password 选项设置为用来保护密钥存储的密码。

      例如:

      listeners=UNENCRYPTED://:9092,ENCRYPTED://:9093,REPLICATION://:9094
      listener.security.protocol.map=UNENCRYPTED:PLAINTEXT,ENCRYPTED:SSL,REPLICATION:PLAINTEXT
      ssl.keystore.location=/path/to/keystore/server-1.jks
      ssl.keystore.password=123456
      Copy to Clipboard Toggle word wrap
  3. (重新)启动 Kafka 代理

其他资源

4.9.4. 身份验证

要进行身份验证,您可以使用:

4.9.4.1. TLS 客户端身份验证

TLS 客户端身份验证只能用于已经使用 TLS 加密的连接。要使用 TLS 客户端身份验证,可以为代理提供带有公钥的信任存储。这些密钥可用于验证连接到代理的客户端。truststore 应以 Java Keystore (JKS)格式提供,且应包含证书颁发机构的公钥。所有由信任存储中包含的证书颁发机构签名的公钥和私钥的客户端都将进行身份验证。信任存储的位置使用字段 ssl.truststore.location 设置。如果信任存储受密码保护,则密码应在 ssl.truststore.password 属性中设置。例如:

ssl.truststore.location=/path/to/keystore/server-1.jks
ssl.truststore.password=123456
Copy to Clipboard Toggle word wrap

配置信任存储后,必须使用 ssl.client.auth 属性启用 TLS 客户端身份验证。此属性可以设置为三个不同的值之一:

none
TLS 客户端身份验证已关闭。(默认值)
requested
TLS 客户端身份验证是可选的。系统将要求客户端使用 TLS 客户端证书进行身份验证,但不能选择。
required
客户端需要使用 TLS 客户端证书进行身份验证。

当客户端使用 TLS 客户端身份验证进行身份验证时,经过身份验证的主体名称是与经过身份验证的客户端证书区分名称。例如,具有可分辨名称 CN=someuser 的证书的用户将使用以下主体 CN=someuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown,C=Unknown 进行验证。如果没有使用 TLS 客户端身份验证,并且禁用 SASL,则主体名称为 ANONYMOUS

4.9.4.2. SASL 身份验证

SASL 身份验证是使用 Java 身份验证和授权服务(JAAS)配置的。JAAS 也用于对 Kafka 和 ZooKeeper 之间的连接进行身份验证。JAAS 使用自己的配置文件。此文件的建议位置为 /opt/kafka/config/jaas.conf。该文件必须由 kafka 用户读取。在运行 Kafka 时,使用 Java 系统属性 java.security.auth.login.config 来指定此文件的位置。启动代理节点时,必须将此属性传递给 Kafka:

KAFKA_OPTS="-Djava.security.auth.login.config=/path/to/my/jaas.config"; bin/kafka-server-start.sh
Copy to Clipboard Toggle word wrap

通过普通未加密的连接以及 TLS 连接支持 SASL 身份验证。可以为每个监听程序单独启用 SASL。要启用它,listener.security.protocol.map 中的安全协议必须是 SASL_PLAINTEXTSASL_SSL

Kafka 中的 SASL 身份验证支持多个不同的机制:

PLAIN
根据用户名和密码实施身份验证。用户名和密码存储在 Kafka 配置中。
SCRAM-SHA-256SCRAM-SHA-512
使用 Salted Challenge Response Authentication Mechanism (SCRAM) 实现验证。SCRAM 凭证集中存储在 ZooKeeper 中。当 ZooKeeper 集群节点在私有网络中隔离时,可以使用 SCRAM。
GSSAPI
针对 Kerberos 服务器实现身份验证。
警告

PLAIN 机制通过网络以未加密的格式发送用户名和密码。因此,它应该只与 TLS 加密结合使用。

SASL 机制通过 JAAS 配置文件配置。Kafka 使用名为 KafkaServer 的 JAAS 上下文。在 JAAS 中配置后,必须在 Kafka 配置中启用 SASL 机制。这使用 sasl.enabled.mechanisms 属性完成。此属性包含以逗号分隔的启用机制列表:

sasl.enabled.mechanisms=PLAIN,SCRAM-SHA-256,SCRAM-SHA-512
Copy to Clipboard Toggle word wrap

如果用于 Inter-broker 通信的监听程序使用 SASL,则必须使用属性 sasl.mechanism.inter.broker.protocol 来指定它应使用的 SASL 机制。例如:

sasl.mechanism.inter.broker.protocol=PLAIN
Copy to Clipboard Toggle word wrap

将用于 openshift-broker 通信的用户名和密码,该通信必须使用字段 usernamepasswordKafkaServer JAAS 上下文中指定。

SASL PLAIN

要使用 PLAIN 机制,允许在 JAAS 上下文中指定允许连接的用户名和密码。以下示例显示了为 SASL PLAIN 身份验证配置的上下文。这个示例配置三个不同的用户:

  • admin
  • user1
  • user2
KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";
};
Copy to Clipboard Toggle word wrap

与用户数据库的 JAAS 配置文件应保持在所有 Kafka 代理上同步。

当 SASL PLAIN 也用于内部代理身份验证时,usernamepassword 属性应包含在 JAAS 上下文中:

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="123456"
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";
};
Copy to Clipboard Toggle word wrap

SASL SCRAM

Kafka 中的 SCRAM 身份验证由两个机制组成: SCRAM-SHA-256SCRAM-SHA-512。这些机制仅在使用的哈希算法中有所不同 - SHA-256 与更强大的 SHA-512。要启用 SCRAM 身份验证,HMQ 配置文件必须包括以下配置:

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required;
};
Copy to Clipboard Toggle word wrap

当在 Kafka 配置文件中启用 SASL 身份验证时,可以列出这两个 SCRAM 机制。但是,对于代理间通信,只能选择其中一个。例如:

sasl.enabled.mechanisms=SCRAM-SHA-256,SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
Copy to Clipboard Toggle word wrap

SCRAM 机制的用户凭证存储在 ZooKeeper 中。kafka-configs.sh 工具可用于管理它们。例如,运行以下命令添加用户 user1 和密码 123456 :

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config 'SCRAM-SHA-256=[password=123456],SCRAM-SHA-512=[password=123456]' --entity-type users --entity-name user1
Copy to Clipboard Toggle word wrap

要删除用户凭证,请使用:

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name user1
Copy to Clipboard Toggle word wrap

SASL GSSAPI

使用 Kerberos 进行身份验证的 SASL 机制称为 GSSAPI。要配置 Kerberos SASL 身份验证,应将以下配置添加到 JAAS 配置文件中:

KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
};
Copy to Clipboard Toggle word wrap

Kerberos 主体中的域名必须始终为大写。

除了 JAAS 配置外,还需要在 Kafka 配置中的 sasl.kerberos.service.name 属性中指定 Kerberos 服务名称:

sasl.enabled.mechanisms=GSSAPI
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.kerberos.service.name=kafka
Copy to Clipboard Toggle word wrap

多个 SASL 机制

Kafka 可以同时使用多个 SASL 机制。不同的 JAAS 配置都可以添加到同一上下文中:

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";

    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";

    org.apache.kafka.common.security.scram.ScramLoginModule required;
};
Copy to Clipboard Toggle word wrap

启用多个机制时,客户端将能够选择想要使用的机制。

4.9.5. 启用 TLS 客户端身份验证

此流程描述了如何在 Kafka 代理中启用 TLS 客户端身份验证。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。
  • 启用 TLS 加密。

流程

  1. 准备一个 JKS 信任存储,其中包含用于签署用户证书的证书颁发机构的公钥。
  2. 编辑所有集群节点上的 /opt/kafka/config/server.properties Kafka 配置文件:

    • 使用用户证书的证书颁发机构,将 ssl.truststore.location 选项设置为 JKS 信任存储的路径。
    • ssl.truststore.password 选项设置为用来保护信任存储的密码。
    • ssl.client.auth 选项设置为 required

      例如:

      ssl.truststore.location=/path/to/truststore.jks
      ssl.truststore.password=123456
      ssl.client.auth=required
      Copy to Clipboard Toggle word wrap
  3. (重新)启动 Kafka 代理

其他资源

4.9.6. 启用 SASL PLAIN 身份验证

这个步骤描述了如何在 Kafka 代理中启用 SASL PLAIN 身份验证。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。

流程

  1. 编辑或创建 /opt/kafka/config/jaas.conf JAAS 配置文件。此文件应包含您的所有用户及其密码。确保该文件在所有 Kafka 代理中都是相同的。

    例如:

    KafkaServer {
        org.apache.kafka.common.security.plain.PlainLoginModule required
        user_admin="123456"
        user_user1="123456"
        user_user2="123456";
    };
    Copy to Clipboard Toggle word wrap
  2. 编辑所有集群节点上的 /opt/kafka/config/server.properties Kafka 配置文件:

    • 更改 listener.security.protocol.map 字段,为您要使用 SASL PLAIN 身份验证的监听程序指定 SASL_PLAINTEXTSASL_SSL 协议。
    • sasl.enabled.mechanisms 选项设置为 PLAIN

      例如:

      listeners=INSECURE://:9092,AUTHENTICATED://:9093,REPLICATION://:9094
      listener.security.protocol.map=INSECURE:PLAINTEXT,AUTHENTICATED:SASL_PLAINTEXT,REPLICATION:PLAINTEXT
      sasl.enabled.mechanisms=PLAIN
      Copy to Clipboard Toggle word wrap
  3. 使用 KAFKA_OPTS 环境变量(重新)启动 Kafka 代理,将 JAAS 配置传递给 Kafka 代理。

    su - kafka
    export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

其他资源

4.9.7. 启用 SASL SCRAM 身份验证

此流程描述了如何在 Kafka 代理中启用 SASL SCRAM 身份验证。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。

流程

  1. 编辑或创建 /opt/kafka/config/jaas.conf JAAS 配置文件。为 KafkaServer 上下文启用 ScramLoginModule。确保该文件在所有 Kafka 代理中都是相同的。

    例如:

    KafkaServer {
        org.apache.kafka.common.security.scram.ScramLoginModule required;
    };
    Copy to Clipboard Toggle word wrap
  2. 编辑所有集群节点上的 /opt/kafka/config/server.properties Kafka 配置文件:

    • 更改 listener.security.protocol.map 字段,为您要使用 SASL SCRAM 身份验证的监听程序指定 SASL_PLAINTEXTSASL_SSL 协议。
    • sasl.enabled.mechanisms 选项设置为 SCRAM-SHA-256SCRAM-SHA-512

      例如:

      listeners=INSECURE://:9092,AUTHENTICATED://:9093,REPLICATION://:9094
      listener.security.protocol.map=INSECURE:PLAINTEXT,AUTHENTICATED:SASL_PLAINTEXT,REPLICATION:PLAINTEXT
      sasl.enabled.mechanisms=SCRAM-SHA-512
      Copy to Clipboard Toggle word wrap
  3. 使用 KAFKA_OPTS 环境变量(重新)启动 Kafka 代理,将 JAAS 配置传递给 Kafka 代理。

    su - kafka
    export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

其他资源

4.9.8. 添加 SASL SCRAM 用户

这个步骤描述了如何使用 SASL SCRAM 为身份验证添加新用户。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。
  • 启用 SASL SCRAM 身份验证。

流程

  • 使用 kafka-configs.sh 工具添加新的 SASL SCRAM 用户。

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --alter --add-config 'SCRAM-SHA-512=[password=<Password>]' --entity-type users --entity-name <Username>
    Copy to Clipboard Toggle word wrap

    例如:

    bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config 'SCRAM-SHA-512=[password=123456]' --entity-type users --entity-name user1
    Copy to Clipboard Toggle word wrap

其他资源

4.9.9. 删除 SASL SCRAM 用户

这个流程描述了如何在使用 SASL SCRAM 身份验证时删除用户。

先决条件

  • AMQ Streams 安装在 将用作 Kafka 代理的所有主机上。
  • 启用 SASL SCRAM 身份验证。

流程

  • 使用 kafka-configs.sh 工具删除 SASL SCRAM 用户。

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name <Username>
    Copy to Clipboard Toggle word wrap

    例如:

    bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name user1
    Copy to Clipboard Toggle word wrap

其他资源

4.10. 使用基于 OAuth 2.0 令牌的身份验证

AMQ Streams 支持使用 OAUTHBEARERPLAIN 机制使用 OAuth 2.0 身份验证

OAuth 2.0 启用应用程序之间的基于令牌的标准化身份验证和授权,使用中央授权服务器签发对资源有限访问权限的令牌。

Kafka 代理和客户端都需要配置为使用 OAuth 2.0。您可以配置 OAuth 2.0 身份验证,然后配置 OAuth 2.0 授权

注意

OAuth 2.0 身份验证可与 基于 ACL 的 Kafka 授权 一起使用,无论使用的授权服务器是什么。

使用 OAuth 2.0 身份验证时,应用程序客户端可以访问应用服务器(称为 资源服务器)上的资源,而无需公开帐户凭据。

应用程序客户端通过访问令牌作为身份验证方法传递,应用服务器也可以用来决定要授予的访问权限级别。授权服务器处理访问权限的授予和查询有关访问权限的查询。

在 AMQ Streams 的上下文中:

  • Kafka 代理作为 OAuth 2.0 资源服务器
  • Kafka 客户端充当 OAuth 2.0 应用程序客户端

Kafka 客户端在 Kafka 代理验证。代理和客户端根据需要与 OAuth 2.0 授权服务器通信,以获取或验证访问令牌。

对于 AMQ Streams 的部署,OAuth 2.0 集成提供:

  • Kafka 代理的服务器端 OAuth 2.0 支持
  • 对 Kafka MirrorMaker、Kafka Connect 和 Kafka Bridge 的客户端 OAuth 2.0 支持

RHEL 上的 AMQ Streams 包括两个 OAuth 2.0 库:

kafka-oauth-client
提供名为 io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler 的自定义登录回调处理器类。要处理 OAUTHBEARER 身份验证机制,请使用 Apache Kafka 提供的 OAuthBearerLoginModule 的登录回调处理器。
kafka-oauth-common
提供 kafka-oauth-client 库所需的一些功能的帮助程序库。

提供的客户端库还依赖于一些额外的第三方库,例如: keycloak-corejackson-databindslf4j-api

我们建议使用 Maven 项目来打包您的客户端,以确保包含所有依赖项库。依赖项库可能会在以后的版本中有所变化。

其他资源

4.10.1. OAuth 2.0 身份验证机制

AMQ Streams 支持 OAUTHBEARER 和 PLAIN 机制进行 OAuth 2.0 身份验证。这两种机制都允许 Kafka 客户端与 Kafka 代理建立经过身份验证的会话。客户端、授权服务器和 Kafka 代理之间的身份验证流因每种机制而异。

我们建议您将客户端配置为尽可能使用 OAUTHBEARER。OAUTHBEARER 提供比 PLAIN 更高的安全性,因为客户端凭证不会与 Kafka 代理共享。考虑仅在不支持 OAUTHBEARER 的 Kafka 客户端中使用 PLAIN。

您可以将 Kafka 代理监听程序配置为使用 OAuth 2.0 身份验证来连接客户端。如果需要,您可以在同一 oauth 侦听器上使用 OAUTHBEARER 和 PLAIN 机制。支持每个机制的属性必须在 oauth 侦听器配置中明确指定。

OAUTHBEARER 概述

要使用 OAUTHBEARER,请将 Kafka 代理的 OAuth 身份验证监听程序配置中的 sasl.enabled.mechanisms 设置为 OAUTHBEARER。有关详细配置,请参阅 第 4.10.2 节 “OAuth 2.0 Kafka 代理配置”

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
Copy to Clipboard Toggle word wrap

许多 Kafka 客户端工具使用在协议级别为 OAUTHBEARER 提供基本支持的库。为了支持应用程序开发,AMQ Streams 为上游 Kafka Client Java 库(但不适用于其他库)提供了一个 OAuth 回调处理器。因此,您不需要自行编写回调处理程序。应用客户端可以使用回调处理程序来提供访问令牌。使用 Go 等其他语言编写的客户端必须使用自定义代码连接到授权服务器并获取访问令牌。

使用 OAUTHBEARER 时,客户端发起带有 Kafka 代理进行凭证交换的会话,其中凭证采用由回调处理器提供的 bearer 令牌的形式。使用回调,您可以以三种方式之一配置令牌置备:

  • 客户端 ID 和 Secret (使用 OAuth 2.0 客户端凭证 机制)
  • 一个长期的访问令牌,在配置时手动获取
  • 一个长期的刷新令牌,在配置时手动获取
注意

OAUTHBEARER 身份验证只能由支持协议级别的 OAUTHBEARER 机制的 Kafka 客户端使用。

PLAIN 概述

要使用 PLAIN,请将 PLAIN 添加到 sasl.enabled.mechanisms 的值。

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER,PLAIN
Copy to Clipboard Toggle word wrap

PLAIN 是所有 Kafka 客户端工具使用的简单身份验证机制。要启用 PLAIN 以用于 OAuth 2.0 身份验证,AMQ Streams 提供了 OAuth 2.0 over PLAIN 服务器端的回调。

使用 PLAIN 的 AMQ Streams 实现,客户端凭证不会存储在 ZooKeeper 中。相反,客户端凭证会在兼容授权服务器后进行集中处理,这与使用 OAUTHBEARER 身份验证类似。

当与 OAuth 2.0 over PLAIN 回调一起使用时,Kafka 客户端使用以下方法之一与 Kafka 代理进行身份验证:

  • 客户端 ID 和 secret (使用 OAuth 2.0 客户端凭证 机制)
  • 一个长期的访问令牌,在配置时手动获取

对于这两种方法,客户端必须提供 PLAIN usernamepassword 属性,将凭证传递给 Kafka 代理。客户端使用这些属性传递客户端 ID 和 secret 或用户名和访问令牌。

客户端 ID 和 secret 用于获取访问令牌。

访问令牌作为 password 属性值传递。您可以使用或没有 $accessToken: 前缀来传递访问令牌。

  • 如果您在监听器配置中配置令牌端点(oauth.token.endpoint.uri),则需要前缀。
  • 如果您没有在监听器配置中配置令牌端点(oauth.token.endpoint.uri),则不需要前缀。Kafka 代理将密码解释为原始访问令牌。

如果将密码设置为访问令牌,则必须将用户名设置为 Kafka 代理从访问令牌获取的相同的主体名称。您可以使用 oauth.username.claim, oauth.fallback.username.claim, oauth.fallback.username.prefix, 和 oauth.userinfo.endpoint.uri 属性在监听器中指定用户名提取选项。用户名提取过程还取决于您的授权服务器;特别是,它将客户端 ID 映射到帐户名称。

4.10.1.1. 使用属性或变量配置 OAuth 2.0

您可以使用 Java Authentication and Authorization Service(JAAS)属性或环境变量来配置 OAuth 2.0 设置。

  • JAAS 属性在 server.properties 配置文件中配置,并传递为 listener.name.LISTENER-NAME.oauthbearer.sasl.jaas.config 属性的键值对。
  • 如果使用环境变量,您仍然需要在 server.properties 文件中提供 listener.name.LISTENER-NAME.oauthbearer.sasl.jaas.config 属性,但您可以忽略其他 JAAS 属性。

    您可以使用大写或大写环境变量命名约定。

AMQ Streams OAuth 2.0 库使用以以下内容开头的属性:

4.10.2. OAuth 2.0 Kafka 代理配置

用于 OAuth 2.0 身份验证的 Kafka 代理配置涉及:

  • 在授权服务器中创建 OAuth 2.0 客户端
  • 在 Kafka 集群中配置 OAuth 2.0 身份验证
注意

与授权服务器的关系,Kafka 代理和 Kafka 客户端都被视为 OAuth 2.0 客户端。

4.10.2.1. 授权服务器上的 OAuth 2.0 客户端配置

要配置 Kafka 代理以验证会话启动期间收到的令牌,建议的做法是在授权服务器中创建一个 OAuth 2.0 client 定义(配置为 confidential),并启用了以下客户端凭证:

  • 客户端 ID kafka-broker (例如)
  • 客户端 ID 和 secret 作为身份验证机制
注意

在使用授权服务器的非公共内省端点时,您只需要使用客户端 ID 和 secret。在使用公共授权服务器端点时,通常不需要凭据,如快速本地 JWT 令牌验证一样。

4.10.2.2. Kafka 集群中的 OAuth 2.0 身份验证配置

要在 Kafka 集群中使用 OAuth 2.0 身份验证,您可以在 Kafka server.properties 文件中为 Kafka 集群启用 OAuth 身份验证监听程序配置。至少需要配置。您还可以配置 TLS 侦听器,其中 TLS 用于代理间通信。

您可以使用以下方法之一为授权服务器配置代理以进行令牌验证:

  • 快速本地令牌验证: JWKS 端点与签名的 JWT 格式的访问令牌相结合
  • 内省端点

您可以配置 OAUTHBEARER 或 PLAIN 身份验证,或两者。

以下示例显示了应用 全局 监听器配置的最低配置,这意味着,内部代理间通信通过与应用程序客户端相同的监听程序进行。

这个示例还显示了一个特定监听程序的 OAuth 2.0 配置,在其中您可以指定 listener.name.LISTENER-NAME.sasl.enabled.mechanisms 而不是 sasl.enabled.mechanismsLISTENER-NAME 是监听器的区分大小写的名称。在这里,我们将侦听器的 CLIENT 命名为 listener.name.client.sasl.enabled.mechanisms

这个示例使用 OAUTHBEARER 身份验证。

示例:使用 JWKS 端点进行 OAuth 2.0 身份验证的最小监听程序配置

sasl.enabled.mechanisms=OAUTHBEARER 
1

listeners=CLIENT://0.0.0.0:9092 
2

listener.security.protocol.map=CLIENT:SASL_PLAINTEXT 
3

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER 
4

sasl.mechanism.inter.broker.protocol=OAUTHBEARER 
5

inter.broker.listener.name=CLIENT 
6

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler 
7

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ 
8

  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \ 
9

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \ 
10

  oauth.username.claim="preferred_username"  \ 
11

  oauth.client.id="kafka-broker" \ 
12

  oauth.client.secret="kafka-secret" \ 
13

  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/token" ; 
14

listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler 
15

listener.name.client.oauthbearer.connections.max.reauth.ms=3600000 
16
Copy to Clipboard Toggle word wrap

1
为通过 SASL 进行凭证交换启用 OAUTHBEARER 机制。
2
配置要连接的客户端应用程序的监听程序。系统的 hostname 用作公告的主机名,客户端必须可以解析该主机名才能重新连接。本例中,侦听器名为 CLIENT
3
指定监听器的频道协议。SASL_SSL 用于 TLS。SASL_PLAINTEXT 用于未加密的连接(无 TLS),但存在丢失和截获 TCP 连接层的风险。
4
CLIENT 侦听器指定 OAUTHBEARER 机制。客户端名称(CLIENT)通常在 listeners 属性中使用大写指定,对于 listener.name 属性是小写 (listener.name.client),当为 listener.name.client.* 属性的一部分时是小写。
5
指定用于代理间通信的 OAUTHBEARER 机制。
6
指定用于代理间通信的监听程序。配置需要有效的规格。
7
在客户端监听器上配置 OAuth 2.0 身份验证。
8
配置客户端和 inter-broker 通信的身份验证设置。oauth.client.idoauth.client.secretauth.token.endpoint.uri 属性与 inter-broker 配置相关。
9
有效的签发者 URI。只有此签发者发布的访问令牌才会被接受。例如 :https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
10
JWKS 端点 URL。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
11
在令牌中包含实际用户名的令牌声明(或密钥)。用户名是用于识别用户的 主体。该值将取决于身份验证流和使用的授权服务器。
12
Kafka 代理的客户端 ID,适用于所有代理。这是在 授权服务器注册为 kafka-broker的客户端
13
Kafka 代理的 secret,适用于所有代理。
14
到您的授权服务器的 OAuth 2.0 令牌端点 URL。对于生产环境,请始终使用 https:// urls。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token
15
为代理间通信启用(且只需要)OAuth 2.0 身份验证。
16
(可选)当令牌过期时强制会话到期,并激活 Kafka 重新验证机制。如果指定的值小于访问令牌保留的时间,则客户端必须在实际令牌到期前重新验证。默认情况下,当访问令牌过期时,会话不会过期,客户端也不会尝试重新身份验证。

以下示例显示了 TLS 侦听器的最小配置,其中 TLS 用于代理间通信。

示例:用于 OAuth 2.0 身份验证的 TLS 侦听器配置

listeners=REPLICATION://kafka:9091,CLIENT://kafka:9092 
1

listener.security.protocol.map=REPLICATION:SSL,CLIENT:SASL_PLAINTEXT 
2

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
inter.broker.listener.name=REPLICATION
listener.name.replication.ssl.keystore.password=KEYSTORE-PASSWORD 
3

listener.name.replication.ssl.truststore.password=TRUSTSTORE-PASSWORD
listener.name.replication.ssl.keystore.type=JKS
listener.name.replication.ssl.truststore.type=JKS
listener.name.replication.ssl.endpoint.identification.algorithm=HTTPS 
4

listener.name.replication.ssl.secure.random.implementation=SHA1PRNG 
5

listener.name.replication.ssl.keystore.location=PATH-TO-KEYSTORE 
6

listener.name.replication.ssl.truststore.location=PATH-TO-TRUSTSTORE 
7

listener.name.replication.ssl.client.auth=required 
8

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \
  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \
  oauth.username.claim="preferred_username" ; 
9
Copy to Clipboard Toggle word wrap

1
相互代理通信和客户端应用程序需要单独的配置。
2
REPLICATION 侦听器配置为使用 TLS,并将 CLIENT 侦听器配置为通过未加密的通道使用 SASL。客户端可能会在生产环境中使用加密的频道(SASL_SSL)。
3
ssl. 属性定义 TLS 配置。
4
随机数生成器实施。如果没有设置,则使用 Java platform SDK 默认。
5
主机名验证。如果设置为空字符串,则会关闭主机名验证。如果没有设置,则默认值为 HTTPS,它会强制对服务器证书进行主机名验证。
6
侦听器的密钥存储的路径。
7
侦听器的信任存储的路径。
8
指定 REPLICATION 侦听器的客户端必须在建立 TLS 连接时与客户端证书进行身份验证(用于代理连接)。
9
为 OAuth 2.0 配置 CLIENT 侦听器。与授权服务器的连接应使用安全 HTTPS 连接。

以下示例显示了使用 PLAIN 身份验证机制通过 SASL 进行凭证交换的 OAuth 2.0 身份验证的最低配置。使用快速的本地令牌验证。

示例:用于 PLAIN 验证的最小监听程序配置

listeners=CLIENT://0.0.0.0:9092 
1

listener.security.protocol.map=CLIENT:SASL_PLAINTEXT 
2

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER,PLAIN 
3

sasl.mechanism.inter.broker.protocol=OAUTHBEARER 
4

inter.broker.listener.name=CLIENT 
5

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler 
6

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ 
7

  oauth.valid.issuer.uri="http://AUTH_SERVER/auth/realms/REALM" \ 
8

  oauth.jwks.endpoint.uri="https://AUTH_SERVER/auth/realms/REALM/protocol/openid-connect/certs" \ 
9

  oauth.username.claim="preferred_username"  \ 
10

  oauth.client.id="kafka-broker" \ 
11

  oauth.client.secret="kafka-secret" \ 
12

  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/token" ; 
13

listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler 
14

listener.name.client.plain.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.plain.JaasServerOauthOverPlainValidatorCallbackHandler 
15

listener.name.client.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ 
16

  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \ 
17

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \ 
18

  oauth.username.claim="preferred_username"  \ 
19

  oauth.token.endpoint.uri="http://AUTH_SERVER/auth/realms/REALM/protocol/openid-connect/token" ; 
20

connections.max.reauth.ms=3600000 
21
Copy to Clipboard Toggle word wrap

1
为要连接的客户端应用程序配置监听程序(本例中为 CLIENT )。系统的 hostname 用作公告的主机名,客户端必须可以解析该主机名才能重新连接。由于这是唯一配置的监听程序,它也用于代理间通信。
2
将示例 CLIENT 侦听器配置为通过未加密的频道使用 SASL。在生产环境中,客户端应使用加密频道(SASL_SSL)来保护对 TCP 连接层进行窃取和截获。
3
为通过 SASL 和 OAUTHBEARER 进行凭证交换启用 PLAIN 身份验证机制。OAUTHBEARER 也被指定,因为代理间通信需要它。Kafka 客户端可以选择使用哪些机制进行连接。
4
为代理间通信指定 OAUTHBEARER 身份验证机制。
5
为内部代理通信指定监听器(本例中为 CLIENT)。配置需要有效。
6
为 OAUTHBEARER 机制配置服务器回调处理程序。
7
使用 OAUTHBEARER 机制为客户端和内部代理通信配置身份验证设置。oauth.client.idoauth.client.secretoauth.token.endpoint.uri 属性与 inter-broker 配置相关。
8
有效的签发者 URI。只有来自此签发者的访问令牌才被接受。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
9
JWKS 端点 URL。例如 :https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
10
在令牌中包含实际用户名的令牌声明(或密钥)。用户名是标识用户 的主体。该值取决于身份验证流和使用的授权服务器。
11
Kafka 代理的客户端 ID,适用于所有代理。这是在 授权服务器注册为 kafka-broker的客户端
12
Kafka 代理的 secret (所有代理都相同)。
13
到您的授权服务器的 OAuth 2.0 令牌端点 URL。对于生产环境,请始终使用 https:// urls。例如 :https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token
14
为代理间通信启用 OAuth 2.0 身份验证。
15
PLAIN 身份验证配置服务器回调处理程序。
16
使用 PLAIN 身份验证为客户端通信配置身份验证设置。

oauth.token.endpoint.uri 是一个可选属性,它使用 OAuth 2.0 客户端凭证机制启用 OAuth 2.0 over PLAIN。

17
有效的签发者 URI。只有来自此签发者的访问令牌才被接受。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
18
JWKS 端点 URL。例如 :https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
19
在令牌中包含实际用户名的令牌声明(或密钥)。用户名是标识用户 的主体。该值取决于身份验证流和使用的授权服务器。
20
到您的授权服务器的 OAuth 2.0 令牌端点 URL。PLAIN 机制的其他配置。如果指定,客户端可以通过在使用 $accessToken: 前缀将访问令牌 作为密码 传递来通过 PLAIN 进行身份验证。

对于生产环境,请始终使用 https:// urls。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token

21
(可选)当令牌过期时强制会话到期,并激活 Kafka 重新验证机制。如果指定的值小于访问令牌保留的时间,则客户端必须在实际令牌到期前重新验证。默认情况下,当访问令牌过期时,会话不会过期,客户端也不会尝试重新身份验证。
4.10.2.3. 快速的本地 JWT 令牌验证配置

快速本地 JWT 令牌验证会在本地检查 JWT 令牌签名。

本地检查可确保令牌:

  • 使用一个访问令牌的 Bearer 的(typ)声明值符合类型
  • 有效(未过期)
  • 具有与 validIssuerURI 匹配的签发者

在配置监听程序时 指定有效的签发者 URI,以便任何未由授权服务器发布的令牌都被拒绝。

授权服务器不需要在快速本地 JWT 令牌验证过程中联系。您可以通过指定由 OAuth 2.0 授权服务器公开的 JWKs 端点 URI 来激活快速本地 JWT 令牌验证。端点包含验证已签名的 JWT 令牌的公钥,这些令牌由 Kafka 客户端作为凭证发送。

注意

所有与授权服务器通信都应使用 HTTPS 执行。

对于 TLS 侦听器,您可以配置证书信任存储并指向信任存储文件。

快速本地 JWT 令牌验证的属性示例

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \ 
1

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \ 
2

  oauth.jwks.refresh.seconds="300" \ 
3

  oauth.jwks.refresh.min.pause.seconds="1" \ 
4

  oauth.jwks.expiry.seconds="360" \ 
5

  oauth.username.claim="preferred_username" \ 
6

  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \ 
7

  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \ 
8

  oauth.ssl.truststore.type="PKCS12" ; 
9
Copy to Clipboard Toggle word wrap

1
有效的签发者 URI。只有此签发者发布的访问令牌才会被接受。例如 :https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
2
JWKS 端点 URL。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
3
端点刷新之间的周期(默认为 300)。
4
连续尝试刷新 JWKS 公钥之间的最小暂停(以秒为单位)。当遇到未知签名密钥时,JWKS 密钥刷新在常规定期调度后调度,且至少在最后一次刷新尝试后出现指定暂停。刷新密钥遵循 exponential backoff 规则,重试不成功刷新,且持续增加暂停,直到它到达 oauth.jwks.refresh.seconds。默认值为 1。
5
JWKs 证书在证书过期前被视为有效。默认为 360 秒。如果您指定了较长的时间,请考虑允许访问撤销的证书的风险。
6
在令牌中包含实际用户名的令牌声明(或密钥)。用户名是用于识别用户的 主体。该值将取决于身份验证流和使用的授权服务器。
7
TLS 配置中使用的信任存储的位置。
8
访问信任存储的密码。
9
PKCS #12 格式的 truststore 类型。
4.10.2.4. OAuth 2.0 内省端点配置

使用 OAuth 2.0 内省端点进行令牌验证会将接收的访问令牌视为不透明。Kafka 代理向内省端点发送访问令牌,该端点使用验证所需的令牌信息做出响应。最重要的是,如果特定访问令牌有效,它会返回最新的信息,以及令牌何时过期的信息。

要配置基于 OAuth 2.0 内省的验证,您可以指定一个 内省端点 URI,而不是为快速本地 JWT 令牌验证指定的 JWKs 端点 URI。根据授权服务器,通常必须指定 client IDclient secret,因为内省端点通常受到保护。

内省端点的属性示例

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/introspection" \ 
1

  oauth.client.id="kafka-broker" \ 
2

  oauth.client.secret="kafka-broker-secret" \ 
3

  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \ 
4

  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \ 
5

  oauth.ssl.truststore.type="PKCS12" \ 
6

  oauth.username.claim="preferred_username" ; 
7
Copy to Clipboard Toggle word wrap

1
OAuth 2.0 内省端点 URI。例如: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token/introspect
2
Kafka 代理的客户端 ID。
3
Kafka 代理的 secret。
4
TLS 配置中使用的信任存储的位置。
5
访问信任存储的密码。
6
PKCS #12 格式的 truststore 类型。
7
在令牌中包含实际用户名的令牌声明(或密钥)。用户名是用于识别用户的 主体oauth.username.claim 的值取决于使用的授权服务器。

4.10.3. Kafka 代理的会话重新身份验证

您可以将 OAuth 侦听程序配置为使用 Kafka 会话在 Kafka 客户端和 Kafka 代理之间对 OAuth 2.0 会话进行重新身份验证。这个机制在定义的时间后强制实施客户端和代理之间经过身份验证的会话的过期。当会话过期时,客户端会立即通过重复使用现有连接而不是丢弃它来启动新的会话。

会话重新身份验证默认为禁用。您可以在 server.properties 文件中启用它。为启用了 OAUTHBEARER 或 PLAIN 的 TLS 侦听器设置 connections.max.reauth.ms 属性作为 SASL 机制。

您可以指定每个监听器的会话重新身份验证。例如:

listener.name.client.oauthbearer.connections.max.reauth.ms=3600000
Copy to Clipboard Toggle word wrap

会话重新身份验证必须由客户端使用的 Kafka 客户端库支持。

会话重新身份验证可用于快速 本地 JWT内省端点 令牌验证。

客户端重新身份验证

当代理的经过身份验证的会话过期时,客户端必须通过向代理发送一个新的有效访问令牌来重新验证到现有会话,而无需丢弃连接。

如果令牌验证成功,则使用现有连接启动新的客户端会话。如果客户端无法重新验证,代理会在进一步尝试发送或接收消息时关闭连接。如果代理上启用了重新身份验证机制,则使用 Kafka 客户端库 2.2 或更高版本的 Java 客户端会自动重新验证。

如果使用,会话重新身份验证也适用于刷新令牌。当会话过期时,客户端会使用其刷新令牌来刷新访问令牌。然后,客户端使用新的访问令牌来重新验证现有连接。

OAUTHBEARER 和 PLAIN 的会话到期

配置会话重新身份验证后,会话到期对于 OAUTHBEARER 和 PLAIN 身份验证是不同的。

对于 OAUTHBEARER 和 PLAIN,使用 客户端 ID 和 secret 方法:

  • 代理的身份验证会话将在配置的 connections.max.reauth.ms 过期。
  • 如果访问令牌在配置的时间前过期,会话将提前过期。

对于 PLAIN,使用 长期访问令牌 方法:

  • 代理的身份验证会话将在配置的 connections.max.reauth.ms 过期。
  • 如果访问令牌在配置的时间前过期,则重新身份验证将失败。虽然尝试尝试会话重新身份验证,但 PLAIN 没有刷新令牌的机制。

如果没有配置 connection.max.reauth.ms,OAUTHBEARER 和 PLAIN 客户端可以无限期地连接到代理,而无需重新验证。经过身份验证的会话不会因为访问令牌到期而终止。但是,这可在配置授权时考虑,例如,使用 keycloak 授权或安装自定义授权器。

4.10.4. OAuth 2.0 Kafka 客户端配置

Kafka 客户端被配置为:

  • 从授权服务器获取有效访问令牌(客户端 ID 和 Secret)所需的凭证
  • 使用授权服务器提供的工具获取有效的长期访问令牌或刷新令牌

发送到 Kafka 代理的唯一信息是访问令牌。用于与授权服务器进行身份验证的凭证从不会发送到代理。

当客户端获取访问令牌时,不需要进一步与授权服务器通信。

最简单的机制是使用客户端 ID 和 Secret 进行身份验证。使用长期的访问令牌或长期的刷新令牌会增加复杂性,因为对授权服务器工具还有额外的依赖。

注意

如果您使用长期的访问令牌,您可能需要在授权服务器中配置客户端来提高令牌的最大生命周期。

如果 Kafka 客户端没有直接配置访问令牌,客户端会在 Kafka 会话发起授权服务器的过程中交换访问令牌的凭证。Kafka 客户端交换:

  • 客户端 ID 和 Secret
  • 客户端 ID、刷新令牌和(可选)Secret

4.10.5. OAuth 2.0 客户端身份验证流

OAuth 2.0 身份验证流程取决于底层 Kafka 客户端和 Kafka 代理配置。流还必须由使用的授权服务器支持。

Kafka 代理监听程序配置决定客户端如何使用访问令牌进行身份验证。客户端可以传递客户端 ID 和机密来请求访问令牌。

如果侦听器配置为使用 PLAIN 身份验证,客户端可以通过客户端 ID 和 secret 或用户名和访问令牌进行身份验证。这些值作为 PLAIN 机制 usernamepassword 属性传递。

侦听器配置支持以下令牌验证选项:

  • 您可以根据 JWT 签名检查和本地令牌内省使用快速本地令牌验证,而无需联系授权服务器。授权服务器提供带有公共证书的 JWKS 端点,用于验证令牌中的签名。
  • 您可以使用调用授权服务器提供的令牌内省端点。每次建立新的 Kafka 代理连接时,代理会将从客户端接收的访问令牌传递给授权服务器。Kafka 代理检查响应,以确认令牌是否有效。
注意

授权服务器可能只允许使用不透明访问令牌,这意味着无法进行本地令牌验证。

也可以为以下类型的身份验证配置 Kafka 客户端凭证:

  • 使用之前生成的长期访问令牌直接进行本地访问
  • 与授权服务器联系,以获取要发布的新访问令牌(使用客户端 ID 和 secret,或刷新令牌)

您可以使用 SASL OAUTHBEARER 机制为 Kafka 身份验证使用以下通信流。

使用客户端 ID 和 secret 的客户端以及代理委派到授权服务器的验证

Client using client ID and secret with broker delegating validation to authorization server

  1. Kafka 客户端使用客户端 ID 和 secret 从授权服务器请求访问令牌,以及可选的刷新令牌。
  2. 授权服务器生成新的访问令牌。
  3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
  4. Kafka 代理通过使用自己的客户端 ID 和 secret,在授权服务器上调用令牌内省端点来验证访问令牌。
  5. 如果令牌有效,则会建立 Kafka 客户端会话。

使用客户端 ID 和 secret 的客户端,代理执行快速本地令牌验证

Client using client ID and secret with broker performing fast local token validation

  1. Kafka 客户端使用令牌端点、使用客户端 ID 和 secret 以及刷新令牌(可选)从令牌端点验证。
  2. 授权服务器生成新的访问令牌。
  3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
  4. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省验证访问令牌。

使用长期访问令牌的客户端,带有代理委派验证到授权服务器

Client using long-lived access token with broker delegating validation to authorization server

  1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期访问令牌。
  2. Kafka 代理通过使用自己的客户端 ID 和 secret,在授权服务器上调用令牌内省端点来验证访问令牌。
  3. 如果令牌有效,则会建立 Kafka 客户端会话。

使用长期访问令牌的客户端,代理执行快速本地验证

Client using long-lived access token with broker performing fast local validation

  1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期访问令牌。
  2. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省验证访问令牌。
警告

快速的本地 JWT 令牌签名验证仅适用于短期的令牌,因为如果已撤销令牌,就不会通过授权服务器检查该授权服务器。令牌到期时间写入到令牌,但可以随时进行撤销,因此不能在不联系授权服务器的情况下被考虑。任何发布的令牌都将被视为有效,直到过期为止。

您可以使用 OAuth PLAIN 机制对 Kafka 身份验证使用以下通信流。

使用客户端 ID 和 secret 的客户端以及代理获取客户端的访问令牌

Client using a client ID and secret with the broker obtaining the access token for the client

  1. Kafka 客户端或传递一个 clientId 作为用户名,以及一个 secret 作为密码。
  2. Kafka 代理使用令牌端点将 clientIdsecret 传递给授权服务器。
  3. 如果客户端凭据无效,授权服务器会返回一个新的访问令牌或错误。
  4. Kafka 代理使用以下方法之一验证令牌:

    1. 如果指定了令牌内省端点,Kafka 代理会通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立会话。
    2. 如果使用本地令牌内省,则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

使用没有客户端 ID 和 secret 的长期访问令牌的客户端

Client using a long-lived access token without a client ID and secret

  1. Kafka 客户端会传递用户名和密码。密码提供在运行客户端前手动配置的访问令牌值。
  2. 密码通过或不使用 $accessToken: 字符串前缀来传递,具体取决于 Kafka 代理侦听程序是否配置了令牌端点来进行身份验证。

    1. 如果配置了令牌端点,则密码应加上前缀 $accessToken:,以便代理知道 password 参数包含访问令牌,而不是客户端 secret。Kafka 代理将用户名解释为帐户用户名。
    2. 如果没有在 Kafka 代理监听程序上配置令牌端点(强制 no-client-credentials 模式),则密码应在没有前缀的情况下提供访问令牌。Kafka 代理将用户名解释为帐户用户名。在这个模式中,客户端不使用客户端 ID 和 secret,password 参数始终解释为原始访问令牌。
  3. Kafka 代理使用以下方法之一验证令牌:

    1. 如果指定了令牌内省端点,Kafka 代理会通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立会话。
    2. 如果使用本地令牌内省,则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

4.10.6. 配置 OAuth 2.0 身份验证

OAuth 2.0 用于在 Kafka 客户端和 AMQ Streams 组件间交互。

要将 OAuth 2.0 用于 AMQ Streams,您必须:

这个步骤描述了如何将 Red Hat Single Sign-On 部署为授权服务器,并配置它以与 AMQ Streams 集成。

授权服务器为身份验证和授权提供了一个中央点,以及用户、客户端和权限的管理。Red Hat Single Sign-On 具有域概念,其中 realm 代表一组独立的用户、客户端、权限和其他配置。您可以使用默认 master 域,或创建新域。每个 realm 会公开自己的 OAuth 2.0 端点,这意味着应用程序客户端和应用服务器都需要使用相同的域。

要将 OAuth 2.0 与 AMQ Streams 搭配使用,请使用部署 Red Hat Single Sign-On 来创建和管理身份验证域。

注意

如果您已经部署了 Red Hat Single Sign-On,您可以跳过部署步骤并使用您的当前部署。

开始前

您将需要熟悉使用 Red Hat Single Sign-On。

有关安装和管理说明,请参阅:

先决条件

  • AMQ Streams 和 Kafka 正在运行

对于 Red Hat Single Sign-On 部署:

流程

  1. 安装 Red Hat Single Sign-On。

    您可以从 ZIP 文件或使用 RPM 安装。

  2. 登录到 Red Hat Single Sign-On Admin 控制台,为 AMQ Streams 创建 OAuth 2.0 策略。

    部署 Red Hat Single Sign-On 时会提供登录详情。

  3. 创建并启用 realm。

    您可以使用现有的 master 域。

  4. 如果需要,调整域的会话和令牌超时。
  5. 创建名为 kafka-broker 的客户端。
  6. Settings 选项卡中设置:

    • 访问类型机密
    • Standard Flow EnabledOFF 为这个客户端禁用 Web 登录
    • Service Accounts EnabledON,允许此客户端在其自己的名称中进行身份验证
  7. 在继续操作前,点 Save
  8. Credentials 选项卡中,记录使用 AMQ Streams Kafka 集群配置的 secret。
  9. 对将连接到 Kafka 代理的任何应用程序客户端重复客户端创建步骤。

    为每个新客户端创建一个定义。

    在配置中,您将使用名称作为客户端 ID。

接下来要做什么

部署和配置授权服务器后,将 Kafka 代理配置为使用 OAuth 2.0

4.10.6.2. 为 Kafka 代理配置 OAuth 2.0 支持

此流程描述了如何配置 Kafka 代理,以便代理监听程序可以使用授权服务器使用 OAuth 2.0 身份验证。

我们建议通过配置 TLS 侦听程序在加密接口中使用 OAuth 2.0。不建议使用 plain 监听程序。

使用支持您选择的授权服务器的属性配置 Kafka 代理,以及您要实现的授权类型。

开始前

有关 Kafka 代理监听程序的配置和验证的更多信息,请参阅:

有关监听器配置中使用的属性的描述,请参阅:

先决条件

  • AMQ Streams 和 Kafka 正在运行
  • 部署 OAuth 2.0 授权服务器

流程

  1. server.properties 文件中配置 Kafka 代理监听程序配置。

    例如,使用 OAUTHBEARER 机制:

    sasl.enabled.mechanisms=OAUTHBEARER
    listeners=CLIENT://0.0.0.0:9092
    listener.security.protocol.map=CLIENT:SASL_PLAINTEXT
    listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
    sasl.mechanism.inter.broker.protocol=OAUTHBEARER
    inter.broker.listener.name=CLIENT
    listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
    listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    Copy to Clipboard Toggle word wrap
  2. 将代理连接设置配置为 listener.name.client.oauthbearer.sasl.jaas.config 的一部分。

    此处的示例显示连接配置选项。

    示例 1:使用 JWKS 端点配置进行本地令牌验证

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME" \
      oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs" \
      oauth.jwks.refresh.seconds="300" \
      oauth.jwks.refresh.min.pause.seconds="1" \
      oauth.jwks.expiry.seconds="360" \
      oauth.username.claim="preferred_username" \
      oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
      oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
      oauth.ssl.truststore.type="PKCS12" ;
    listener.name.client.oauthbearer.connections.max.reauth.ms=3600000
    Copy to Clipboard Toggle word wrap

    示例 2:通过 OAuth 2.0 内省端点将令牌验证委托给授权服务器

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/introspection" \
      # ...
    Copy to Clipboard Toggle word wrap

  3. 如果需要,配置对授权服务器的访问。

    生产环境通常需要这一步,除非使用 service mesh 等技术来配置容器外的安全频道。

    1. 提供用于连接安全授权服务器的自定义信任存储。对授权服务器的访问始终需要 SSL。

      设置属性来配置信任存储。

      例如:

      listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
        # ...
        oauth.client.id="kafka-broker" \
        oauth.client.secret="kafka-broker-secret" \
        oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
        oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
        oauth.ssl.truststore.type="PKCS12" ;
      Copy to Clipboard Toggle word wrap
    2. 如果证书主机名与访问 URL 主机名不匹配,您可以关闭证书主机名验证:

      oauth.ssl.endpoint.identification.algorithm=""
      Copy to Clipboard Toggle word wrap

      检查可确保与授权服务器的连接是真实的。您可能想要在非生产环境中关闭验证。

  4. 根据您选择的身份验证流配置附加属性。

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      # ...
      oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token" \ 
    1
    
      oauth.custom.claim.check="@.custom == 'custom-value'" \ 
    2
    
      oauth.scope="SCOPE" \ 
    3
    
      oauth.check.audience="true" \ 
    4
    
      oauth.audience="AUDIENCE" \ 
    5
    
      oauth.valid.issuer.uri="https://https://AUTH-SERVER-ADDRESS/auth/REALM-NAME" \ 
    6
    
      oauth.client.id="kafka-broker" \ 
    7
    
      oauth.client.secret="kafka-broker-secret" \ 
    8
    
      oauth.refresh.token="REFRESH-TOKEN-FOR-KAFKA-BROKERS" \ 
    9
    
      oauth.access.token="ACCESS-TOKEN-FOR-KAFKA-BROKERS" ; 
    10
    
      oauth.connect.timeout.seconds=60 
    11
    
      oauth.read.timeout.seconds=60 
    12
    
      oauth.groups.claim="$.groups" 
    13
    
      oauth.groups.claim.delimiter="," 
    14
    Copy to Clipboard Toggle word wrap
    1
    到您的授权服务器的 OAuth 2.0 令牌端点 URL。对于生产环境,请始终使用 https:// urls。当使用 KeycloakRBACAuthorizer 或启用了 OAuth 2.0 的监听程序时,需要用于 Inter-broker 间通信。
    2
    (可选) 自定义声明检查。JsonPath 过滤器查询,用于在验证期间将其他自定义规则应用到 JWT 访问令牌。如果访问令牌不包含必要的数据,它将被拒绝。使用 introspection 端点方法时,自定义检查将应用到内省端点响应 JSON。
    3
    (可选)传递给令牌端点 的范围 参数。获取访问令牌进行代理身份验证时使用的 scope。它还在使用 clientIdsecret 的 PLAIN 客户端验证中用于 OAuth 2.0 的客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会影响监听器的令牌验证规则。
    4
    (可选)对象 检查。如果您的授权服务器提供 aud (audience)声明,并且希望强制进行受众检查,请将 ouath.check.audience 设置为 true。Audience 检查标识令牌的预期接收者。因此,Kafka 代理将拒绝在其 aud 声明中没有 clientId 的令牌。默认为 false
    5
    (可选)传递给令牌端点的 audience 参数。在获取用于代理身份验证的访问令牌时,需要使用 audience。它还在使用 clientIdsecret 的 PLAIN 客户端验证中用于 OAuth 2.0 的客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会影响监听器的令牌验证规则。
    6
    有效的签发者 URI。只有此签发者发布的访问令牌才会被接受。(始终需要。)
    7
    Kafka 代理配置的客户端 ID,适用于所有代理。这是在 授权服务器注册为 kafka-broker的客户端。当内省端点用于令牌验证时,或使用 KeycloakRBACAuthorizer 时是必需的。
    8
    Kafka 代理配置的 secret,适用于所有代理。当代理必须向授权服务器进行身份验证时,必须指定客户端 secret、访问令牌或刷新令牌。
    9
    (可选) Kafka 代理的长期刷新令牌。
    10
    (可选) Kafka 代理的长期访问令牌。
    11
    (可选)连接到授权服务器时的连接超时(以秒为单位)。默认值为 60。
    12
    (可选)连接到授权服务器时读取超时(以秒为单位)。默认值为 60。
    13
    JsonPath 查询,用于从 JWT 令牌或内省端点响应中提取组信息。默认不设置。这可供自定义授权器用于根据用户组做出授权决策。
    14
    当以单一分隔的字符串返回时,用于解析组信息的分隔符。默认值为 ','(comma)。
  5. 根据您如何应用 OAuth 2.0 身份验证以及所使用的授权服务器类型,添加额外的配置设置:

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      # ...
      oauth.check.issuer=false \ 
    1
    
      oauth.fallback.username.claim="CLIENT-ID" \ 
    2
    
      oauth.fallback.username.prefix="CLIENT-ACCOUNT" \ 
    3
    
      oauth.valid.token.type="bearer" \ 
    4
    
      oauth.userinfo.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/userinfo" ; 
    5
    Copy to Clipboard Toggle word wrap
    1
    如果您的授权服务器不提供 iss 声明,则无法执行签发者检查。在这种情况下,将 oauth.check.issuer 设置为 false,且不指定 oauth.valid.issuer.uri。默认为 true
    2
    授权服务器可能无法提供单个属性来识别常规用户和客户端。当客户端以自己的名称进行身份验证时,服务器可能会提供 客户端 ID。当用户使用用户名和密码进行身份验证时,若要获取刷新令牌或访问令牌,除了客户端 ID 外,服务器可能会提供一个 username 属性。如果主用户 ID 属性不可用,则使用这个 fallback 选项指定要使用的用户名声明(attribute)。
    3
    oauth.fallback.username.claim 适用的情况下,可能还需要防止用户名声明的值与回退用户名声明之间的名称冲突。请考虑存在名为 producer 的客户端存在的情况,但也存在名为 producer 的常规用户。为了区分这两者,您可以使用此属性向客户端的用户 ID 添加前缀。
    4
    (仅在使用 oauth.introspection.endpoint.uri)取决于您使用的授权服务器,内省端点可能会或不返回 令牌类型 属性,或者可以包含不同的值。您可以指定来自内省端点的响应必须包含有效的令牌类型值。
    5
    (仅在使用 oauth.introspection.endpoint.uri)时,可以配置或实施授权服务器,以便在内省端点响应中提供任何可识别的信息。要获取用户 ID,您可以将 userinfo 端点的 URI 配置为回退。oauth.fallback.username.claimoauth.fallback.username.claimoauth.fallback.username.prefix 设置应用到 userinfo 端点的响应。
4.10.6.3. 将 Kafka Java 客户端配置为使用 OAuth 2.0

这个步骤描述了如何配置 Kafka producer 和消费者 API,以使用 OAuth 2.0 与 Kafka 代理交互。

将客户端回调插件添加到 pom.xml 文件中,并配置系统属性。

先决条件

  • AMQ Streams 和 Kafka 正在运行
  • 部署和配置 OAuth 2.0 授权服务器以 OAuth 访问 Kafka 代理
  • 为 OAuth 2.0 配置 Kafka 代理

流程

  1. 将支持 OAuth 2.0 的客户端库添加到 Kafka 客户端的 pom.xml 文件中:

    <dependency>
     <groupId>io.strimzi</groupId>
     <artifactId>kafka-oauth-client</artifactId>
     <version>0.10.0.redhat-00002</version>
    </dependency>
    Copy to Clipboard Toggle word wrap
  2. 为回调配置系统属性:

    例如:

    System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 
    1
    
    System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client_name>"); 
    2
    
    System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client_secret>"); 
    3
    
    System.setProperty(ClientConfig.OAUTH_SCOPE, "<scope_value>") 
    4
    
    System.setProperty(ClientConfig.OAUTH_AUDIENCE, "<audience_value") 
    5
    Copy to Clipboard Toggle word wrap
    1
    授权服务器令牌端点的 URI。
    2
    客户端 ID,这是在授权服务器中创建客户端时使用的名称。
    3
    在授权服务器中创建客户端时创建的 客户端 secret。
    4
    (可选)从令牌端点请求令牌的范围。授权服务器可能需要客户端来指定范围。
    5
    (可选)从令牌端点请求令牌的听众。授权服务器可能需要客户端来指定受众。
  3. 在 Kafka 客户端配置中的 TLS 加密连接上启用 OAUTHBEARERPLAIN 机制。

    例如:

    为 Kafka 客户端启用 OAUTHBEARER

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
    props.put("security.protocol", "SASL_SSL");
    props.put("sasl.mechanism", "OAUTHBEARER");
    props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");
    Copy to Clipboard Toggle word wrap

    为 Kafka 客户端启用 PLAIN

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"$CLIENT_ID_OR_ACCOUNT_NAME\" password=\"$SECRET_OR_ACCESS_TOKEN\" ;");
    props.put("security.protocol", "SASL_SSL"); 
    1
    
    props.put("sasl.mechanism", "PLAIN");
    Copy to Clipboard Toggle word wrap

    1
    在这里,我们使用 SASL_SSL 进行 TLS 连接。仅对本地开发使用 SASL_PLAINTEXT
  4. 验证 Kafka 客户端是否可以访问 Kafka 代理。

4.11. 使用基于 OAuth 2.0 令牌的授权

如果您在 Red Hat Single Sign-On 中使用 OAuth 2.0 进行基于令牌的身份验证,您还可以使用 Red Hat Single Sign-On 来配置授权规则来限制客户端对 Kafka 代理的访问。身份验证建立用户的身份。授权决定该用户的访问权限级别。

AMQ Streams 支持通过 Red Hat Single Sign-On Authorization Services 使用基于 OAuth 2.0 令牌的授权,它允许您集中管理安全策略和权限。

Red Hat Single Sign-On 中定义的安全策略和权限用于授予对 Kafka 代理上资源的访问权限。用户和客户端与允许对 Kafka 代理执行特定操作的策略进行匹配。

Kafka 允许所有用户默认对代理进行完全访问,同时还提供 AclAuthorizer 插件来配置基于 Access Control Lists (ACL)的授权。

ZooKeeper 存储 ACL 规则,以根据 用户名 授予或拒绝对资源的访问。但是,红帽单点登录基于 OAuth 2.0 令牌的授权在您希望实现对 Kafka 代理的访问控制方面具有更大的灵活性。另外,您可以将 Kafka 代理配置为使用 OAuth 2.0 授权和 ACL。

4.11.1. OAuth 2.0 授权机制

AMQ Streams 中的 OAuth 2.0 授权使用红帽单点登录服务器授权服务 REST 端点,通过在特定用户上应用定义的安全策略来扩展基于令牌的身份验证,并为该用户提供授予不同资源的权限列表。策略使用角色和组来匹配用户的权限。OAuth 2.0 授权根据从 Red Hat Single Sign-On Authorization Services 用户获得的授予者列表在本地强制实施权限。

4.11.1.1. Kafka 代理自定义授权器

AMQ Streams 提供了 Red Hat Single Sign-On authorizer (KeycloakRBACAuthorizer)。为了可以使用 Red Hat Single Sign-On 提供的授权服务的 Red Hat Single Sign-On REST 端点,您可以在 Kafka 代理上配置自定义授权器。

授权程序根据需要从授权服务器获取授予权限的列表,并在 Kafka Broker 上本地强制实施授权,为每个客户端请求做出快速授权决策。

4.11.2. 配置 OAuth 2.0 授权支持

这个步骤描述了如何使用 Red Hat Single Sign-On Authorization Services 将 Kafka 代理配置为使用 OAuth 2.0 授权服务。

开始前

考虑某些用户所需的访问权限或希望限制某些用户。您可以使用 Red Hat Single Sign-On 角色客户端用户在 Red Hat Single Sign-On 中配置访问权限的组合。

通常,组用于根据机构部门或地理位置匹配用户。和 角色用于根据其功能匹配用户。

使用红帽单点登录,您可以在 LDAP 中存储用户和组,而客户端和角色不能以这种方式存储。存储和对用户数据的访问可能是您选择配置授权策略的一个因素。

注意

无论在 Kafka 代理上实现的授权是什么,超级用户始终对 Kafka 代理具有不受限制的访问。

先决条件

  • AMQ Streams 必须通过 Red Hat Single Sign-On 配置为使用 OAuth 2.0 进行基于令牌的身份验证。设置授权时,您可以使用相同的 Red Hat Single Sign-On 服务器端点。
  • 您需要了解如何管理 Red Hat Single Sign-On Authorization Services 的策略和权限,如 Red Hat Single Sign-On 文档所述

流程

  1. 访问 Red Hat Single Sign-On Admin 控制台,或使用 Red Hat Single Sign-On Admin CLI 为设置 OAuth 2.0 身份验证时创建的 Kafka 代理客户端启用授权服务。
  2. 使用 Authorization Services 为客户端定义资源、授权范围、策略和权限。
  3. 通过分配角色和组,将权限绑定到用户和客户端。
  4. 将 Kafka 代理配置为使用 Red Hat Single Sign-On 授权。

    将以下内容添加到 Kafka server.properties 配置文件中,以在 Kafka 中安装授权器:

    authorizer.class.name=io.strimzi.kafka.oauth.server.authorizer.KeycloakRBACAuthorizer
    principal.builder.class=io.strimzi.kafka.oauth.server.authorizer.JwtKafkaPrincipalBuilder
    Copy to Clipboard Toggle word wrap
  5. 为 Kafka 代理添加配置以访问授权服务器和授权服务。

    在此我们显示作为额外属性添加到 server.properties 的示例配置,但您也可以使用大写或大写的命名规则将它们定义为环境变量。

    strimzi.authorization.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token" 
    1
    
    strimzi.authorization.client.id="kafka" 
    2
    Copy to Clipboard Toggle word wrap
    1
    到 Red Hat Single Sign-On 的 OAuth 2.0 令牌端点 URL。对于生产环境,请始终使用 https:// urls。
    2
    在启用了授权服务的 Red Hat Single Sign-On 中 OAuth 2.0 客户端定义的客户端 ID。通常,kafka 被用作 ID。
  6. (可选)为特定 Kafka 集群添加配置。

    例如:

    strimzi.authorization.kafka.cluster.name="kafka-cluster" 
    1
    Copy to Clipboard Toggle word wrap
    1
    特定 Kafka 集群的名称。名称用于目标权限,因此可以在同一 Red Hat Single Sign-On 域中管理多个集群。默认值为 kafka-cluster
  7. (可选)与简单授权决定。

    例如:

    strimzi.authorization.delegate.to.kafka.acl="false" 
    1
    Copy to Clipboard Toggle word wrap
    1
    如果 Red Hat Single Sign-On Authorization Services 策略无法访问,将授权委派给 Kafka AclAuthorizer。默认值为 false
  8. (可选)将 TLS 连接的配置添加到授权服务器。

    例如:

    strimzi.authorization.ssl.truststore.location=<path-to-truststore> 
    1
    
    strimzi.authorization.ssl.truststore.password=<my-truststore-password> 
    2
    
    strimzi.authorization.ssl.truststore.type=JKS 
    3
    
    strimzi.authorization.ssl.secure.random.implementation=SHA1PRNG 
    4
    
    strimzi.authorization.ssl.endpoint.identification.algorithm=HTTPS 
    5
    Copy to Clipboard Toggle word wrap
    1
    包含证书的信任存储的路径。
    2
    truststore 的密码。
    3
    truststore 类型。如果没有设置,则使用默认的 Java 密钥存储类型。
    4
    随机数生成器实施。如果没有设置,则使用 Java platform SDK 默认。
    5
    主机名验证。如果设置为空字符串,则会关闭主机名验证。如果没有设置,则默认值为 HTTPS,它会强制对服务器证书进行主机名验证。
  9. (可选)配置从授权服务器刷新授权。授予刷新作业的工作原理,方法是枚举活跃的令牌并请求每个令牌的最新授权。

    例如:

    strimzi.authorization.grants.refresh.period.seconds="120" 
    1
    
    strimzi.authorization.grants.refresh.pool.size="10" 
    2
    Copy to Clipboard Toggle word wrap
    1
    指定授权服务器的授予的频率(默认为每分钟一次)。要关闭刷新以进行调试,请将 设置为 "0"
    2
    指定授予刷新作业使用的线程池大小(并行级别)。默认值为 "5"
  10. 通过以客户端或具有特定角色的用户访问 Kafka 代理来验证配置的权限,确保它们具有必要的访问权限,或者没有应该具有访问权限。

4.12. 使用基于 OPA 策略的授权

开源策略代理(OPA)是一个开源策略引擎。您可以将 OPA 与 AMQ Streams 集成,作为基于策略的授权机制,允许在 Kafka 代理上进行客户端操作。

从客户端发出请求时,OPA 将根据为 Kafka 访问定义的策略评估请求,然后允许或拒绝请求。

注意

红帽不支持 OPA 服务器。

4.12.1. 定义 OPA 策略

在将 OPA 与 AMQ Streams 集成前,请考虑如何定义策略以提供精细的访问控制。

您可以为 Kafka 集群、消费者组和主题定义访问控制。例如,您可以定义一个授权策略,允许从制作者客户端写入到特定代理主题的访问。

为此,策略可能会指定:

  • 与制作者客户端关联的用户主体主机地址
  • 客户端允许的操作
  • 策略适用的 资源类型 (topic)和资源名称

允许或拒绝决策将写入到策略中,并根据提供的请求和客户端识别数据提供响应。

在我们的示例中,生成者客户端必须满足策略才能写入该主题。

4.12.2. 连接到 OPA

要启用 Kafka 访问 OPA 策略引擎以查询访问控制策略,您可以在您的 Kafka server.properties 文件中配置自定义 OPA authorizer 插件 (kafka-authorizer-opa-VERSION.jar)。

客户端发出请求时,OPA 策略引擎将通过指定的 URL 地址和 REST 端点来查询 OPA 策略引擎,该端点必须是定义的策略的名称。

该插件提供了客户端请求的详细信息 - 用户主体、操作和资源 - 以 JSON 格式针对策略进行检查。详细信息将包括客户端的唯一身份;例如,使用 TLS 身份验证时将区分名称与客户端证书进行区分。

OPA 使用数据向插件提供响应 - truefalse - 允许或拒绝请求。

4.12.3. 配置 OPA 授权支持

这个步骤描述了如何将 Kafka 代理配置为使用 OPA 授权。

开始前

考虑某些用户所需的访问权限或希望限制某些用户。您可以使用 用户和 Kafka 资源 的组合来定义 OPA 策略。

可以设置 OPA 从 LDAP 数据源加载用户信息。

注意

无论在 Kafka 代理上实现的授权是什么,超级用户始终对 Kafka 代理具有不受限制的访问。

先决条件

流程

  1. 编写授权客户端请求对 Kafka 代理执行操作所需的 OPA 策略。

    请参阅 定义 OPA 策略

    现在,将 Kafka 代理配置为使用 OPA。

  2. 为 Kafka 安装 OPA 授权器插件

    请参阅 连接到 OPA

    确保插件文件包含在 Kafka 类路径中。

  3. 在 Kafka server.properties 配置文件中添加以下内容以启用 OPA 插件:

    authorizer.class.name: com.bisnode.kafka.authorization.OpaAuthorizer
    Copy to Clipboard Toggle word wrap
  4. 在 Kafka 代理的 server.properties 中添加其他配置来访问 OPA 策略引擎和策略。

    例如:

    opa.authorizer.url=https://OPA-ADDRESS/allow 
    1
    
    opa.authorizer.allow.on.error=false 
    2
    
    opa.authorizer.cache.initial.capacity=50000 
    3
    
    opa.authorizer.cache.maximum.size=50000 
    4
    
    opa.authorizer.cache.expire.after.seconds=600000 
    5
    
    super.users=User:alice;User:bob 
    6
    Copy to Clipboard Toggle word wrap
    1
    (必需)授权器插件将查询的策略的 OAuth 2.0 令牌端点 URL。在本例中,策略称为 allow
    2
    标志指定在授权器插件无法与 OPA 策略引擎连接时,默认是否允许或拒绝客户端访问。
    3
    本地缓存的初始容量(以字节为单位)。使用缓存,以便插件不必查询每个请求的 OPA 策略引擎。
    4
    本地缓存的最大容量(以字节为单位)。
    5
    本地缓存的时间(以毫秒为单位),方法是从 OPA 策略引擎重新加载。
    6
    被视为超级用户的用户主体列表,以便在不查询 Open Policy Agent 策略的情况下始终允许它们。

    有关身份验证和授权选项的信息,请参阅 Open Policy Agent 网站

  5. 通过使用具有正确授权的客户端访问 Kafka 代理来验证配置的权限。

4.13. 日志记录

Kafka 代理使用 Log4j 作为其日志记录基础架构。默认情况下,日志记录配置从 log4j.properties 配置文件读取,该文件应放在 /opt/kafka/config/ 目录中,或 classpath。可以使用 Java 属性 log4j.configuration 更改配置文件的位置和名称,可使用 KAFKA_LOG4J_OPTS 环境变量传递给 Kafka:

su - kafka
export KAFKA_LOG4J_OPTS="-Dlog4j.configuration=file:/my/path/to/log4j.config"; /opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties
Copy to Clipboard Toggle word wrap

有关 Log4j 配置的更多信息,请参阅 Log4j 手册

Kafka 代理日志记录由每个代理中的多个 broker loggers 提供。您可以动态更改代理日志记录器的日志记录级别,而无需重启代理。增加日志返回的详细级别 - 从 INFO 变为 DEBUG,例如:在 Kafka 集群中调查性能问题时很有用。

代理日志记录器也可以动态重置为其默认日志记录级别。

流程

  1. 切换到 kafka 用户:

    su - kafka
    Copy to Clipboard Toggle word wrap
  2. 使用 kafka-configs.sh 工具列出代理的所有代理日志记录器:

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server BOOTSTRAP-ADDRESS --describe --entity-type broker-loggers --entity-name BROKER-ID
    Copy to Clipboard Toggle word wrap

    例如,对于代理 0

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type broker-loggers --entity-name 0
    Copy to Clipboard Toggle word wrap

    这会返回每个日志记录器的日志记录级别:TRACE, DEBUG, INFO, WARN, ERROR, 或 FATAL。例如:

    #...
    kafka.controller.ControllerChannelManager=INFO sensitive=false synonyms={}
    kafka.log.TimeIndex=INFO sensitive=false synonyms={}
    Copy to Clipboard Toggle word wrap
  3. 更改一个或多个代理日志记录器的日志级别。使用 --alter--add-config 选项,并使用双引号将每个日志记录器及其级别指定为逗号分隔的列表。

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server BOOTSTRAP-ADDRESS --alter --add-config "LOGGER-ONE=NEW-LEVEL,LOGGER-TWO=NEW-LEVEL" --entity-type broker-loggers --entity-name BROKER-ID
    Copy to Clipboard Toggle word wrap

    例如,对于代理 0

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config "kafka.controller.ControllerChannelManager=WARN,kafka.log.TimeIndex=WARN" --entity-type broker-loggers --entity-name 0
    Copy to Clipboard Toggle word wrap

    如果成功,则返回:

    Completed updating config for broker: 0.
    Copy to Clipboard Toggle word wrap
重置代理日志记录器

您可以使用 kafka-configs.sh 工具将一个或多个代理日志记录器重置为其默认日志记录级别。使用 --alter--delete-config 选项,并使用双引号将每个代理日志记录器指定为用逗号分开的列表:

/opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config "LOGGER-ONE,LOGGER-TWO" --entity-type broker-loggers --entity-name BROKER-ID
Copy to Clipboard Toggle word wrap

其他资源

  • Apache Kafka 文档中的 更新 代理配置。

第 5 章 topics

Kafka 中的消息始终从主题发送到或接收。本章论述了如何配置和管理 Kafka 主题。

5.1. 分区和副本

Kafka 中的消息始终从主题发送到或接收。主题始终被分成一个或多个分区。分区充当分片。这意味着,由制作者发送的每个消息始终仅写入单个分区。由于消息分片到不同的分区,主题很容易水平扩展。

每个分区都可以有一个或多个副本,它们存储在集群中的不同代理中。在创建主题时,您可以使用 复制因素 配置副本数。复制因子 定义在集群中保留的副本数。给定分区的一个副本将被选为领导。领导副本由生产者用于发送新消息并供消费者使用消息。其他副本将遵循副本。后续者复制领导。

如果领导失败,则后续者之一将自动成为新的领导。每个服务器充当其部分分区的领导者,对其他分区的遵循,因此负载在群集内取得良好平衡。

注意

复制因素决定了副本数量,包括领导机和后续程序。例如,如果您将复制项设置为 3,那么将有一个领导和两个后续副本。

5.2. 消息保留

消息保留策略定义信息存储在 Kafka 代理中的时长。它可以根据时间、分区大小或两者定义。

例如,您可以定义消息应该保留:

  • 7 天
  • 直到有 1GB 的消息。达到限制后,将删除最旧的消息。
  • 7 天或直至达到 1GB 限制。首先将使用任何限制。
警告

Kafka 代理将信息存储在日志片段中。只有在创建新日志片段时,才会删除其保留策略的消息。当以前的日志片段超过配置的日志片段大小时,会创建新的日志片段。此外,用户可以请求定期创建新的片段。

另外,Kafka 代理支持紧凑策略。

对于带有紧凑策略的主题,代理总是只保留每个键的最后一条消息。具有相同密钥的旧消息将从分区中删除。因为 compact 是一个定期执行的操作,所以当具有相同键的新消息发送到分区时不会立即发生。相反,可能需要稍等片刻,直到旧的消息被删除为止。

有关消息保留配置选项的更多信息,请参阅 第 5.5 节 “主题配置”

5.3. Topic 自动创建

当制作者或消费者尝试向不存在的主题发送信息或接收信息时,Kafka 默认会自动创建该主题。这个行为由 auto.create.topics.enable 配置属性控制,该配置属性默认设置为 true

要禁用它,在 Kafka 代理配置文件中将 auto.create.topics.enable 设置为 false

auto.create.topics.enable=false
Copy to Clipboard Toggle word wrap

5.4. 主题删除

Kafka 提供了禁用删除主题的可能性。这通过 delete.topic.enable 属性进行配置,该属性默认设置为 true (即删除主题是可能的)。当此属性设置为 false 时,将无法删除主题,所有尝试删除主题都将返回成功,但主题不会被删除。

delete.topic.enable=false
Copy to Clipboard Toggle word wrap

5.5. 主题配置

自动创建的主题将使用默认主题配置,可在代理属性文件中指定。但是,在手动创建主题时,可以在创建时指定其配置。也可以在创建主题后更改主题配置。手动创建主题的主要主题配置选项有:

cleanup.policy
将保留策略配置为 deletecompact删除策略 将删除旧记录。紧凑 策略将启用日志压缩。默认值为 delete。有关日志压缩的更多信息,请参阅 Kafka 网站
compression.type
指定用于存储消息的压缩。有效值为 gzipsnappylz4、 未压缩 (无压缩)和 生成者 (包含生产者使用的压缩代码)。默认值为 producer
max.message.bytes
Kafka 代理允许的最大消息大小,以字节为单位。默认值为 1000012
min.insync.replicas
要被视为成功,必须同步的最小副本数才被视为成功。默认值为:1
retention.ms
保留日志片段的最大毫秒数。早于这个值的日志片段将被删除。默认值为 604800000 (7 天)。
retention.bytes
分区将保留的最大字节数。当分区大小超过这个限制后,将删除最旧的日志片段。-1 表示没有限制。默认值为 -1
segment.bytes
单个提交日志段文件的最大文件大小(以字节为单位)。当片段达到其大小时,将启动新的网段。默认值为 1073741824 字节 (1 gibibyte)。

有关所有支持的主题配置选项的列表,请参阅 附录 B, 主题配置参数

自动创建主题的默认值可使用类似选项在 Kafka 代理配置中指定:

log.cleanup.policy
请参阅上面的 cleanup.policy
compression.type
请参阅上述 compression.type
message.max.bytes
请参阅上面的 max.message.bytes
min.insync.replicas
请参阅上面的 min.insync.replicas
log.retention.ms
请参阅上面的 retention.ms
log.retention.bytes
请参阅上面的 retention.bytes
log.segment.bytes
请参阅上面的 segment.bytes
default.replication.factor
自动创建的主题的默认复制因素。默认值为 1
num.partitions
自动创建主题的默认分区数。默认值为 1

有关所有支持的 Kafka 代理配置选项列表,请参阅 附录 A, 代理配置参数

5.6. 内部主题

内部主题由 Kafka 代理和客户端在内部创建和使用。Kafka 有几个内部主题。它们用于存储消费者偏移量(__consumer_offsets)或事务状态(__transaction_state)。这些主题可使用以前缀 offsets.topic.transaction.state.log. 开头的专用 Kafka 代理配置选项来配置。最重要的配置选项有:

offsets.topic.replication.factor
__consumer_offsets 主题的副本数。默认值为 3
offsets.topic.num.partitions
__consumer_offsets 主题的分区数。默认值为 50
transaction.state.log.replication.factor
__transaction_state 主题的副本数。默认值为 3
transaction.state.log.num.partitions
__transaction_state 主题的分区数。默认值为 50
transaction.state.log.min.isr
必须确认对 __transaction_state 主题的写入的最小副本数才被视为成功。如果无法满足此最小值,则生成者将失败,但会异常。默认值为 2

5.7. 创建主题

kafka-topics.sh 工具可用于管理主题。kafka-topics.sh 是 AMQ Streams 发布的一部分,可在 bin 目录中找到。

先决条件

  • AMQ Streams 集群已安装并运行

创建主题

  1. 使用 kafka-topics.sh 实用程序创建主题并指定以下内容:

    • --bootstrap-server 选项中的 Kafka 代理的主机和端口。
    • 要在 --create 选项中创建的新主题。
    • --topic 选项中的主题名称。
    • --partitions 选项中的分区数量。
    • --replication-factor 选项中的主题复制因素。

      您还可以使用 --config 选项覆盖一些默认主题配置选项。这个选项可多次使用来覆盖不同的选项。

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --create --topic <TopicName> --partitions <NumberOfPartitions> --replication-factor <ReplicationFactor> --config <Option1>=<Value1> --config <Option2>=<Value2>
      Copy to Clipboard Toggle word wrap

      创建名为 mytopic的主题的命令示例

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic mytopic --partitions 50 --replication-factor 3 --config cleanup.policy=compact --config min.insync.replicas=2
      Copy to Clipboard Toggle word wrap

  2. 验证主题是否使用 kafka-topics.sh 是否存在。

    bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --describe --topic <TopicName>
    Copy to Clipboard Toggle word wrap

    描述名为 mytopic的主题的命令示例

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic mytopic
    Copy to Clipboard Toggle word wrap

其他资源

5.8. 列出和描述主题

kafka-topics.sh 工具可用于列出和描述主题。kafka-topics.sh 是 AMQ Streams 发布的一部分,可在 bin 目录中找到。

先决条件

  • AMQ Streams 集群已安装并运行
  • 存在主题 mytopic

描述主题

  1. 使用 kafka-topics.sh 工具描述主题并指定以下内容:

    • --bootstrap-server 选项中的 Kafka 代理的主机和端口。
    • 使用 --describe 选项指定您要描述主题。
    • 主题名称必须在 --topic 选项中指定。
    • 当省略 --topic 选项时,它将描述所有可用的主题。

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --describe --topic <TopicName>
      Copy to Clipboard Toggle word wrap

      描述名为 mytopic的主题的命令示例

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic mytopic
      Copy to Clipboard Toggle word wrap

      describe 命令将列出所有属于此主题的分区和副本。它还将列出所有主题配置选项。

其他资源

5.9. 修改主题配置

kafka-configs.sh 工具可用于修改主题配置。kafka-configs.sh 是 AMQ Streams 发行版本的一部分,可在 bin 目录中找到。

先决条件

  • AMQ Streams 集群已安装并运行
  • 存在主题 mytopic

修改主题配置

  1. 使用 kafka-configs.sh 工具获取当前的配置。

    • --bootstrap-server 选项中指定 Kafka 代理的主机和端口。
    • --entity-type 设置为 topic,将 --entity-name 设置为主题的名称。
    • 使用 --describe 选项获取当前的配置。

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --describe
      Copy to Clipboard Toggle word wrap

      获取名为 mytopic的主题配置的命令示例

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --describe
      Copy to Clipboard Toggle word wrap

  2. 使用 kafka-configs.sh 工具更改配置。

    • --bootstrap-server 选项中指定 Kafka 代理的主机和端口。
    • --entity-type 设置为 topic,将 --entity-name 设置为主题的名称。
    • 使用 --alter 选项修改当前配置。
    • 在选项 --add-config 中指定您要添加或更改的选项。

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --alter --add-config <Option>=<Value>
      Copy to Clipboard Toggle word wrap

      更改名为 mytopic的主题配置的命令示例

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --alter --add-config min.insync.replicas=1
      Copy to Clipboard Toggle word wrap

  3. 使用 kafka-configs.sh 工具删除现有配置选项。

    • --bootstrap-server 选项中指定 Kafka 代理的主机和端口。
    • --entity-type 设置为 topic,将 --entity-name 设置为主题的名称。
    • 使用 --delete-config 选项删除现有配置选项。
    • 在选项 --remove-config 中指定您要删除的选项。

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --alter --delete-config <Option>
      Copy to Clipboard Toggle word wrap

      更改名为 mytopic的主题配置的命令示例

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --alter --delete-config min.insync.replicas
      Copy to Clipboard Toggle word wrap

其他资源

5.10. 删除主题

kafka-topics.sh 工具可用于管理主题。kafka-topics.sh 是 AMQ Streams 发布的一部分,可在 bin 目录中找到。

先决条件

  • AMQ Streams 集群已安装并运行
  • 存在主题 mytopic

删除主题

  1. 使用 kafka-topics.sh 工具删除主题。

    • --bootstrap-server 选项中的 Kafka 代理的主机和端口。
    • 使用 --delete 选项指定应删除现有主题。
    • 主题名称必须在 --topic 选项中指定。

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --delete --topic <TopicName>
      Copy to Clipboard Toggle word wrap

      创建名为 mytopic的主题的命令示例

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic mytopic
      Copy to Clipboard Toggle word wrap

  2. 使用 kafka-topics.sh 验证主题是否已删除。

    bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --list
    Copy to Clipboard Toggle word wrap

    列出所有主题的命令示例

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --list
    Copy to Clipboard Toggle word wrap

其他资源

第 6 章 管理 Kafka

使用额外的配置属性来维护 AMQ Streams 的部署。您可以添加和调整设置,以响应 AMQ Streams 的性能。例如,您可以引入其他配置以提高吞吐量和数据可靠性。

6.1. 调整 Kafka 配置

使用配置属性来优化 Kafka 代理、生产者和消费者的性能。

需要一组最小配置属性,但您可以添加或调整属性,以更改制作者和消费者与 Kafka 代理交互的方式。例如,您可以调整消息的延迟和吞吐量,以便客户端可以实时响应数据。

您可能首先分析指标以量化进行初始配置的位置,然后进行增量更改,并进一步比较指标,直到您有所需的配置。

有关 Apache Kafka 配置属性的更多信息,请参阅 Apache Kafka 文档

6.1.1. Kafka 代理配置调整

使用配置属性来优化 Kafka 代理的性能。您可以使用标准 Kafka 代理配置选项,但由 AMQ Streams 直接管理的属性除外。

6.1.1.1. 基本代理配置

基本配置将包含以下属性来识别您的代理并提供安全访问:

  • broker.id 是 Kafka 代理的 ID
  • log.dirs 是日志数据的目录
  • zookeeper.connect 是 Kafka 与 ZooKeeper 连接的配置
  • 侦听器 将 Kafka 集群公开给客户端
  • 授权机制 允许或拒绝用户执行的操作
  • 身份验证机制 证明了需要访问 Kafka 的用户的身份

有关配置 Kafka 中基本配置选项的详情,。

典型的代理配置还包括与主题、线程和日志相关的属性的设置。

基本代理配置属性

# ...
num.partitions=1
default.replication.factor=3
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
num.network.threads=3
num.io.threads=8
num.recovery.threads.per.data.dir=1
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
group.initial.rebalance.delay.ms=0
zookeeper.connection.timeout.ms=6000
# ...
Copy to Clipboard Toggle word wrap

6.1.1.2. 复制主题以实现高可用性

基本主题属性为主题设置默认分区数和复制因素,这些主题将应用于没有显式设置这些属性创建的主题,包括何时自动创建主题。

# ...
num.partitions=1
auto.create.topics.enable=false
default.replication.factor=3
min.insync.replicas=2
replica.fetch.max.bytes=1048576
# ...
Copy to Clipboard Toggle word wrap

auto.create.topics.enable 属性默认为启用,以便在生产者和消费者需要时自动创建不存在的主题。如果使用自动主题创建,您可以使用 num.partitions 为主题设置默认分区数量。通常,此属性被禁用,以便在创建主题时提供更多的控制

对于高可用性环境,建议将复制因素增加到至少 3 个用于主题,并将最小 in-sync 副本数量设置为复制因素小 1。

对于 数据持久性,您还应在主题配置中设置 min.insync.replicas,并在生成者配置中使用 acks=all 进行消息交付确认。

使用 replica.fetch.max.bytes 设置复制领导分区的每个后续程序获取的最大大小(以字节为单位)。根据平均消息大小和吞吐量更改这个值。在考虑读/写缓冲区所需的总内存分配时,可用内存也必须能适应所有后续者的最大复制消息大小。大小还必须大于 message.max.bytes,以便复制所有消息。

delete.topic.enable 属性默认为启用,以允许删除主题。在生产环境中,您应该禁用此属性以避免意外删除主题,从而导致数据丢失。但是,您可以临时启用它并删除主题,然后再次禁用它。

# ...
auto.create.topics.enable=false
delete.topic.enable=true
# ...
Copy to Clipboard Toggle word wrap
6.1.1.3. 事务和提交的内部主题设置

如果您使用事务 启用对生成者中的分区的原子写入,则事务的状态存储在内部 __transaction_state 主题。默认情况下,代理配置有 3 个复制因素,以及此主题的最小同步副本,这意味着 Kafka 集群中最少需要三个代理。

# ...
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
# ...
Copy to Clipboard Toggle word wrap

同样,存储消费者状态的内部 __consumer_offsets 主题具有分区和复制因素的数量的默认设置。

# ...
offsets.topic.num.partitions=50
offsets.topic.replication.factor=3
# ...
Copy to Clipboard Toggle word wrap

不要在生产环境中减少这些设置。生产环境中,您可以提高设置。作为例外,您可能需要减少单代理 测试环境中的设置

网络线程处理对 Kafka 集群的请求,如从客户端应用程序生成和获取请求。生成请求将置于请求队列中。响应放置在响应队列中。

网络线程数量应该反映了复制因者和与 Kafka 集群交互的用户的活动级别。如果您要拥有大量请求,您可以使用闲置时间线程数量来增加线程数量,以确定何时添加更多线程。

要减少拥塞并规范请求流量,您可以在网络线程被阻止前限制请求队列中允许的请求数。

I/O 线程从请求队列获取请求来处理它们。添加更多线程可以提高吞吐量,但 CPU 内核和磁盘带宽的数量会实施实际的上限。至少,I/O 线程的数量应等于存储卷的数量。

# ...
num.network.threads=3 
1

queued.max.requests=500 
2

num.io.threads=8 
3

num.recovery.threads.per.data.dir=1 
4

# ...
Copy to Clipboard Toggle word wrap
1
Kafka 集群的网络线程数量。
2
请求队列中允许的请求数。
3
Kafka 代理的 I/O 线程数量。
4
在启动时用于日志载入的线程数量,并在关闭时清除。

所有代理的线程池的配置更新可能会在集群级别动态发生。这些更新仅限于当前大小的一半和两倍的当前大小。

注意

Kafka 代理指标可帮助处理所需的线程数量。例如,平均时间网络线程的指标是空闲的(kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent)表示使用的资源百分比。如果有 0% 空闲时间,则使用所有资源,这意味着添加更多线程可能很有用。

如果线程因为磁盘数量而较慢或限制,您可以尝试增加网络请求的缓冲区的大小,以提高吞吐量:

# ...
replica.socket.receive.buffer.bytes=65536
# ...
Copy to Clipboard Toggle word wrap

另外,增加 Kafka 可以接收的最大字节数:

# ...
socket.request.max.bytes=104857600
# ...
Copy to Clipboard Toggle word wrap
6.1.1.5. 为高延迟连接增加带宽

Kafka 批处理数据,以便在从 Kafka 到客户端(如数据中心之间的连接)上实现合理的吞吐量。但是,如果高延迟问题,您可以增加缓冲区的大小来发送和接收信息。

# ...
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
# ...
Copy to Clipboard Toggle word wrap

您可以使用 bandwidth-delay 产品 计算来估算缓冲区的最佳大小,这会乘以带往返延迟(以秒为单位)链路的最大带宽(以秒为单位)以达到最大吞吐量。

6.1.1.6. 使用数据保留策略管理日志

Kafka 使用日志来存储消息数据。日志是与各种索引关联的一系列片段。新消息被写入 active 片段,之后永远不会修改。当服务从消费者获取请求时,可读取片段。有时候,活跃段会滚动到变为只读,一个新的活跃段会被创建来替代它。一次只有一个段处于活跃状态。保留旧的片段,直到它们有资格删除。

在代理级别配置设置日志片段的最大大小(以字节为单位),以及活跃的片段前的时间(毫秒):

# ...
log.segment.bytes=1073741824
log.roll.ms=604800000
# ...
Copy to Clipboard Toggle word wrap

您可以使用 segment.bytessegment.ms 在主题级别上覆盖这些设置。您需要降低或提升这些值,这取决于删除网段的策略。较大的大小表示活跃片段包含更多信息,且会更频繁地推出。段也有资格减少删除。

您可以设置基于时间的日志保留和清理策略,以便可以保持管理的日志。根据您的要求,您可以使用日志保留配置删除旧的片段。如果使用日志保留策略,则在达到保留限制时会删除非活跃日志片段。删除旧的片段绑定了日志所需的存储空间,因此您不会超过磁盘容量。

对于基于时间的日志保留,您可以根据小时、分钟和毫秒设置保留周期。保留周期基于消息附加到段中的时间。

毫秒配置的优先级超过分钟,其优先级高于小时。默认情况下,minutes 和 milliseconds 配置是 null,但三个选项提供了对您要保留的数据进行大量控制。首选项应提供给毫秒配置,因为它是唯一可以动态更新的三个属性之一。

# ...
log.retention.ms=1680000
# ...
Copy to Clipboard Toggle word wrap

如果 log.retention.ms 设置为 -1,则不会将时间限制应用到日志保留,因此所有日志都会被保留。磁盘用量应始终被监控,但通常不建议使用 -1 设置,因为它可能会导致完整磁盘出现问题,这可能会难以重新显示。

对于基于大小的日志保留,您可以以字节为单位设置最大日志大小(日志中所有片段):

# ...
log.retention.bytes=1073741824
# ...
Copy to Clipboard Toggle word wrap

换句话说,日志通常会在达到稳定状态后具有大约 log.retention.bytes/log.segment.bytes 片段。当达到最大日志大小时,会删除旧的片段。

使用最大日志大小的潜在问题是,它不会考虑时间信息被附加到段中。您可以对清理策略使用基于时间和大小的日志保留,以获得您需要的平衡。首先达到哪个阈值会触发清理。

如果要在从系统中删除段文件前添加时间延迟,您可以使用 log.segment.delete.delay.ms 用于代理级别或 file.delete.delay.ms 中特定主题。

# ...
log.segment.delete.delay.ms=60000
# ...
Copy to Clipboard Toggle word wrap
6.1.1.7. 使用清理策略删除日志数据

删除旧的日志数据的方法由日志 清理 配置决定。

默认情况下,代理启用了 log cleaner:

# ...
log.cleaner.enable=true
# ...
Copy to Clipboard Toggle word wrap

您可以在主题或代理级别设置清理策略。代理级配置是没有设置策略的主题的默认设置。

您可以设置策略来删除日志、压缩日志或同时执行这两者:

# ...
log.cleanup.policy=compact,delete
# ...
Copy to Clipboard Toggle word wrap

delete 策略与使用数据保留策略管理日志对应。当不需要永久保留数据时,它非常适合。紧凑 策略保证为每个消息键保留最新的消息。日志压缩适用于消息值可更改的位置,您希望保留最新的更新。

如果将清理策略设置为删除日志,则根据日志保留限制删除旧的片段。否则,如果没有启用日志清理程序,且没有日志保留限制,日志将继续增长。

如果为日志压缩设置了清理策略,则日志 作为标准 Kafka 日志运行,并按顺序写入附加新消息。在紧凑的日志的 尾部,日志清理程序运行,如果日志中稍后发生具有相同键的另一个记录,将删除记录。具有 null 值的消息也会被删除。如果没有使用密钥,则无法使用压缩,因为需要密钥来识别相关消息。虽然 Kafka 保证保留每个密钥的最新信息,但它不能保证整个压缩的日志不会包含重复。

图 6.1. 在压缩前显示带有偏移位置的键值写入的日志

使用键识别信息,Kafka 压缩会为特定消息键保留最新的消息(具有最高偏移),最终丢弃具有相同键的早期消息。换句话说,其最新状态的消息始终可用,当日志清理程序运行时,该特定消息的任何过时的记录都会最终被删除。您可以将消息恢复到以前的状态。

即使周围记录被删除,记录也会保留其原始偏移量。因此,tail 可以具有非连续偏移。当消耗在 tail 中可用偏移时,会发现带有下一个偏移的记录。

图 6.2. 压缩后日志

如果您只选择紧凑策略,您的日志仍然可以变为任意的。在这种情况下,您可以将策略设置为紧凑删除日志。如果您选择紧凑和删除,首先压缩日志数据,在日志头中使用键删除记录。之后,在日志保留阈值被删除前的数据。

图 6.3. 日志保留点和压缩点

您可以设置检查日志进行清理的频率(以毫秒为单位):

# ...
log.retention.check.interval.ms=300000
# ...
Copy to Clipboard Toggle word wrap

调整与日志保留设置相关的日志保留检查间隔。较小的保留大小可能需要更频繁地检查。

清理的频率通常足以管理磁盘空间,但通常不会影响主题的性能。

如果没有要清理的日志,您还可以设置时间(以毫秒为单位),以将清理器放在待机中:

# ...
log.cleaner.backoff.ms=15000
# ...
Copy to Clipboard Toggle word wrap

如果您选择删除旧的日志数据,您可以在清除前设置句点来保留已删除的数据:

# ...
log.cleaner.delete.retention.ms=86400000
# ...
Copy to Clipboard Toggle word wrap

删除的数据保留周期提供了在数据被不可避免删除前注意到数据的时间。

要删除与特定密钥相关的所有消息,制作者可以发送 tombstone 消息。tombstone 有一个 null 值,并作为标记来代表消费者删除该值。在压缩后,只保留 tombstone,它必须足够长的时间才能知道该消息已被删除。删除旧的消息时,没有值,tombstone 键也会从分区中删除。

6.1.1.8. 管理磁盘使用率

还有其他与日志清理相关的配置设置,但特别的重要性是内存分配。

deduplication 属性指定在所有日志清理线程中清理的总内存。您可以设置通过缓冲区负载因子使用的内存百分比的上限。

# ...
log.cleaner.dedupe.buffer.size=134217728
log.cleaner.io.buffer.load.factor=0.9
# ...
Copy to Clipboard Toggle word wrap

每个日志条目都使用 24 字节,以便您可以处理缓冲区可以在单一运行中处理多少个日志条目,并相应地调整设置。

如果要减少日志清理时间,请考虑增加日志清理线程数量:

# ...
log.cleaner.threads=8
# ...
Copy to Clipboard Toggle word wrap

如果您遇到 100% 磁盘带宽使用情况的问题,您可以节流日志清理 I/O,以便读/写操作的总和小于执行操作的磁盘功能的指定双值:

# ...
log.cleaner.io.max.bytes.per.second=1.7976931348623157E308
# ...
Copy to Clipboard Toggle word wrap
6.1.1.9. 处理大量消息大小

消息的默认批处理大小为 1MB,这是大多数用例中最大吞吐量的最佳选择。Kafka 可以在减少吞吐量下容纳更大的批处理,假设有足够的磁盘容量。

大型消息大小以四种方式处理:

  1. 生产者消息压缩 将压缩消息写入日志。
  2. 基于参考的消息传递仅发送对消息值中存储的其他系统中数据的引用。
  3. 内联消息传递将信息分成使用相同键的块,然后使用流处理器(如 Kafka Streams)在输出中合并。
  4. 构建的 broker 和 producer/consumer 客户端应用程序配置来处理更大的消息大小。

建议使用基于参考的消息和消息压缩选项,并涵盖大多数情况。对于这些选项,必须小心才能避免引入性能问题。

制作者压缩

对于生成者配置,您可以指定一个 compression.type,如 Gzip,它被应用到制作者生成的数据的批处理。使用代理配置 compression.type=producer,代理会保留使用制作者的任何压缩。每当制作者和主题压缩不匹配时,代理必须在将批处理附加到日志前再次压缩批处理,这会影响代理性能。

压缩还会在生产者和解压缩开销上增加额外的处理开销,但在批处理中包含更多的数据,因此当消息数据压缩良好时,吞吐量通常很有用。

将生成者压缩与批处理大小的微调相结合,以促进最佳吞吐量。使用指标有助于量化所需的平均批处理大小。

基于参考的消息传递

当您不知道消息有多大时,基于参考的消息传递对于数据复制非常有用。外部数据存储必须快速、持久且高度可用,才能使此配置正常工作。数据被写入数据存储,并返回对数据的引用。producer 发送一条消息,其中包含对 Kafka 的引用。消费者从消息中获取引用,并使用它来从数据存储中获取数据。

图 6.4. 基于参考的消息传递流

当消息传递需要更多行程时,端到端延迟会增加。这个方法的另一个显著缺陷是,在清理 Kafka 消息时,外部系统中没有自动清理数据。混合方法是仅将大型消息发送到数据存储并直接处理标准化消息。

内联消息传递

内联消息传递非常复杂,但它对基于参考的消息等外部系统没有开销。

如果消息太大,则生成客户端应用必须序列化,然后对数据进行阻塞。然后,生成者使用 Kafka ByteArraySerializer,或者在发送前再次序列化每个块。消费者跟踪消息和缓冲区块,直到它有完整的消息。消耗客户端应用程序接收块,这些块在进行序列化前被编译。根据每个块消息集合的第一个或最后一个块的偏移量,将完整消息发送到消耗应用程序的剩余部分。针对偏移元数据检查成功交付完整消息,以避免重新平衡期间重复。

图 6.5. 内联消息传递流

内联消息传递在消费者端具有性能开销,因为需要缓冲,特别是在并行处理一系列大型消息时。大型消息的块可能会变为交集,因此如果缓冲区中另一个大消息的块不完整,则无法提交消息的所有区块。因此,通常通过持久保留消息块或实施提交逻辑来支持缓冲。

配置以处理更大的信息

如果无法避免更大的消息,并且避免在消息流的任意点进行块,您可以增加消息限制。为此,请在主题级别上配置 message.max.bytes,以设置各个主题的最大记录批处理大小。如果您在代理级别上设置 message.max.bytes,则为所有主题允许更大的消息。

代理将拒绝任何大于 message.max.bytes 设置的限制的消息。producers 的缓冲区大小(max.request.size)和消费者(message.max.bytes)必须能够容纳更大的消息。

6.1.1.10. 控制消息数据的日志清除

log flush 属性控制缓存的消息数据定期写入磁盘。调度程序以毫秒为单位指定日志缓存上的检查频率:

# ...
log.flush.scheduler.interval.ms=2000
# ...
Copy to Clipboard Toggle word wrap

您可以根据消息保留在内存中的最长时间以及日志中的最大信息数量来控制清除的频率,然后再写入磁盘:

# ...
log.flush.interval.ms=50000
log.flush.interval.messages=100000
# ...
Copy to Clipboard Toggle word wrap

flushes 之间的等待时间包括进行检查的时间以及执行刷新前指定的间隔。增加清除的频率可能会影响吞吐量。

通常,建议不要设置显式清除阈值,并让操作系统使用默认设置执行后台清除。分区复制提供比写入任何单个磁盘更高的数据持久性,因为失败的代理可以从其同步的副本中恢复。

如果您使用应用程序清除管理,如果您正在使用更快速的磁盘,则设置较低冲刷阈值可能适当。

6.1.1.11. 分区重新平衡以实现可用性

分区可以在代理之间复制,以进行容错。对于给定分区,一个代理被选为 leader,并处理所有生成请求(写入日志)。在领导失败时,在其他代理中,分区会遵循其他代理为数据可靠性复制分区数据。

followers 通常不会提供客户端,但 broker.rack 允许消费者在 Kafka 集群跨越多个数据中心时消耗来自最接近的副本的消息。followers 仅操作从分区领导机复制消息,并允许在领导机失败时进行恢复。恢复需要同步的后续程序。遵循者通过向领导发送获取请求来保持同步,这将按顺序将消息返回到后续消息。如果已在领导消息中发现最近提交的消息,则后续者被视为同步。领导机通过查看后续程序请求的最后一个偏移来检查。不同步的后续者通常不符合领导机失败,除非允许未清理的领导选举机制

您可以在考虑不同步前调整滞后时间:

# ...
replica.lag.time.max.ms=30000
# ...
Copy to Clipboard Toggle word wrap

Lag time 对时间设置了一个上限,以将消息复制到所有同步副本以及生成者必须等待确认的时间。如果后续程序无法获取请求,并捕获指定滞后时间的最新消息,则会从同步的副本中删除。您可以更快地减少检测失败的副本的时间,但这样做可能会增加无法同步的后续者数量。正确的滞后时间值取决于网络延迟和代理磁盘带宽。

当领导分区不再可用时,会选择其中一个同步副本作为新的领导。分区副本列表中的第一个代理称为 首选 领导。默认情况下,根据定期检查领导发行版,为自动分区领导重新平衡启用 Kafka。也就是说,Kafka 会检查首选领导是否为 当前的 领导。重新平衡可确保领导在代理和代理间均匀分布,不会超载。

您可以使用 Cruise Control for AMQ Streams 将副本分配找出在集群中平均平衡负载的代理。其计算需要考虑领导和后续者所经历的不同负载。失败的领导会影响 Kafka 集群的平衡,因为剩余的代理会获得领导额外分区的额外工作。

对于 Cruise Control 发现的分配,实际上,分区需要被首选领导。Kafka 可以自动确保首选领导(在可能的情况下),根据需要更改当前的领导。这样可确保集群处于 Cruise Control 找到的均衡状态。

您可以在重新平衡检查前控制重新平衡检查的频率,以及代理允许的最大 imbalance 百分比。

#...
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10
#...
Copy to Clipboard Toggle word wrap

代理的百分比 leader imbalance 是当前代理为当前领导的分区数量和首选领导的分区数量之间的比例。您可以将百分比设置为 0,以确保首选领导一直被选择,假设它们处于同步状态。

如果检查重新平衡需要更多控制,您可以禁用自动重新平衡。然后,您可以选择何时使用 kafka-leader-election.sh 命令行工具触发重新平衡。

注意

由 AMQ Streams 提供的 Grafana 仪表板显示没有活跃领导的分区和分区的指标。

6.1.1.12. unclean 领导选举机制

对同步副本的领导选举被视为干净,因为它不会丢失数据。这是默认发生的情况。但是,如果没有同步的副本在领导方面需要什么?或许,ISR (同步副本)仅在领导磁盘结束时包含领导机。如果没有设置最少的 in-sync 副本数量,并且硬盘驱动器无法同步分区领导机时,数据将会丢失。不仅如此,新的领导产品也无法被选举,因为没有同步的跟随者。

您可以配置 Kafka 如何处理领导失败:

# ...
unclean.leader.election.enable=false
# ...
Copy to Clipboard Toggle word wrap

默认情况下,不干净的领导选举机制被禁用,这意味着不同步的副本无法成为领导。使用干净的领导选举机制时,如果在旧领导丢失时没有其他代理,则 Kafka 会在消息写入或读取前等待该领导机在线。不干净的领导选举机制意味着不同步的副本可能会成为领导机,但您会面临丢失消息的风险。您做出的选择取决于您的要求是否优先使用可用性或持久性。

您可以在主题级别覆盖特定主题的默认配置。如果您无法承担数据丢失的风险,请保留默认配置。

6.1.1.13. 避免不必要的消费者组重新平衡

对于加入新消费者组的用户,您可以添加一个延迟,以避免对代理进行不必要的重新平衡:

# ...
group.initial.rebalance.delay.ms=3000
# ...
Copy to Clipboard Toggle word wrap

延迟是协调器等待成员加入的时间长度。延迟时间越长,所有成员都将一次加入并避免重新平衡的可能性。但是,延迟也会阻止组消耗到周期结束为止。

6.1.2. Kafka producer 配置调整

使用带有针对特定用例量身定制的可选属性的基本制作者配置。

调整配置以最大化吞吐量可能会增加延迟,反之亦然。您需要对生成者配置进行试验和调优,以获得所需的平衡。

6.1.2.1. 基本制作者配置

每个制作者都需要 connection 和 serializer 属性。通常,最好为跟踪添加客户端 ID,并使用生成者压缩来减小请求的批处理大小。

在基本制作者配置中:

  • 无法保证分区中的消息顺序。
  • 到达代理的消息不能保证持久性。

基本制作者配置属性

# ...
bootstrap.servers=localhost:9092 
1

key.serializer=org.apache.kafka.common.serialization.StringSerializer 
2

value.serializer=org.apache.kafka.common.serialization.StringSerializer 
3

client.id=my-client 
4

compression.type=gzip 
5

# ...
Copy to Clipboard Toggle word wrap

1
(必需)告诉制作者使用 Kafka 代理的 host:port bootstrap 服务器地址连接到 Kafka 集群。生产者使用地址来发现并连接到集群中的所有代理。如果服务器停机,请使用逗号分隔的列表来指定两个或三个地址,但不需要提供集群中的所有代理的列表。
2
(必需)Serializer 将每个消息的密钥转换为字节,然后再发送到代理。
3
(必需)Serializer 将每个消息的值转换为字节,然后再发送到代理。
4
(可选)客户端的逻辑名称,用于日志和指标来识别请求源。
5
(可选)压缩消息的代码c,这些消息会被发送,并可能以压缩格式存储,然后在到达消费者时解压缩。压缩可用于提高吞吐量并减少存储负载,但可能不适用于压缩或解压缩成本的低延迟应用程序。
6.1.2.2. 数据持久性

您可以使用消息发送确认来应用更大的数据持久性,以最大程度降低消息丢失的可能性。

# ...
acks=all 
1

# ...
Copy to Clipboard Toggle word wrap
1
指定 acks=all 会强制分区领导将消息复制到特定数量的后续人员,然后再确认消息请求被成功收到。由于额外的检查,acks=all 会增加生成者发送消息和接收确认之间的延迟。

在将消息发送到制作者之前,需要将消息附加到其日志中的代理数量由主题的 min.insync.replicas 配置决定。典型的起点是具有 3 个主题复制因素,其他代理上有两个同步副本。在此配置中,如果单个代理不可用,生成者可以继续不受影响。如果第二个代理不可用,则生成者将不会收到确认,且无法生成更多消息。

支持 acks=all的主题配置

# ...
min.insync.replicas=2 
1

# ...
Copy to Clipboard Toggle word wrap

1
使用 2 个同步副本。默认值为 1
注意

如果系统失败,缓冲区中数据的风险会丢失。

6.1.2.3. 订购的交付

幂等的生成者会避免在消息发送一次时重复。ID 和序列号分配给消息,以确保发送顺序,即使出现失败情况。如果您使用 acks=all 用于数据一致性,则启用 idempotency 适合于排序的发送。

使用 idempotency 排序交付

# ...
enable.idempotence=true 
1

max.in.flight.requests.per.connection=5 
2

acks=all 
3

retries=2147483647 
4

# ...
Copy to Clipboard Toggle word wrap

1
设置为 true 以启用幂等制作者。
2
随着幂等的交付,动态请求数可能大于 1,同时仍然提供消息顺序保证。默认为 5 个 in-flight 请求。
3
将 a ck 设置为 all
4
设置重新发送失败消息请求的尝试次数。

如果您由于性能成本而没有使用 acks=all 和 idempotency,请将 in-flight (未确认)请求的数量设置为 1 以保留顺序。否则,在 Message-A 已写入代理后,Message- A 才会成功。

在没有 idempotency 的情况下排序交付

# ...
enable.idempotence=false 
1

max.in.flight.requests.per.connection=1 
2

retries=2147483647
# ...
Copy to Clipboard Toggle word wrap

1
设置为 false 以禁用幂等制作者。
2
将动态请求数设置为正好 1
6.1.2.4. 可靠性保证

在对单个分区进行一次写入一次,idempotence 非常有用。事务与 idempotence 一起使用时,允许跨多个分区的一次写入一次。

使用相同事务 ID 发送的事务消息只生成一次,因此只会所有都成功写入到相应的日志,或所有都没有写入。

# ...
enable.idempotence=true
max.in.flight.requests.per.connection=5
acks=all
retries=2147483647
transactional.id=UNIQUE-ID 
1

transaction.timeout.ms=900000 
2

# ...
Copy to Clipboard Toggle word wrap
1
指定唯一事务 ID。
2
在返回超时错误前设置事务的最大允许时间(以毫秒为单位)。默认值为 900000 或 15 分钟。

选择 transactional.id 非常重要,以便保持事务保证。每个事务 ID 都应该用于一组唯一的主题分区。例如,可以使用主题分区名称的外部映射到事务 ID,或使用避免冲突的功能计算主题分区名称中的事务 ID 来实现。

6.1.2.5. 优化吞吐量和延迟

通常,系统的要求是满足给定延迟内消息的特定吞吐量目标。例如,以每秒 500,000 条消息为目标,在 2 秒内确认消息的 95%。

您的制作者的消息语义(消息排序和持久性)可能由您的应用程序的要求定义。例如,您可能没有选择使用 acks=0acks=1,而不破坏一些重要属性或应用程序提供的保证。

代理重启会对高百分比统计产生重大影响。例如,在较长的时间内,代理重启过程中会造成 99 百分比的延迟。在设计基准测试中或比较基准测试与生产环境中看到的性能号进行比较时,这值得考虑。

根据您的目标,Kafka 提供了很多配置参数和技术,用于调优生成者性能以获得吞吐量和延迟。

消息批处理(linger.msbatch.size)
消息批处理延迟会按希望向同一代理发送更多消息,从而使它们被批量批量化到单个生成请求中。批处理在返回更高吞吐量时返回延迟之间很折现。基于时间的批处理使用 linger.ms 进行配置,并且基于大小的批处理则使用 batch.size 进行配置。
压缩(compression.type)
消息压缩会增加生成者(压缩消息的 CPU 时间)的延迟,但可以使请求(以及可能的磁盘写入)更小,从而提高吞吐量。无论是值得压缩还是值得使用的最佳压缩,都将取决于所发送的消息。压缩发生在调用 KafkaProducer.send () 的线程上,因此如果此方法的延迟关系,您应该考虑使用更多线程。
pipelining (max.in.flight.requests.per.connection)
pipelining 表示在收到上一个请求的响应前发送更多请求。一般来说,管道流意味着更好的吞吐量,最多可达到其他影响的阈值,如更糟糕的批处理,开始处理对吞吐量的影响。

降低延迟

当应用程序调用 KafkaProducer.send () 时,消息是:

  • 由任何拦截器处理
  • 序列化
  • 分配给分区
  • 已压缩
  • 添加到每个分区队列中的批量消息

send () 方法返回。因此,阻止了时间 send () 是由以下决定的:

  • 拦截器、serializer 和 partitioner 花费的时间
  • 使用的压缩算法
  • 等待缓冲区用于压缩的时间

批处理将保留在队列中,直到出现以下情况之一:

  • 批处理已满(根据 batch.size
  • linger.ms 引入的延迟已经通过
  • 发件人即将将其他分区的消息批处理发送到同一代理,也可以添加此批处理
  • 生成者正在清除或关闭

查看批处理和缓冲区的配置,以减少 send () 阻止对延迟的影响。

# ...
linger.ms=100 
1

batch.size=16384 
2

buffer.memory=33554432 
3

# ...
Copy to Clipboard Toggle word wrap
1
linger 属性以毫秒为单位添加一个延迟,以便增加大量消息批处理并在请求中发送。默认值为 0'。
2
如果使用了最大 batch.size,则在达到最大值时,将发送请求,或者已排队消息的时间超过 linger.ms (以更早的时间为准)。添加延迟可让批处理将消息递增到批处理大小。
3
缓冲区大小必须至少与批处理大小相同,并且能够适应缓冲区、压缩和动态请求。

增加吞吐量

通过调整消息在发送并完成发送请求前等待的最长时间,提高消息请求的吞吐量。

您还可以通过编写自定义分区来替换默认值,将消息定向到指定的分区。

# ...
delivery.timeout.ms=120000 
1

partitioner.class=my-custom-partitioner 
2


# ...
Copy to Clipboard Toggle word wrap
1
等待完整发送请求的最长时间(毫秒)。您可以将值设为 MAX_LONG,以委派给 Kafka 的重试次数。默认值为 120000 或 2 分钟。
2
指定自定义分区器的类名称。

6.1.3. Kafka 消费者配置调整

使用带有为特定用例量身定制的可选属性的基本消费者配置。

在调整您的消费者时,您的主要关注将确保他们能够高效地处理数据量。与生成者调优一样,准备好进行增量更改,直到消费者按预期工作。

6.1.3.1. 基本消费者配置

每个消费者都需要 connection 和 deserializer 属性。通常,为跟踪添加客户端 ID 是不错的做法。

在消费者配置中,无论后续配置是什么:

  • 消费者从给定的偏移中获取,并按顺序消耗消息,除非将偏移更改为跳过或重新读取消息。
  • 代理不知道消费者是否处理响应,即使将偏移提交到 Kafka,因为偏移可能会发送到集群中的不同代理。

基本消费者配置属性

# ...
bootstrap.servers=localhost:9092 
1

key.deserializer=org.apache.kafka.common.serialization.StringDeserializer  
2

value.deserializer=org.apache.kafka.common.serialization.StringDeserializer  
3

client.id=my-client 
4

group.id=my-group-id 
5

# ...
Copy to Clipboard Toggle word wrap

1
(必需)告诉消费者使用 Kafka 代理的 host:port bootstrap 服务器地址连接到 Kafka 集群。消费者使用地址来发现并连接到集群中的所有代理。如果服务器停机,请使用逗号分隔的列表来指定两个或三个地址,但不需要提供集群中所有代理的列表。如果您使用 loadbalancer 服务公开 Kafka 集群,则只需要该服务的地址,因为可用性由 loadbalancer 处理。
2
(必需) Deserializer 将从 Kafka 代理获取的字节数转换为消息密钥。
3
(必需) Deserializer 将从 Kafka 代理获取的字节数转换为消息值。
4
(可选)客户端的逻辑名称,用于日志和指标来识别请求源。id 也可以根据处理时间配额来节流消费者。
5
(条件)消费者 需要 组 id 才能加入消费者组。
6.1.3.2. 使用消费者组扩展数据消耗

用户组共享一个通常由来自给定主题的一个或多个制作者生成的大型数据流。消费者使用 group.id 属性分组,允许消息分散到成员中。组中的一个消费者被选为领导机,决定如何将分区分配给组中的消费者。每个分区只能分配给一个消费者。

如果您还没有作为分区的用户数量,您可以通过添加具有相同 group.id 的更多消费者实例来扩展数据消耗。在组中添加比分区更多的消费者将有助于吞吐量,但这意味着在待机上有消费者能够停止工作。如果您可以使用较少的使用者达到吞吐量目标,您可以节省资源。

同一消费者组中的消费者发送偏移提交和心跳到同一代理。因此组中消费者的数量越大,代理上的请求负载越高。

# ...
group.id=my-group-id 
1

# ...
Copy to Clipboard Toggle word wrap
1
使用组 ID 将消费者添加到消费者组中。
6.1.3.3. 消息排序保证

Kafka 代理从请求代理从主题、分区和偏移位置列表中发送消息的用户接收请求。

消费者按照提交到代理的顺序在单个分区中观察信息,这意味着 Kafka 为单一分区中的消息提供排序保证。相反,如果消费者消耗来自多个分区的消息,则不同分区中消息的顺序与消费者观察到的消息顺序不一定反映了发送它们的顺序。

如果您希望严格排序来自一个主题的消息,请为每个消费者使用一个分区。

6.1.3.4. 优化吞吐量和延迟

控制客户端应用程序调用 KafkaConsumer.poll () 时返回的消息数量。

使用 fetch.max.wait.msfetch.min.bytes 属性来增加由 Kafka 代理使用者获取的最小数据量。基于时间的批处理使用 fetch.max.wait.ms 进行配置,并且基于大小的批处理则使用 fetch.min.bytes 来配置。

如果消费者或代理中的 CPU 使用率很高,这可能是因为消费者有太多请求。您可以调整 fetch.max.wait.msfetch.min.bytes 属性,以便在较大的批处理中交付较少的请求和信息。通过调整更高,吞吐量会降低延迟。如果生成的数据量较低,您也可以调整更高的数据。

例如,如果您将 fetch.max.wait.ms 设置为 500ms,并且 fetch.min.bytes 设为 16384 字节,当 Kafka 从消费者收到获取请求时,它将在达到第一个阈值时响应。

相反,您可以调整 fetch.max.wait.msfetch.min.bytes 属性,以提高端到端延迟。

# ...
fetch.max.wait.ms=500 
1

fetch.min.bytes=16384 
2

# ...
Copy to Clipboard Toggle word wrap
1
代理在完成获取请求前等待的时间(毫秒)。默认值为 500 毫秒。
2
如果使用最小批处理大小,则会在达到最小时发送请求,或者已排队消息的时间超过 fetch.max.wait.ms (以更早的时间为准)。添加延迟可让批处理将消息递增到批处理大小。

通过增加获取请求大小来降低延迟

使用 fetch.max.bytesmax.partition.fetch.bytes 属性增加消费者从 Kafka 代理获取的最大数据量。

fetch.max.bytes 属性设置一次从代理获取的数据量的最大限制(以字节为单位)。

max.partition.fetch.bytes 会以字节为单位设置每个分区返回的最大限制,每个分区必须始终大于代理或主题配置中设置的 max.message.bytes 字节数。

客户端可消耗的最大内存量大约计算为:

NUMBER-OF-BROKERS * fetch.max.bytes and NUMBER-OF-PARTITIONS * max.partition.fetch.bytes
Copy to Clipboard Toggle word wrap

如果内存用量可以容纳它,您可以增加这两个属性的值。通过允许每个请求中的更多数据,随着获取请求减少,延迟会得到提高。

# ...
fetch.max.bytes=52428800 
1

max.partition.fetch.bytes=1048576 
2

# ...
Copy to Clipboard Toggle word wrap
1
获取请求返回的最大数据量(以字节为单位)。
2
每个分区返回的最大数据量(以字节为单位)。
6.1.3.5. 在提交偏移时避免数据丢失或重复

Kafka auto-commit 机制允许 使用者自动提交消息的偏移。如果启用,消费者将从轮询代理接收的偏移以 5000ms 间隔提交。

auto-commit 机制比较方便,但它引入了数据丢失和重复的风险。如果消费者获取并转换了很多消息,但系统会在执行 auto-commit 时与消费者缓冲区中处理的消息崩溃,则该数据会丢失。如果系统在处理消息后崩溃,但在执行 auto-commit 前,数据会在重新平衡后在另一个消费者实例上重复。

auto-committing 可以避免仅在下一次轮询到代理或消费者关闭前处理所有消息时数据丢失。

要最小化数据丢失或重复的可能性,您可以将 enable.auto.commit 设置为 false,并开发您的客户端应用程序来更好地控制提交偏移。或者,您可以使用 auto.commit.interval.ms 来减少提交之间的间隔。

# ...
enable.auto.commit=false 
1

# ...
Copy to Clipboard Toggle word wrap
1
自动提交设置为 false,以提供更多对提交偏移的控制。

通过将 enable.auto.commit 设置为 false,您可以在 执行所有 处理后提交偏移,并且消息已被使用。例如,您可以设置应用程序来调用 Kafka commitSynccommitAsync 提交 API。

commitSync API 在从轮询返回的消息批处理中提交偏移量。完成批处理中的所有消息后,会调用 API。如果使用 commitSync API,则应用程序不会轮询新消息,直到批处理中的最后一个偏移提交为止。如果这对吞吐量造成负面影响,您可以更频繁地提交,也可以使用 commitAsync API。commitAsync API 不会等待代理响应提交请求,而是在重新平衡时创建更多重复的风险。常见方法是将应用程序中的提交 API 与在关闭消费者或重新平衡前使用的 commitSync API 相结合,以确保最终提交成功。

6.1.3.5.1. 控制事务消息

考虑在生成者端使用事务 ID 和启用 idempotence (enable.idempotence=true),以保证精确发送一次。然后,您可以使用 isolation.level 属性来控制消费者读取事务消息的方式。

isolation.level 属性有两个有效的值:

  • read_committed
  • read_uncommitted (default)

使用 read_committed 来确保仅由消费者读取提交的事务消息。但是,这会导致端到端延迟增加,因为消费者将无法返回消息,直到代理编写记录事务结果的事务标记(提交中止)。

# ...
enable.auto.commit=false
isolation.level=read_committed 
1

# ...
Copy to Clipboard Toggle word wrap
1
设置 read_committed,以便只有提交的消息才会被消费者读取。
6.1.3.6. 恢复失败以避免数据丢失

使用 session.timeout.msheartbeat.interval.ms 属性配置从消费者组中消费者故障检查和恢复的时间。

session.timeout.ms 属性指定消费者内消费者在被视为不活跃前与代理联系的最大时间,并在组中的活跃消费者间触发 重新平衡。当组重新平衡时,分区会被重新分配给组的成员。

heartbeat.interval.ms 属性指定消费者组协调器的 heartbeat 检查间隔(以毫秒为单位),以指示消费者处于活跃状态并连接。heartbeat 间隔必须较低,通常由第三个,而不是会话超时间隔。

如果您设置 session.timeout.ms 属性较低,则之前检测到失败的消费者,重新平衡可能会更快进行。但是,请小心地设置超时,以便代理无法及时接收心跳,并触发不必要的重新平衡。

减少心跳间隔可减少意外重新平衡的几率,但更频繁的心跳会增加代理资源的开销。

6.1.3.7. 管理偏移策略

使用 auto.offset.reset 属性来控制消费者没有提交偏移时的行为方式,或者提交的偏移不再有效或删除。

假设您首次部署使用者应用,并且从现有的主题读取消息。由于第一次使用 group.id,因此 __consumer_offsets 主题不包含此应用的任何偏移信息。新应用可以开始处理日志开始的所有现有消息,或者仅处理新消息。默认重置值为 latest (从分区末尾开始),因此缺少一些消息。为避免数据丢失,但要增加处理量,将 auto.offset.reset 设置为 earliest 以在分区的头部开始。

另外,请考虑使用 最早 的选项来避免在为代理配置偏移保留周期(offsets.retention.minutes)时丢失消息。如果消费者组或独立消费者不活跃,并在保留期间提交没有偏移,则之前提交的偏移将从 __consumer_offsets 中删除。

# ...
heartbeat.interval.ms=3000 
1

session.timeout.ms=10000 
2

auto.offset.reset=earliest 
3

# ...
Copy to Clipboard Toggle word wrap
1
根据预期的重新平衡调整较低的心跳间隔。
2
如果在超时时间到期前 Kafka 代理没有接收心跳,则消费者将从消费者组中删除,并启动重新平衡。如果代理配置具有 group.min.session.timeout.msgroup.max.session.timeout.ms,则会话超时值必须在该范围内。
3
设置为 earliest 以返回到分区的起始位置,并在未提交偏移时避免数据丢失。

如果在单个获取请求中返回的数据量较大,则在消费者处理数据前可能会出现超时。在这种情况下,您可以降低 max.partition.fetch.bytes 或增加 session.timeout.ms

6.1.3.8. 最小化重新平衡的影响

在组中活跃消费者之间的分区重新平衡是:

  • 消费者提交其偏移
  • 要形成的新消费者组
  • 为组成员分配分区的组领导者
  • 组中的消费者,接收其分配并开始获取

很明显,这个过程会增加服务的停机时间,特别是在消费者组集群滚动重启后重复发生时。

在这种情况下,您可以使用 静态成员资格 的概念来减少重新平衡数量。重新平衡在消费者组成员之间平均分配主题分区。静态成员资格使用持久性,以便在会话超时后重启过程中识别消费者实例。

消费者组协调器可以使用使用 group.instance.id 属性指定的唯一 id 来识别新的消费者实例。在重启过程中,消费者被分配一个新的成员 ID,但作为静态成员,它将继续使用相同的实例 ID,并且进行相同的主题分区分配。

如果消费者应用程序没有调用至少轮询每个 max.poll.interval.ms 毫秒,则消费者被视为失败,从而导致重新平衡。如果应用程序无法处理从轮询时返回的所有记录,您可以使用 max.poll.interval.ms 属性指定从消费者轮询新消息之间的间隔(毫秒)。或者,您可以使用 max.poll.records 属性设置从消费者缓冲区返回的记录数量的最大限制,允许您的应用程序处理 max.poll.interval.ms 限值中的记录数量。

# ...
group.instance.id=UNIQUE-ID 
1

max.poll.interval.ms=300000 
2

max.poll.records=500 
3

# ...
Copy to Clipboard Toggle word wrap
1
唯一的实例 id 确保新的消费者实例接收相同的主题分区分配。
2
设置间隔以检查消费者正在继续处理消息。
3
设置从消费者返回的已处理记录的数量。

6.2. 使用 Kafka 静态配额插件对代理设置限制

重要

Kafka 静态配额插件只是一个技术预览。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中实施任何技术预览功能。此技术预览功能为您提供对即将推出的产品创新的早期访问,允许您在开发过程中测试并提供反馈。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

使用 Kafka 静态配额插件在 Kafka 集群中的代理上设置吞吐量和存储限制。您可以通过在 Kafka 配置文件中添加属性来启用插件和设置限制。您可以设置字节阈值和存储配额,以在与代理交互的客户端上放置限制。

您可以为生成者和消费者带宽设置字节阈值。总限制分布在访问代理的所有客户端中。例如,您可以为制作者设置 40 MBps 的字节阈值。如果两个制作者正在运行,则它们各自限制为 20 MBps 的吞吐量。

存储配额在软限制和硬限制之间节流 Kafka 磁盘存储限制。限制适用于所有可用磁盘空间。生产者在软限制和硬限制之间逐渐减慢。限制可防止磁盘填满速度超过其容量。完整磁盘可能会导致出现问题。硬限制是最大存储限制。

注意

对于 JBOD 存储,限制适用于所有磁盘。如果代理使用两个 1 TB 磁盘,且配额为 1.1 TB,则一个磁盘可能会填满,另一个磁盘将大约为空。

先决条件

流程

  1. 编辑 /opt/kafka/config/server.properties Kafka 配置文件。

    本例中显示了插件属性。

    Kafka 静态配额插件配置示例

    # ...
    client.quota.callback.class=io.strimzi.kafka.quotas.StaticQuotaCallback 
    1
    
    client.quota.callback.static.produce=1000000 
    2
    
    client.quota.callback.static.fetch=1000000 
    3
    
    client.quota.callback.static.storage.soft=400000000000 
    4
    
    client.quota.callback.static.storage.hard=500000000000 
    5
    
    client.quota.callback.static.storage.check-interval=5 
    6
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    加载 Kafka Static Quota 插件。
    2
    设置制作者字节阈值。本示例中为 1 Mbps.
    3
    设置消费者字节阈值。本示例中为 1 Mbps.
    4
    为存储设置较低软限制。在本示例中为 400 GB。
    5
    为存储设置更高的硬限制。本例中为 500 GB。
    6
    设置存储检查间隔(以秒为单位)。本示例中为 5 秒。您可以将其设置为 0 来禁用检查。
  2. 使用默认配置文件启动 Kafka 代理。

    su - kafka
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  3. 验证 Kafka 代理是否正在运行。

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap

6.3. 扩展集群

6.3.1. 扩展 Kafka 集群

6.3.1.1. 在集群中添加代理

增加主题吞吐量的主要方法是增加该主题的分区数。这可以正常工作,因为分区允许在集群中的代理之间共享该主题的负载。当某些资源(通常是 I/O)的限制代理时,使用更多分区不会增加吞吐量。反之,您必须在集群中添加代理。

当您向集群添加额外的代理时,AMQ Streams 不会自动将任何分区分配给它。您必须决定将哪些分区从现有代理移到新代理中。

在所有代理间重新分发分区后,每个代理都应该有较低的资源使用率。

6.3.1.2. 从集群中删除代理

从集群中删除代理前,您必须确保它没有被分配给任何分区。您应该决定哪些剩余的代理将负责代理中的每个分区被停用。代理没有分配的分区后,您可以停止它。

6.3.2. 重新分配分区

kafka-reassign-partitions.sh 实用程序用于将分区重新分配给不同的代理。

它有三种不同的模式:

--generate
取一组主题和代理,并生成 重新分配 JSON 文件,这会导致将这些主题的分区分配给这些代理。生成 重新分配 JSON 文件 的一种简单方法是,但它对整个主题进行操作,因此其使用并不始终合适。
--execute
取一个 重新分配 JSON 文件,并将其应用到集群中的分区和代理。获得分区的代理将遵循分区领导机。对于给定分区,当新代理发现并加入 ISR 后,旧代理将停止为后续,并删除其副本。
--verify
使用与 --execute 步骤相同的重新分配 JSON 文件--verify 会检查文件中所有分区是否已移至其预期的代理中。如果重新分配完成,它将删除任何无效 节流。除非被删除,throttles 将继续影响集群,即使重新分配完成后也是如此。

在任何给定时间,集群中只能有一个重新分配运行,且无法取消正在运行的重新分配。如果您需要取消重新分配,则必须等待它完成,然后执行另一个重新分配来恢复第一个重新分配的影响。kafka-reassign-partitions.sh 将打印这个 reversion 的重新分配 JSON 作为其输出的一部分。非常大的重新分配应该被分解为多个较小的重新分配,以防需要停止 in-progress 重新分配。

6.3.2.1. 重新分配 JSON 文件

重新分配 JSON 文件具有特定的结构:

{
  "version": 1,
  "partitions": [
    <PartitionObjects>
  ]
}
Copy to Clipboard Toggle word wrap

其中 <PartitionObjects > 是以逗号分隔的对象列表,如下所示:

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ],
  "log_dirs": [<LogDirs>]
}
Copy to Clipboard Toggle word wrap

"log_dirs" 属性是可选的,用于将分区移到特定的日志目录中。

以下是一个示例重新分配 JSON 文件,它将主题 topic-a, 分区 4 分配给代理 2, 47;主题 topic-b 的分区 2 分配给代理 1, 57

{
  "version": 1,
  "partitions": [
    {
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7]
    },
    {
      "topic": "topic-b",
      "partition": 2,
      "replicas": [1,5,7]
    }
  ]
}
Copy to Clipboard Toggle word wrap

不包含在 JSON 中的分区不会改变。

6.3.2.2. 生成重新分配 JSON 文件

为给定一组代理分配给定主题的所有分区的最简单方法是使用 kafka-reassign-partitions.sh --generate 命令生成一个重新分配 JSON 文件。

bin/kafka-reassign-partitions.sh --zookeeper <ZooKeeper> --topics-to-move-json-file <TopicsFile> --broker-list <BrokerList> --generate
Copy to Clipboard Toggle word wrap

& lt;TopicsFile > 是一个 JSON 文件,它列出了要移动的主题。它具有以下结构:

{
  "version": 1,
  "topics": [
    <TopicObjects>
  ]
}
Copy to Clipboard Toggle word wrap

其中 <TopicObjects > 是以逗号分隔的对象列表,如下所示:

{
  "topic": <TopicName>
}
Copy to Clipboard Toggle word wrap

例如,要将 topic-atopic-b 的所有分区移动到代理 47

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-be-moved.json --broker-list 4,7 --generate
Copy to Clipboard Toggle word wrap

where topics-to-be-moved.json has contents:

{
  "version": 1,
  "topics": [
    { "topic": "topic-a"},
    { "topic": "topic-b"}
  ]
}
Copy to Clipboard Toggle word wrap
6.3.2.3. 手动创建重新分配 JSON 文件

如果要移动特定分区,您可以手动创建重新分配 JSON 文件。

6.3.3. 重新分配节流

重新分配分区可能会是一个较慢的过程,因为它可能需要在代理间移动大量数据。为了避免这会对客户端产生不利影响,可以限制重新分配。使用节流意味着重新分配需要更长的时间。如果节流过低,则新分配的代理将无法与发布记录保持同步,且重新分配永远不会完成。如果节流过高,客户端将会受到影响。例如,对于制作者,这可能比正常延迟高,等待确认。对于消费者,这可能因为轮询之间延迟更高的吞吐量导致的吞吐量下降。

6.3.4. 扩展 Kafka 集群

这个步骤描述了如何增加 Kafka 集群中的代理数量。

先决条件

  • 现有的 Kafka 集群。
  • 安装了 AMQ 代理的新机器。
  • 重新分配 JSON 文件,了解如何将分区重新分配给放大集群中的代理。

流程

  1. 使用与集群中其他代理相同的设置为新代理创建配置文件,但 broker.id 除外,它应该是未被任何其他代理使用的编号。
  2. 启动新的 Kafka 代理,将您在上一步中创建的配置文件作为 kafka-server-start.sh 脚本的参数:

    su - kafka
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  3. 验证 Kafka 代理是否正在运行。

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap
  4. 为每个新代理重复上述步骤。
  5. 使用 kafka-reassign-partitions.sh 命令行工具执行分区重新分配。

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --execute
    Copy to Clipboard Toggle word wrap

    如果要节流复制,您还可以通过 --throttle 选项,并传递一个 inter-broker 节流率(以字节/秒为单位)。例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 5000000 --execute
    Copy to Clipboard Toggle word wrap

    此命令将输出两个重新分配 JSON 对象。第一个记录正在移动的分区的当前分配。如果需要稍后恢复重新分配,您应该将其保存到文件中。第二个 JSON 对象是在重新分配 JSON 文件中传递的目标重新分配。

  6. 如果您需要在重新分配过程中更改节流,您可以使用带有不同节流率相同的命令行。例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 10000000 --execute
    Copy to Clipboard Toggle word wrap
  7. 使用 kafka-reassign-partitions.sh 命令行工具定期验证重新分配是否已完成。这与上一步的命令相同,但使用 --verify 选项而不是 --execute 选项。

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --verify
    Copy to Clipboard Toggle word wrap

    例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --verify
    Copy to Clipboard Toggle word wrap
  8. --verify 命令报告以成功完成方式移动的每个分区时,重新分配已完成。最后 --verify 也具有删除任何重新分配节流的影响。现在,如果您保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。

6.3.5. 缩减 Kafka 集群

其他资源

这个步骤描述了如何减少 Kafka 集群中的代理数量。

先决条件

  • 现有的 Kafka 集群。
  • 重新分配 JSON 文件,在代理被删除后,如何将分区重新分配给集群中的代理。

流程

  1. 使用 kafka-reassign-partitions.sh 命令行工具执行分区重新分配。

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --execute
    Copy to Clipboard Toggle word wrap

    如果要节流复制,您还可以通过 --throttle 选项,并传递一个 inter-broker 节流率(以字节/秒为单位)。例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 5000000 --execute
    Copy to Clipboard Toggle word wrap

    此命令将输出两个重新分配 JSON 对象。第一个记录正在移动的分区的当前分配。如果需要稍后恢复重新分配,您应该将其保存到文件中。第二个 JSON 对象是在重新分配 JSON 文件中传递的目标重新分配。

  2. 如果您需要在重新分配过程中更改节流,您可以使用带有不同节流率相同的命令行。例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 10000000 --execute
    Copy to Clipboard Toggle word wrap
  3. 使用 kafka-reassign-partitions.sh 命令行工具定期验证重新分配是否已完成。这与上一步的命令相同,但使用 --verify 选项而不是 --execute 选项。

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --verify
    Copy to Clipboard Toggle word wrap

    例如:

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --verify
    Copy to Clipboard Toggle word wrap
  4. --verify 命令报告以成功完成方式移动的每个分区时,重新分配已完成。最后 --verify 也具有删除任何重新分配节流的影响。现在,如果您保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。
  5. 所有分区重新分配完成后,会删除代理应该不会对集群中的任何分区负责。您可以通过检查代理的 log.dirs 配置参数中提供的每个目录来验证这一点。如果代理中的任何日志目录包含一个与扩展正则表达式 \.[a-z0-9]-delete$ 不匹配的目录,则代理仍具有实时分区,不应停止。

    您可以通过执行以下命令来检查它:

    ls -l <LogDir> | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'
    Copy to Clipboard Toggle word wrap

    如果上述命令打印任何输出,则代理仍有实时分区。在这种情况下,重新分配还没有完成,或者重新分配 JSON 文件不正确。

  6. 确认代理没有实时分区后,就可以停止它。

    su - kafka
    /opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap
  7. 确认 Kafka 代理已停止。

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

6.3.6. 扩展 ZooKeeper 集群

这个步骤描述了如何在 ZooKeeper 集群中添加服务器(节点)。ZooKeeper 的动态重新配置 功能在扩展过程中维护稳定的 ZooKeeper 集群。

先决条件

  • ZooKeeper 配置文件中启用了动态重新配置(reconfigEnabled=true)。
  • 启用了 ZooKeeper 身份验证,您可以使用身份验证机制访问新的服务器。

流程

对每个 ZooKeeper 服务器执行以下步骤,一次:

  1. 在 ZooKeeper 集群中添加服务器,如 第 3.3 节 “运行多节点 ZooKeeper 集群” 所述,然后启动 ZooKeeper。
  2. 请注意新服务器的 IP 地址和配置的访问端口。
  3. 为服务器启动 zookeeper-shell 会话。从可以访问集群的机器中运行以下命令(如果可以访问集群,这可能是 ZooKeeper 节点或本地机器之一)。

    su - kafka
    /opt/kafka/bin/zookeeper-shell.sh <ip-address>:<zk-port>
    Copy to Clipboard Toggle word wrap
  4. 在 shell 会话中,运行 ZooKeeper 节点,输入以下行将新服务器作为投票成员添加到仲裁中:

    reconfig -add server.<positive-id> = <address1>:<port1>:<port2>[:role];[<client-port-address>:]<client-port>
    Copy to Clipboard Toggle word wrap

    例如:

    reconfig -add server.4=172.17.0.4:2888:3888:participant;172.17.0.4:2181
    Copy to Clipboard Toggle word wrap

    其中 <positive-id> 是新服务器 ID 4

    对于两个端口,<port1> 2888 用于 ZooKeeper 服务器之间的通信,<port2> 3888 用于领导选举机制。

    新配置传播到 ZooKeeper 集群中的其他服务器 ; 新服务器现在是仲裁的完整成员。

  5. 对您要添加的其他服务器重复步骤 1-4。

6.3.7. 缩减 ZooKeeper 集群

这个步骤描述了如何从 ZooKeeper 集群中删除服务器(节点)。ZooKeeper 的动态重新配置 功能在缩减过程中维护稳定的 ZooKeeper 集群。

先决条件

  • ZooKeeper 配置文件中启用了动态重新配置(reconfigEnabled=true)。
  • 启用了 ZooKeeper 身份验证,您可以使用身份验证机制访问新的服务器。

流程

对每个 ZooKeeper 服务器执行以下步骤,一次:

  1. 登录到在缩减后会保留的其中一个服务器上的 zookeeper-shell(例如,服务器 1)。

    注意

    使用为 ZooKeeper 集群配置的验证机制访问服务器。

  2. 删除服务器,如 server 5。

    reconfig -remove 5
    Copy to Clipboard Toggle word wrap
  3. 取消激活您删除的服务器。
  4. 重复步骤 1-3 以减小集群大小。

第 7 章 Kafka Connect

Kafka Connect 是一个在 Apache Kafka 和外部系统间流传输数据的工具。它提供移动大量数据的框架,同时保持可扩展性和可靠性。Kafka Connect 通常用于将 Kafka 与 Kafka 集群外部的数据库、存储和消息传递系统集成。

Kafka Connect 使用连接器插件,为不同类型的外部系统实现连接。有两种连接器插件:接收器和源。sink 连接器将数据从 Kafka 流传输到外部系统。源连接器将来自外部系统的数据流传输到 Kafka。

Kafka Connect 可使用独立或分布式模式运行。

独立模式
在独立模式中,Kafka Connect 在带有从属性文件中读取的用户定义的配置的单个节点上运行。
分布式模式
在分布式模式中,Kafka Connect 在一个或多个 worker 节点上运行,工作负载分布在它们中。您可以使用 HTTP REST 接口管理连接器及其配置。

7.1. 独立模式的 Kafka 连接

在独立模式中,Kafka Connect 作为单个进程在单一节点上运行。您可以使用属性文件管理独立模式的配置。

7.1.1. 在独立模式中配置 Kafka 连接

要在独立模式下配置 Kafka Connect,请编辑 config/connect-standalone.properties 配置文件。以下选项是最重要的。

bootstrap.servers
用作 Kafka 的 bootstrap 连接的 Kafka 代理地址列表。例如: kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
key.converter
用于将消息密钥转换为 Kafka 格式的类。例如,org.apache.kafka.connect.json.JsonConverter.
value.converter
用于将消息有效负载转换为 Kafka 格式的类。例如,org.apache.kafka.connect.json.JsonConverter.
offset.storage.file.filename
指定存储偏移数据的文件。

安装目录中提供了示例配置文件,即 config/connect-standalone.properties。有关所有支持的 Kafka Connect 配置选项的完整列表,请参阅 Kafka Connect 配置参数

连接器插件使用 bootstrap 地址打开到 Kafka 代理的客户端连接。要配置这些连接,请使用以 producer.consumer. 为前缀的标准 Kafka producer 和使用者配置选项。

有关配置 Kafka 生成者和消费者的更多信息,请参阅:

7.1.2. 在独立模式中配置 Kafka Connect 的连接器

您可以使用属性文件在独立模式中配置 Kafka Connect 的连接器插件。大多数配置选项都特定于每个连接器。以下选项适用于所有连接器:

name
连接器的名称,它在当前 Kafka Connect 实例中必须是唯一的。
connector.class
连接器插件的类。例如,org.apache.kafka.connect.file.FileStreamSinkConnector
tasks.max
指定连接器可以使用的最大任务数量。任务可让连接器并行执行工作。连接器可能会创建比指定更少的任务。
key.converter
用于将消息密钥转换为 Kafka 格式的类。这会覆盖 Kafka Connect 配置设置的默认值。例如,org.apache.kafka.connect.json.JsonConverter.
value.converter
用于将消息有效负载转换为 Kafka 格式的类。这会覆盖 Kafka Connect 配置设置的默认值。例如,org.apache.kafka.connect.json.JsonConverter.

另外,您必须为接收器连接器设置以下选项之一:

topics
以逗号分隔的主题列表,用作输入。
topics.regex
用作输入的 Java 正则表达式。

有关所有其他选项,请查看可用连接器的文档。

AMQ Streams 包括示例连接器配置文件 - 请参阅 AMQ Streams 安装目录中的 config/connect-file-sink.propertiesconfig/connect-file-source.properties

7.1.3. 在独立模式中运行 Kafka 连接

这个步骤描述了如何在独立模式中配置和运行 Kafka Connect。

先决条件

  • 已安装并运行 AMQ Streams} 集群。

流程

  1. 编辑 /opt/kafka/config/connect-standalone.properties Kafka 连接配置文件,并将 bootstrap.server 设置为指向您的 Kafka 代理。例如:

    bootstrap.servers=kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
    Copy to Clipboard Toggle word wrap
  2. 使用配置文件启动 Kafka 连接并指定一个或多个连接器配置。

    su - kafka
    /opt/kafka/bin/connect-standalone.sh /opt/kafka/config/connect-standalone.properties connector1.properties
    [connector2.properties ...]
    Copy to Clipboard Toggle word wrap
  3. 验证 Kafka Connect 是否正在运行。

       jcmd | grep ConnectStandalone
    Copy to Clipboard Toggle word wrap

其他资源

7.2. 在分布式模式下的 Kafka Connect

在分布式模式中,Kafka Connect 在一个或多个 worker 节点上运行,工作负载分布在它们中。您可以使用 HTTP REST 接口管理连接器插件及其配置。

7.2.1. 在分布式模式下配置 Kafka 连接

要在分布式模式下配置 Kafka Connect,请编辑 config/connect-distributed.properties 配置文件。以下选项是最重要的。

bootstrap.servers
用作 Kafka 的 bootstrap 连接的 Kafka 代理地址列表。例如: kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
key.converter
用于将消息密钥转换为 Kafka 格式的类。例如,org.apache.kafka.connect.json.JsonConverter.
value.converter
用于将消息有效负载转换为 Kafka 格式的类。例如,org.apache.kafka.connect.json.JsonConverter.
group.id
分布式 Kafka Connect 集群的名称。这必须是唯一的,且不得与另一个消费者组 ID 冲突。默认值为 connect-cluster
config.storage.topic
用于存储连接器配置的 Kafka 主题。默认值为 connect-configs
offset.storage.topic
用于存储偏移的 Kafka 主题。默认值为 connect-offset
status.storage.topic
用于 worker 节点状态的 Kafka 主题。默认值为 connect-status

AMQ Streams 在分布式模式下包括 Kafka Connect 的示例配置文件 - 请参阅 AMQ Streams 安装目录中的 config/connect-distributed.properties

有关所有支持的 Kafka Connect 配置选项的完整列表,请参阅 Kafka Connect 配置参数

连接器插件使用 bootstrap 地址打开到 Kafka 代理的客户端连接。要配置这些连接,请使用以 producer.consumer. 为前缀的标准 Kafka producer 和使用者配置选项。

有关配置 Kafka 生成者和消费者的更多信息,请参阅:

7.2.2. 在分布式 Kafka Connect 中配置连接器

HTTP REST 接口

分布式 Kafka Connect 的连接器使用 HTTP REST 接口进行配置。默认情况下,REST 接口侦听端口 8083。它支持以下端点:

GET /connectors
返回现有连接器列表。
POST /connectors
创建连接器。请求正文必须是带有连接器配置的 JSON 对象。
GET /connectors/ <name>
获取有关特定连接器的信息。
GET /connectors/ &lt;name&gt; /config
获取特定连接器的配置。
PUT /connectors/ &lt;name&gt; /config
更新特定连接器的配置。
GET /connectors/ &lt;name&gt; /status
获取特定连接器的状态。
PUT /connectors/ &lt;name&gt; /pause
暂停连接器及其所有任务。连接器将停止处理任何信息。
PUT /connectors/ &lt;name&gt; /resume
恢复暂停的连接器。
POST /connectors/ &lt;name&gt; /restart
如果连接器失败,请重启它。
DELETE /connectors/ <name>
删除连接器。
GET /connector-plugins
获取所有支持的连接器插件的列表。

连接器配置

大多数配置选项都是特定于连接器的,包括在连接器的文档中。以下字段适用于所有连接器。

name
连接器的名称。在给定的 Kafka Connect 实例中必须是唯一的。
connector.class
连接器插件的类。例如 org.apache.kafka.connect.file.FileStreamSinkConnector
tasks.max
此连接器使用的最大任务数量。连接器使用任务来并行处理其工作。Connetors 可以创建比指定更少的任务。
key.converter
用于将消息密钥转换为 Kafka 格式的类。这会覆盖 Kafka Connect 配置设置的默认值。例如,org.apache.kafka.connect.json.JsonConverter.
value.converter
用于将消息有效负载转换为 Kafka 格式的类。这会覆盖 Kafka Connect 配置设置的默认值。例如,org.apache.kafka.connect.json.JsonConverter.

另外,必须为接收器连接器设置以下选项之一:

topics
以逗号分隔的主题列表,用作输入。
topics.regex
用作输入的 Java 正则表达式。

有关所有其他选项,请查看特定连接器的文档。

AMQ Streams 包括示例连接器配置文件。您可以在 AMQ Streams 安装目录中的 config/connect-file-sink.propertiesconfig/connect-file-source.properties 中找到。

7.2.3. 运行分布式 Kafka Connect

这个步骤描述了如何在分布式模式下配置和运行 Kafka Connect。

先决条件

  • 已安装并运行 AMQ Streams 集群。

运行集群

  1. 编辑所有 Kafka Connect worker 节点上的 /opt/kafka/config/connect-distributed.properties Kafka Connect 配置文件。

    • 设置 bootstrap.server 选项以指向 Kafka 代理。
    • 设置 group.id 选项。
    • 设置 config.storage.topic 选项。
    • 设置 offset.storage.topic 选项。
    • 设置 status.storage.topic 选项。

      例如:

      bootstrap.servers=kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
      group.id=my-group-id
      config.storage.topic=my-group-id-configs
      offset.storage.topic=my-group-id-offsets
      status.storage.topic=my-group-id-status
      Copy to Clipboard Toggle word wrap
  2. 使用所有 Kafka Connect 节点上的 /opt/kafka/config/connect-distributed.properties 配置文件启动 Kafka Connect worker。

    su - kafka
    /opt/kafka/bin/connect-distributed.sh /opt/kafka/config/connect-distributed.properties
    Copy to Clipboard Toggle word wrap
  3. 验证 Kafka Connect 是否正在运行。

    jcmd | grep ConnectDistributed
    Copy to Clipboard Toggle word wrap

其他资源

7.2.4. 创建连接器

此流程描述了如何使用 Kafka Connect REST API 创建连接器插件,以便在分布式模式中使用 Kafka Connect。

先决条件

  • 以分布式模式运行的 Kafka 连接安装。

流程

  1. 使用连接器配置准备 JSON 有效负载。例如:

    {
      "name": "my-connector",
      "config": {
      "connector.class": "org.apache.kafka.connect.file.FileStreamSinkConnector",
        "tasks.max": "1",
        "topics": "my-topic-1,my-topic-2",
        "file": "/tmp/output-file.txt"
      }
    }
    Copy to Clipboard Toggle word wrap
  2. 发送 POST 请求到 <KafkaConnectAddress>:8083/connectors,以创建连接器。以下示例使用 curl

    curl -X POST -H "Content-Type: application/json" --data @sink-connector.json http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap
  3. 通过向 < KafkaConnectAddress > :8083/connectors 发送 GET 请求来验证连接器是否已部署。以下示例使用 curl

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

7.2.5. 删除连接器

此流程描述了如何使用 Kafka Connect REST API 从分布式模式的 Kafka Connect 中删除连接器插件。

先决条件

  • 以分布式模式运行的 Kafka 连接安装。

删除连接器

  1. 通过向 <KafkaConnectAddress>:8083/connectors/<ConnectorName> 发送 GET 请求来验证连接器是否存在。以下示例使用 curl

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap
  2. 要删除连接器,请发送 DELETE 请求到 < KafkaConnectAddress& gt; :8083/connectors。以下示例使用 curl

    curl -X DELETE http://connect0.my-domain.com:8083/connectors/my-connector
    Copy to Clipboard Toggle word wrap
  3. 通过向 < KafkaConnectAddress > :8083/connectors 发送 GET 请求来验证连接器是否已删除。以下示例使用 curl

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

7.3. 连接器插件

AMQ Streams 中包含以下连接器插件。

FileStreamSink
从 Kafka 主题读取数据,并将数据写入一个文件中。
FileStreamSource
从文件中读取数据,并将数据发送到 Kafka 主题。

如果需要,您可以添加更多连接器插件。Kafka Connect 在启动时搜索并运行其他连接器插件。要定义 kafka Connect 搜索插件的路径,请设置 plugin.path 配置选项

plugin.path=/opt/kafka/connector-plugins,/opt/connectors
Copy to Clipboard Toggle word wrap

plugin.path 配置选项可以包含以逗号分隔的路径列表。

当在分布式模式下运行 Kafka Connect 时,所有 worker 节点上都必须提供插件。

7.4. 添加连接器插件

此流程演示了如何添加额外的连接器插件。

先决条件

  • 已安装并运行 AMQ Streams 集群。

流程

  1. 创建 /opt/kafka/connector-plugins 目录。

    su - kafka
    mkdir /opt/kafka/connector-plugins
    Copy to Clipboard Toggle word wrap
  2. 编辑 /opt/kafka/config/connect-standalone.properties/opt/kafka/config/connect-distributed.properties Kafka Connect 配置文件,并将 plugin.path 选项设置为 /opt/kafka/connector-plugins。例如:

    plugin.path=/opt/kafka/connector-plugins
    Copy to Clipboard Toggle word wrap
  3. 将连接器插件复制到 /opt/kafka/connector-plugins 中。
  4. 启动或重启 Kafka Connect worker。

其他资源

第 8 章 使用带有 MirrorMaker 2.0 的 AMQ Streams

MirrorMaker 2.0 用于在两个或更多活跃 Kafka 集群之间复制数据,并在数据中心之间复制数据。

集群间的数据复制支持需要以下场景:

  • 在系统失败时恢复数据
  • 用于分析的数据聚合
  • 对特定集群的数据访问限制
  • 在特定位置置备数据以提高延迟
注意

MirrorMaker 2.0 具有之前版本的 MirrorMaker 不支持的功能。但是,您可以将 MirrorMaker 2.0 配置为用于旧模式

8.1. MirrorMaker 2.0 数据复制

MirrorMaker 2.0 使用来自源 Kafka 集群的信息,并将其写入目标 Kafka 集群。

MirrorMaker 2.0 使用:

  • 源集群配置使用来自源集群的数据
  • 将数据输出到目标集群的目标集群配置

MirrorMaker 2.0 基于 Kafka Connect 框架,连接器 管理集群之间的数据传输。MirrorMaker 2.0 MirrorSourceConnector 将主题从源集群复制到目标集群。

将数据从一个集群镜像到另一个集群的过程是异步的。推荐的模式用于与源 Kafka 集群在本地生成信息,然后远程消耗到目标 Kafka 集群。

MirrorMaker 2.0 可以和多个源集群一起使用。

图 8.1. 在两个集群间复制

默认情况下,检查源集群中的新主题每 10 分钟进行一次。您可以通过在源连接器配置中添加 refresh.topics.interval.seconds 来更改频率。但是,增加操作的频率可能会影响整体性能。

8.2. 集群配置

您可以在主动/被动主动/主动集群配置中使用 MirrorMaker 2.0。

  • 主动/主动配置中,两个集群都处于活跃状态,并同时提供相同的数据,如果您需要在不同地理位置的本地都提供相同的数据,这个配置非常有用。
  • 主动/被动配置中,主动集群中的数据会在被动集群被复制,后者处于待机状态(例如在系统失败时进行数据恢复)。

预期的结构是,生成者和消费者仅连接到活跃集群。

每个目标目的地都需要一个 MirrorMaker 2.0 集群。

8.2.1. 双向复制(主动/主动)

MirrorMaker 2.0 架构支持主动/主动集群配置中双向复制。

每个集群使用 sourceremote 主题的概念复制其他集群的数据。因为每个集群中存储相同的主题,远程主题由 MirrorMaker 2.0 自动重命名,以代表源集群。原始集群的名称前面是主题名称的前面。

图 8.2. 主题重命名

通过标记原始集群,主题不会复制到该集群。

在配置需要数据聚合的架构时,通过 远程主题 复制的概念非常有用。消费者可以订阅同一集群中的源和目标主题,而无需单独的聚合集群。

8.2.2. 单向复制(主动/被动)

MirrorMaker 2.0 架构支持主动/被动集群配置中的单向复制。

您可以使用 主动/被动集群 配置来备份或将数据迁移到另一个集群。在这种情况下,您可能不希望自动重命名远程主题。

您可以通过将 IdentityReplicationPolicy 添加到源连接器配置来覆盖自动重命名。应用此配置后,主题会保留其原始名称。

8.2.3. 主题配置同步

主题配置在源和目标集群之间自动同步。通过同步配置属性,对重新平衡的需求会减少。

8.2.4. 数据完整性

MirrorMaker 2.0 监控源主题,并将任何配置更改传播到远程主题,检查并创建缺少的分区。只有 MirrorMaker 2.0 可以写入远程主题。

8.2.5. 偏移跟踪

MirrorMaker 2.0 使用内部主题跟踪消费者组的偏移。

  • offset-syncs 主题从记录元数据映射复制主题分区的源和目标偏移
  • checkpoints 主题映射源和目标集群中每个消费者组中复制的主题分区的最后提交偏移量

checkpoints 主题的偏移通过配置以预先确定的间隔进行跟踪。这两个主题都允许从故障转移上的正确偏移位置完全恢复复制。

MirrorMaker 2.0 使用其 MirrorCheckpointConnector 为偏移跟踪发送 检查点

offset-syncs 主题的位置是 源集群。您可以使用 offset-syncs.topic.location 连接器配置将其更改为 目标集群。您需要对包含该主题的集群进行读/写访问。使用目标集群作为 offset-syncs 主题的位置,您也可以使用 MirrorMaker 2.0,即使您只有对源集群的读访问权限。

8.2.6. 同步消费者组偏移

__consumer_offsets 主题存储每个消费者组的提交偏移信息。偏移同步会定期将源集群的消费者组的使用者偏移转移到目标集群的使用者偏移量中。

偏移同步在主动/被动配置中特别有用。如果主动集群停机,消费者应用程序可以切换到被动(standby)集群,并从最后一个传输的偏移位置获取。

要使用主题偏移同步,请通过将 sync.group.offsets.enabled 添加到检查点连接器配置来启用同步,并将属性设置为 true。默认情况下禁用同步。

在源连接器中使用 IdentityReplicationPolicy 时,还必须在检查点连接器配置中进行配置。这样可确保为正确的主题应用镜像的消费者偏移。

消费者偏移仅在目标集群中未激活的消费者组同步。

如果启用,则会定期从源集群同步偏移。您可以通过在检查点连接器配置中添加 sync.group.offsets.interval.secondsemit.checkpoints.interval.seconds 来更改频率。属性指定同步消费者组偏移的频率,以及为偏移跟踪发送检查点的频率。这两个属性的默认值为 60 秒。您还可以使用 refresh.groups.interval.seconds 属性更改检查新消费者组的频率,该属性默认为每 10 分钟执行。

由于同步基于时间,因此消费者到被动集群的任何切换都可能会导致一些消息重复。

8.2.7. 连接检查

一个 心跳 内部主题检查集群间的连接。

heartbeat 主题从源集群复制。

目标集群使用该主题来检查:

  • 管理集群间连接运行的连接器
  • 源集群可用

MirrorMaker 2.0 使用其 MirrorHeartbeatConnector 发送 执行这些检查的心跳。

8.3. 连接器配置

将 Mirrormaker 2.0 连接器配置用于编配 Kafka 集群之间的数据同步的内部连接器。

下表描述了连接器属性以及您配置为使用它们的连接器。

Expand
表 8.1. MirrorMaker 2.0 连接器配置属性
属性sourceConnectorcheckpointConnectorheartbeatConnector
admin.timeout.ms
管理任务的超时,如检测新主题。默认值为 60000 (1 分钟)。

replication.policy.class
定义远程主题命名约定的策略。默认为 org.apache.kafka.connect.mirror.DefaultReplicationPolicy

replication.policy.separator
在目标集群中用于主题命名的分隔符。默认为 . (点)。只有在 replication.policy.classDefaultReplicationPolicy 时才会使用。

consumer.poll.timeout.ms
轮询源集群时超时。默认值为 1000 (1 秒)。

 
offset-syncs.topic.location
offset-syncs 主题的位置,可以是 (默认)或 目标集群

 
topic.filter.class
选择要复制的主题的主题过滤器。默认为 org.apache.kafka.connect.mirror.DefaultTopicFilter

 
config.property.filter.class
用于选择要复制的主题配置属性的主题过滤器。默认为 org.apache.kafka.connect.mirror.DefaultConfigPropertyFilter

  
config.properties.exclude
不应复制的主题配置属性。支持以逗号分隔的属性名称和正则表达式。

  
offset.lag.max
在同步远程分区前,最大允许(不同步)偏移滞后。默认值为 100

  
offset-syncs.topic.replication.factor
内部 offset-syncs 主题的复制因素。默认值为 3

  
refresh.topics.enabled
启用检查新主题和分区。默认为 true

  
refresh.topics.interval.seconds
主题刷新的频率。默认为 600 (10 分钟)。

  
replication.factor
新主题的复制因素。默认值为 2

  
sync.topic.acls.enabled
启用从源集群同步 ACL。默认为 true。与 User Operator 不兼容。

  
sync.topic.acls.interval.seconds
ACL 同步的频率。默认为 600 (10 分钟)。

  
sync.topic.configs.enabled
启用从源集群同步主题配置。默认为 true

  
sync.topic.configs.interval.seconds
主题配置同步的频率。默认 600 (10 分钟)。

  
checkpoints.topic.replication.factor
内部 检查点 主题的复制因素。默认值为 3
 

 
emit.checkpoints.enabled
启用将消费者偏移同步到目标集群。默认为 true
 

 
emit.checkpoints.interval.seconds
消费者偏移同步的频率。默认值为 60 (1 分钟)。
 

 
group.filter.class
组过滤器,以选择要复制的消费者组。默认为 org.apache.kafka.connect.mirror.DefaultGroupFilter
 

 
refresh.groups.enabled
启用检查新的消费者组。默认为 true
 

 
refresh.groups.interval.seconds
消费者组刷新的频率。默认为 600 (10 分钟)。
 

 
sync.group.offsets.enabled
启用将消费者组偏移同步到目标集群 __consumer_offsets 主题。默认为 false
 

 
sync.group.offsets.interval.seconds
消费者组偏移同步的频率。默认值为 60 (1 分钟)。
 

 
emit.heartbeats.enabled
在目标集群中启用连接检查。默认为 true
  

emit.heartbeats.interval.seconds
连接检查的频率。默认为 1 ( 1 秒)。
  

heartbeats.topic.replication.factor
内部 心跳 主题的复制因素。默认值为 3
  

8.4. 指定最大任务数

连接器创建负责在 Kafka 中移动数据的任务。每个连接器由一个或多个运行任务的 worker 间分发的任务组成。

任务并行运行。为 worker 分配一个或多个任务。单个任务由一个 worker 处理,因此您不需要多于任务的 worker。如果有多个任务,worker 会处理多个任务。

您可以使用 tasks.max 属性指定 MirrorMaker 配置中的最大连接器任务数量。在不指定最大任务数量的情况下,默认设置是单个任务。如果基础架构支持处理开销,增加任务数量可以提高吞吐量。

MirrorMaker 连接器的 tasks.max 配置

clusters=cluster-1,cluster-2
# ...
tasks.max = 10
Copy to Clipboard Toggle word wrap

对于源连接器,可能的最大任务数是从源集群复制的每个分区。对于检查点连接器,可能的最大任务数是从源集群复制的每个组。为这些连接器启动的任务数量是最大可能任务数和 tasks.max 的值之间的较低值。

heartbeat 连接器始终使用单个任务。

8.5. 处理大量信息

如果您的 MirrorMaker 2.0 部署正在处理大量消息,您可能需要调整其配置来支持它。

数据复制的 flush 管道是 source topic →(Kafka Connect) source message queue → producer buffer → target topic。偏移清除超时周期(offset.flush.timeout.ms)是等待生成者缓冲区(producer.buffer.memory)刷新和偏移数据提交的时间。尝试避免出现大型制作者缓冲区和偏移清除超时周期不足的情况,会导致 清除 或失败提交偏移 类型错误。

这种类型的错误表示生成缓冲区中太多消息,因此在达到偏移清除超时前都无法清除它们。

如果您要获得这类错误,请尝试以下配置更改:

  • 减少 producer.buffer.memory的默认值
  • 将默认值(以毫秒为单位)增加 offset.flush.timeout.ms

更改应有助于将未完成的消息的底层 Kafka Connect 队列保持为可管理的大小。您可能需要调整值,使其具有所需的效果。

如果这些配置更改没有解决错误,您可以尝试通过执行以下操作来增加并行运行的任务数量:

  • 使用 MirrorMaker 2.0 配置中的 tasks.max 属性(connect-mirror-maker.properties)增加任务数量
  • 为运行任务的 worker 增加节点数

处理大量消息的 MirrorMaker 2.0 配置示例

clusters=cluster-1,cluster-2
# ...
cluster-2.offset.flush.timeout.ms = 30000
cluster-2.producer.buffer.memory = 8388608
# ...
tasks.max = 10
Copy to Clipboard Toggle word wrap

8.6. ACL 规则同步

如果使用 AclAuthorizer,则管理对代理访问权限的 ACL 规则也适用于远程主题。读取源主题的用户可以读取其远程的等效内容。

注意

OAuth 2.0 授权不支持以这种方式访问远程主题。

8.7. 使用 MirrorMaker 2.0 在 Kafka 集群间同步数据

使用 MirrorMaker 2.0 通过配置同步 Kafka 集群间的数据。

通过在 旧模式下运行 MirrorMaker 2.0,仍支持之前的 MirrorMaker 版本。

配置必须指定:

  • 每个 Kafka 集群
  • 每个集群的连接信息,包括 TLS 身份验证
  • 复制流和方向

    • 集群到集群
    • topic 的主题
  • 复制规则
  • 提交偏移跟踪间隔

此流程描述了如何通过在属性文件中创建配置来实现 MirrorMaker 2.0,然后在使用 MirrorMaker 脚本文件设置连接时传递属性。

注意

MirrorMaker 2.0 使用 Kafka Connect 在集群间传输数据的连接。Kafka 为数据复制提供 MirrorMaker sink 和源连接器。如果要使用连接器而不是 MirrorMaker 脚本,则必须在 Kafka Connect 集群中配置连接器。如需更多信息,请参阅 Apache Kafka 文档

开始前

./config/connect-mirror-maker.properties 中提供了示例配置属性文件。

先决条件

  • 您需要在您要复制的每个 Kafka 集群节点主机上安装 AMQ Streams。

流程

  1. 在文本编辑器中打开示例属性文件,或创建一个新文件,并编辑该文件使其包含连接信息以及每个 Kafka 集群的复制流程。

    以下示例显示了连接两个集群的配置,即 cluster-1cluster-2 双向。集群名称可通过集群属性 配置

    clusters=cluster-1,cluster-2 
    1
    
    
    cluster-1.bootstrap.servers=<cluster_name>-kafka-bootstrap-<project_name_one>:443 
    2
    
    cluster-1.security.protocol=SSL 
    3
    
    cluster-1.ssl.truststore.password=<truststore_name>
    cluster-1.ssl.truststore.location=<path_to_truststore>/truststore.cluster-1.jks_
    cluster-1.ssl.keystore.password=<keystore_name>
    cluster-1.ssl.keystore.location=<path_to_keystore>/user.cluster-1.p12_
    
    cluster-2.bootstrap.servers=CLUSTER-NAME-kafka-bootstrap-<project_name_two>:443 
    4
    
    cluster-2.security.protocol=SSL 
    5
    
    cluster-2.ssl.truststore.password=<truststore_name>
    cluster-2.ssl.truststore.location=<path_to_truststore>/truststore.cluster-2.jks_
    cluster-2.ssl.keystore.password=<keystore_name>
    cluster-2.ssl.keystore.location=<path_to_keystore>/user.cluster-2.p12_
    
    cluster-1->cluster-2.enabled=true 
    6
    
    cluster-1->cluster-2.topics=.* 
    7
    
    cluster-2->cluster-1.enabled=true 
    8
    
    cluster-2->cluster-1B->C.topics=.* 
    9
    
    
    replication.policy.separator=- 
    10
    
    sync.topic.acls.enabled=false 
    11
    
    refresh.topics.interval.seconds=60 
    12
    
    refresh.groups.interval.seconds=60 
    13
    Copy to Clipboard Toggle word wrap
    1
    每个 Kafka 集群都使用其别名来标识。
    2
    使用 bootstrap address 和端口 443 用于 cluster-1 的连接信息。两个集群都使用端口 443 连接到使用 OpenShift Routes 的 Kafka。
    3
    ssl. 属性定义 cluster-1 的 TLS 配置。
    4
    cluster-2 的连接信息。
    5
    ssl. 属性定义 cluster-2 的 TLS 配置。
    6
    cluster-1 集群启用复制流到 cluster-2 集群。
    7
    将所有主题从 cluster-1 集群复制到 cluster-2 集群。
    8
    cluster-2 集群启用复制流到 cluster-1 集群。
    9
    将特定主题从 cluster-2 集群复制到 cluster-1 集群。
    10
    定义用于重命名远程主题的分隔符。
    11
    启用后,ACL 将应用到同步主题。默认值为 false
    12
    检查之间的期间,检查要同步的新主题。
    13
    检查要同步的新消费者组之间的周期。
  2. OPTION:如果需要,请添加一个策略来覆盖远程主题的自动重命名。该主题不会用源集群的名称来附加名称,而是保留其原始名称。

    此可选设置用于主动/被动备份和数据迁移。

    replication.policy.class=org.apache.kafka.connect.mirror.IdentityReplicationPolicy
    Copy to Clipboard Toggle word wrap
  3. OPTION:如果要同步消费者组偏移,请添加配置来启用和管理同步:

    refresh.groups.interval.seconds=60
    sync.group.offsets.enabled=true 
    1
    
    sync.group.offsets.interval.seconds=60 
    2
    
    emit.checkpoints.interval.seconds=60 
    3
    Copy to Clipboard Toggle word wrap
    1
    用于同步消费者组偏移的可选设置,这对于在主动/被动配置中恢复非常有用。默认不启用同步。
    2
    如果启用了使用者组偏移的同步,您可以调整同步的频率。
    3
    调整检查偏移跟踪的频率。如果您更改了偏移同步的频率,您可能需要调整这些检查的频率。
  4. 在目标集群中启动 ZooKeeper 和 Kafka:

    su - kafka
    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  5. 使用您在属性文件中定义的集群连接配置和复制策略启动 MirrorMaker:

    /opt/kafka/bin/connect-mirror-maker.sh /config/connect-mirror-maker.properties
    Copy to Clipboard Toggle word wrap

    MirrorMaker 在集群之间设置连接。

  6. 对于每个目标集群,验证主题是否被复制:

    /bin/kafka-topics.sh --bootstrap-server <broker_address> --list
    Copy to Clipboard Toggle word wrap

8.8. 在旧模式中使用 MirrorMaker 2.0

这个步骤描述了如何将 MirrorMaker 2.0 配置为在旧模式中使用它。旧模式支持之前版本的 MirrorMaker。

MirrorMaker 脚本 /opt/kafka/bin/kafka-mirror-maker.sh 可以在传统模式下运行 MirrorMaker 2.0。

重要

Kafka MirrorMaker 1 (称为文档中的 MirrorMaker )已在 Apache Kafka 3.0.0 中弃用,并将在 Apache Kafka 4.0.0 中删除。因此,Kafka MirrorMaker 1 也已在 AMQ Streams 中弃用。当使用 Apache Kafka 4.0.0 时,Kafka MirrorMaker 1 将从 AMQ Streams 中删除。作为替换,将 MirrorMaker 2.0 与 IdentityReplicationPolicy 搭配使用。

先决条件

您需要当前与 MirrorMaker 旧版本搭配使用的属性文件。

  • /opt/kafka/config/consumer.properties
  • /opt/kafka/config/producer.properties

流程

  1. 编辑 MirrorMaker consumer.propertiesproducer.properties 文件,以关闭 MirrorMaker 2.0 功能。

    例如:

    replication.policy.class=org.apache.kafka.mirror.LegacyReplicationPolicy 
    1
    
    
    refresh.topics.enabled=false 
    2
    
    refresh.groups.enabled=false
    emit.checkpoints.enabled=false
    emit.heartbeats.enabled=false
    sync.topic.configs.enabled=false
    sync.topic.acls.enabled=false
    Copy to Clipboard Toggle word wrap
    1
    模拟之前的 MirrorMaker 版本。
    2
    MirrorMaker 2.0 禁用了功能,包括内部 检查点心跳 主题
  2. 保存更改,并使用您在之前版本的 MirrorMaker 中使用的属性文件重启 MirrorMaker:

    su - kafka /opt/kafka/bin/kafka-mirror-maker.sh \
    --consumer.config /opt/kafka/config/consumer.properties \
    --producer.config /opt/kafka/config/producer.properties \
    --num.streams=2
    Copy to Clipboard Toggle word wrap

    consumer 属性提供源集群和 producer 属性的配置,提供目标集群配置。

    MirrorMaker 在集群之间设置连接。

  3. 在目标集群中启动 ZooKeeper 和 Kafka:

    su - kafka
    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap
    su - kafka
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  4. 对于目标集群,验证主题是否被复制:

    /bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --list
    Copy to Clipboard Toggle word wrap

第 9 章 Kafka 客户端

kafka-clients JAR 文件包含 Kafka Producer 和 Consumer API 和 Kafka AdminClient API。

  • Producer API 允许应用程序将数据发送到 Kafka 代理。
  • Consumer API 允许应用程序消耗 Kafka 代理中的数据。
  • AdminClient API 提供了管理 Kafka 集群的功能,包括主题、代理和其他组件。

此流程演示了如何将 AMQ Streams Java 客户端作为依赖项添加到 Maven 项目中。

先决条件

  • 具有现有 pom.xml 的 Maven 项目。

流程

  1. 将 Red Hat Maven 存储库添加到 pom.xml 文件的 <repositories > 部分。

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
        <!-- ... -->
    
        <repositories>
            <repository>
                <id>redhat-maven</id>
                <url>https://maven.repository.redhat.com/ga/</url>
            </repository>
        </repositories>
    
        <!-- ... -->
    
    </project>
    Copy to Clipboard Toggle word wrap
  2. 将客户端添加到 pom.xml 文件的 & lt;dependencies > 部分。

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
        <!-- ... -->
    
        <dependencies>
            <dependency>
                <groupId>org.apache.kafka</groupId>
                <artifactId>kafka-clients</artifactId>
                <version>3.1.0.redhat-00004</version>
            </dependency>
        </dependencies>
    
        <!-- ... -->
    </project>
    Copy to Clipboard Toggle word wrap
  3. 构建您的 Maven 项目。

第 10 章 Kafka Streams API 概述

Kafka Streams API 允许应用程序从一个或多个输入流接收数据,执行复杂的操作,如映射、过滤或加入,并将结果写入一个或多个输出流。它是 Red Hat Maven 存储库中提供的 kafka-streams JAR 软件包的一部分。

此流程演示了如何将 AMQ Streams Java 客户端作为依赖项添加到 Maven 项目中。

先决条件

  • 具有现有 pom.xml 的 Maven 项目。

流程

  1. 将 Red Hat Maven 存储库添加到 pom.xml 文件的 <repositories > 部分。

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
        <!-- ... -->
    
        <repositories>
            <repository>
                <id>redhat-maven</id>
                <url>https://maven.repository.redhat.com/ga/</url>
            </repository>
        </repositories>
    
        <!-- ... -->
    
    </project>
    Copy to Clipboard Toggle word wrap
  2. kafka-streams 添加到 pom.xml 文件的 <dependencies > 部分。

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
        <!-- ... -->
    
        <dependencies>
            <dependency>
                <groupId>org.apache.kafka</groupId>
                <artifactId>kafka-streams</artifactId>
                <version>3.1.0.redhat-00004</version>
            </dependency>
        </dependencies>
    
        <!-- ... -->
    </project>
    Copy to Clipboard Toggle word wrap
  3. 构建您的 Maven 项目。

第 11 章 使用 Kerberos (GSSAPI)身份验证

AMQ Streams 支持使用 Kerberos (GSSAPI)身份验证协议来保护对 Kafka 集群的单点登录访问。GSSAPI 是 Kerberos 功能的 API 包装程序,从底层实现更改中模拟应用程序。

Kerberos 是一种网络身份验证系统,其允许客户端和服务器使用对称加密和信任的第三方 KDC 来互相进行身份验证。

此流程演示了如何配置 AMQ Streams,以便 Kafka 客户端可以使用 Kerberos (GSSAPI)身份验证访问 Kafka 和 ZooKeeper。

该流程假设已在 Red Hat Enterprise Linux 主机上设置了 Kerberos krb5 资源服务器。

该流程显示,带有如何配置的示例:

  1. 服务主体
  2. 使用 Kerberos 登录的 Kafka 代理
  3. zookeeper 使用 Kerberos 登录
  4. 生产者和消费者客户端使用 Kerberos 身份验证访问 Kafka

这些说明描述了在单个主机上为单个 ZooKeeper 和 Kafka 安装设置的 Kerberos,为生成者和消费者客户端提供额外的配置。

先决条件

要配置 Kafka 和 ZooKeeper 来验证和授权 Kerberos 凭证,您需要:

  • 访问 Kerberos 服务器
  • 每个 Kafka 代理主机上的 Kerberos 客户端

有关在代理主机上设置 Kerberos 服务器和客户端的详情请参考 RHEL 设置配置中的 Kerberos 示例

为身份验证添加服务主体

在 Kerberos 服务器中,为 ZooKeeper、Kafka 代理和 Kafka 生成者和消费者客户端创建服务主体(用户)。

服务主体必须采用 SERVICE-NAME/FULLY-QUALIFIED-HOST-NAME@DOMAIN-REALM 的形式。

  1. 创建通过 Kerberos KDC 存储主体密钥的服务主体和 keytab。

    例如:

    • zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM
    • kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM
    • producer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM
    • consumer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM

      ZooKeeper 服务主体必须与 Kafka config/server.properties 文件中的 zookeeper.connect 配置具有相同的主机名:

      zookeeper.connect=node1.example.redhat.com:2181
      Copy to Clipboard Toggle word wrap

      如果主机名不相同,则使用 localhost,身份验证将失败。

  2. 在主机上创建一个目录并添加 keytab 文件:

    例如:

    /opt/kafka/krb5/zookeeper-node1.keytab
    /opt/kafka/krb5/kafka-node1.keytab
    /opt/kafka/krb5/kafka-producer1.keytab
    /opt/kafka/krb5/kafka-consumer1.keytab
    Copy to Clipboard Toggle word wrap
  3. 确保 kafka 用户可以访问目录:

    chown kafka:kafka -R /opt/kafka/krb5
    Copy to Clipboard Toggle word wrap
将 ZooKeeper 配置为使用 Kerberos 登录

配置 ZooKeeper 以使用 Kerberos 密钥分发中心(KDC)使用之前为 zookeeper 创建的用户主体和 keytabs 进行身份验证。

  1. 创建或修改 opt/kafka/config/jaas.conf 文件来支持 ZooKeeper 客户端和服务器操作:

    Client {
        com.sun.security.auth.module.Krb5LoginModule required debug=true
        useKeyTab=true 
    1
    
        storeKey=true 
    2
    
        useTicketCache=false 
    3
    
        keyTab="/opt/kafka/krb5/zookeeper-node1.keytab" 
    4
    
        principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM"; 
    5
    
    };
    
    Server {
        com.sun.security.auth.module.Krb5LoginModule required debug=true
        useKeyTab=true
        storeKey=true
        useTicketCache=false
        keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
        principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    };
    
    QuorumServer {
        com.sun.security.auth.module.Krb5LoginModule required debug=true
        useKeyTab=true
        storeKey=true
        keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
        principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    };
    
    QuorumLearner {
        com.sun.security.auth.module.Krb5LoginModule required debug=true
        useKeyTab=true
        storeKey=true
        keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
        principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    };
    Copy to Clipboard Toggle word wrap
    1
    设置为 true,以从 keytab 获取主体密钥。
    2
    设置为 true 以存储主体密钥。
    3
    设置为 true,以从票据缓存获取 Ticket Granting Ticket (TGT)。
    4
    keyTab 属性指向从 Kerberos KDC 复制的 keytab 文件的位置。位置和文件必须可由 kafka 用户读取。
    5
    principal 属性配置为与 KDC 主机上创建的完全限定域名匹配,其格式是 SERVICE-NAME/FULLY-QUALIFIED-HOST@DOMAIN-NAME
  2. 编辑 opt/kafka/config/zookeeper.properties 以使用更新的 JAAS 配置:

    # ...
    
    requireClientAuthScheme=sasl
    jaasLoginRenew=3600000 
    1
    
    kerberos.removeHostFromPrincipal=false 
    2
    
    kerberos.removeRealmFromPrincipal=false 
    3
    
    quorum.auth.enableSasl=true 
    4
    
    quorum.auth.learnerRequireSasl=true 
    5
    
    quorum.auth.serverRequireSasl=true
    quorum.auth.learner.loginContext=QuorumLearner 
    6
    
    quorum.auth.server.loginContext=QuorumServer
    quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST 
    7
    
    quorum.cnxn.threads.size=20
    Copy to Clipboard Toggle word wrap
    1
    控制登录续订的频率(以毫秒为单位),可针对票据续订间隔进行调整。默认值为一小时。
    2
    指定主机名是否用作登录主体名称的一部分。如果将单个 keytab 用于集群中的所有节点,则会将其设置为 true。但是,建议为每个代理主机生成单独的 keytab 和完全限定主体以进行故障排除。
    3
    控制域名称是否从 Kerberos 协商的主体名称中分离。建议将此设置设置为 false
    4
    为 ZooKeeper 服务器和客户端启用 SASL 身份验证机制。
    5
    RequireSasl 属性控制仲裁事件是否需要 SASL 身份验证,如 master 选举机制。
    6
    loginContext 属性标识用于对指定组件进行身份验证的 JAAS 配置中登录上下文的名称。loginContext 名称与 opt/kafka/config/jaas.conf 文件中相关部分的名称对应。
    7
    控制用于组成用于识别的主体名称的命名惯例。占位符 _HOST 会自动解析为运行时由 server.1 属性定义的主机名。
  3. 使用 JVM 参数启动 ZooKeeper,以指定 Kerberos 登录配置:

    su - kafka
    export EXTRA_ARGS="-Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

    如果您不使用默认服务名称(zookeeper),请使用 -Dzookeeper.sasl.client.username=NAME 参数添加名称。

    注意

    如果您使用 /etc/krb5.conf 位置,则不需要在启动 ZooKeeper, Kafka, 或 Kafka 生成者和消费者时不需要指定 -Djava.security.krb5.conf=/etc/krb5.conf

将 Kafka 代理服务器配置为使用 Kerberos 登录

使用之前为 kafka 创建的 user principals 和 keytabs,将 Kafka 配置为使用 Kerberos 密钥分发中心(KDC)进行身份验证。

  1. 使用以下元素修改 opt/kafka/config/jaas.conf 文件:

    KafkaServer {
        com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        storeKey=true
        keyTab="/opt/kafka/krb5/kafka-node1.keytab"
        principal="kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    };
    KafkaClient {
        com.sun.security.auth.module.Krb5LoginModule required debug=true
        useKeyTab=true
        storeKey=true
        useTicketCache=false
        keyTab="/opt/kafka/krb5/kafka-node1.keytab"
        principal="kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    };
    Copy to Clipboard Toggle word wrap
  2. 通过修改 config/server.properties 文件中的监听程序配置来配置 Kafka 集群中的每个代理,以便监听程序使用 SASL/GSSAPI 登录。

    将 SASL 协议添加到监听器的安全协议映射中,并删除所有不需要的协议。

    例如:

    # ...
    broker.id=0
    # ...
    listeners=SECURE://:9092,REPLICATION://:9094 
    1
    
    inter.broker.listener.name=REPLICATION
    # ...
    listener.security.protocol.map=SECURE:SASL_PLAINTEXT,REPLICATION:SASL_PLAINTEXT 
    2
    
    # ..
    sasl.enabled.mechanisms=GSSAPI 
    3
    
    sasl.mechanism.inter.broker.protocol=GSSAPI 
    4
    
    sasl.kerberos.service.name=kafka 
    5
    
    ...
    Copy to Clipboard Toggle word wrap
    1
    配置了两个监听器:一个安全监听程序用于与客户端的通用通信(支持 TLS 用于通信),以及用于代理间通信的复制监听程序。
    2
    对于启用了 TLS 的监听程序,协议名称为 SASL_PLAINTEXT。对于启用了 TLS 的连接器,协议名称为 SASL_PLAINTEXT。如果不需要 SSL,您可以删除 ssl.* 属性。
    3
    Kerberos 验证的 SASL 机制是 GSSAPI
    4
    用于代理间通信的 Kerberos 身份验证。
    5
    用于指定用于身份验证请求的服务名称,以将其与可能使用相同的 Kerberos 配置的其他服务区分开来。
  3. 使用 JVM 参数启动 Kafka 代理,以指定 Kerberos 登录配置:

    su - kafka
    export KAFKA_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

    如果代理和 ZooKeeper 集群之前已经配置并使用基于非 Kerberos 的身份验证系统,则可以启动 ZooKeeper 和 broker 集群,并检查日志中是否存在配置错误。

    启动代理和 Zookeeper 实例后,集群现在被配置为 Kerberos 身份验证。

配置 Kafka producer 和消费者客户端以使用 Kerberos 身份验证

使用之前为 producer1consumer1 创建的用户主体和 keytabs 配置 Kafka producer 和 使用者客户端,以使用 Kerberos 密钥分发中心(KDC)进行身份验证。

  1. 将 Kerberos 配置添加到制作者或消费者配置文件中。

    例如:

    /opt/kafka/config/producer.properties

    # ...
    sasl.mechanism=GSSAPI 
    1
    
    security.protocol=SASL_PLAINTEXT 
    2
    
    sasl.kerberos.service.name=kafka 
    3
    
    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \ 
    4
    
        useKeyTab=true  \
        useTicketCache=false \
        storeKey=true  \
        keyTab="/opt/kafka/krb5/producer1.keytab" \
        principal="producer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    # ...
    Copy to Clipboard Toggle word wrap

    1
    配置 Kerberos (GSSAPI)身份验证。
    2
    Kerberos 使用 SASL 纯文本(用户名/密码)安全协议。
    3
    在 Kerberos KDC 中配置的 Kafka 的服务主体(user)。
    4
    使用 jaas.conf 中定义的相同属性,为 JAAS 配置。

    /opt/kafka/config/consumer.properties

    # ...
    sasl.mechanism=GSSAPI
    security.protocol=SASL_PLAINTEXT
    sasl.kerberos.service.name=kafka
    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
        useKeyTab=true  \
        useTicketCache=false \
        storeKey=true  \
        keyTab="/opt/kafka/krb5/consumer1.keytab" \
        principal="consumer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    # ...
    Copy to Clipboard Toggle word wrap

  2. 运行客户端,验证您可以从 Kafka 代理发送和接收信息。

    制作者客户端:

    export KAFKA_HEAP_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true"; /opt/kafka/bin/kafka-console-producer.sh --producer.config /opt/kafka/config/producer.properties  --topic topic1 --bootstrap-server node1.example.redhat.com:9094
    Copy to Clipboard Toggle word wrap

    消费者客户端:

    export KAFKA_HEAP_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true"; /opt/kafka/bin/kafka-console-consumer.sh --consumer.config /opt/kafka/config/consumer.properties  --topic topic1 --bootstrap-server node1.example.redhat.com:9094
    Copy to Clipboard Toggle word wrap

其他资源

第 12 章 用于集群重新平衡的 Cruise Control

重要

用于集群重新平衡的 Cruise Control 只是一个技术预览。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中实施任何技术预览功能。此技术预览功能为您提供对即将推出的产品创新的早期访问,允许您在开发过程中测试并提供反馈。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

您可以将 Cruise Control 部署到 AMQ Streams 集群,并使用它来在 Kafka 代理间重新平衡负载。

Cruise Control 是一个用于自动化 Kafka 操作的开源系统,如监控集群工作负载、根据预定义的限制重新平衡集群,并检测和修复异常情况。它由四个组件组成(Load Monitor、Anomaly Detector 和 Executor)和 REST API。

当 AMQ Streams 和 Cruise Control 都部署到 Red Hat Enterprise Linux 中时,您可以通过 Cruise Control REST API 访问 Cruise Control 功能。支持以下功能:

  • 配置 优化目标容量限制
  • 使用 /rebalance 端点来:

    • 根据配置的优化目标或 用户提供的 目标作为请求参数,生成优化建议,作为空运行。
    • 启动优化建议以重新平衡 Kafka 集群
  • 使用 /user_tasks 端点检查活跃重新平衡操作的进度
  • 使用 /stop_proposal_execution 端点停止活跃的重新平衡操作

目前还不支持所有其他 Cruise Control 功能,包括异常检测、通知、写入目标以及更改主题复制因素。不支持 Web UI 组件(Cruise Control Frontend)。

Red Hat Enterprise Linux 上的 Cruise Control for AMQ Streams 作为单独的 ziped 发行版本提供。如需更多信息,请参阅 第 12.2 节 “下载 Cruise Control 归档”

12.1. 为什么使用 Cruise Control?

Cruise Control 减少了运行高效 Kafka 集群的时间和工作量,在代理间有更均匀的工作负载。

典型的集群随着时间的推移可能会不均匀地加载。处理大量消息流量的分区可能无法均匀分布到可用代理中。要重新平衡集群,管理员必须监控代理上的负载,并将忙碌的分区手动分配给具有备用容量的代理。

Cruise Control 自动执行此集群重新平衡过程。它根据 CPU、磁盘和网络负载构建资源利用率 的工作负载模型。通过使用一组可配置的优化目标,您可以指示 Cruise Control 为更多均衡的分区分配生成空运行优化建议。

查看空运行优化建议后,您可以指示 Cruise Control 根据这个提议启动集群重新平衡,或生成新的提议。

当集群重新平衡操作完成后,代理会更有效地使用,Kafka 集群上的负载更为均匀。

12.2. 下载 Cruise Control 归档

可以从红帽客户门户网站下载 Cruise Control for AMQ Streams on Red Hat Enterprise Linux 的一个压缩版本。

流程

  1. 红帽客户门户网站 下载最新版本的 Red Hat AMQ Streams Cruise Control 归档。
  2. 创建 /opt/cruise-control 目录:

    sudo mkdir /opt/cruise-control
    Copy to Clipboard Toggle word wrap
  3. 将 Cruise Control ZIP 文件的内容提取到新目录中:

    unzip amq-streams-y.y.y-cruise-control-bin.zip -d /opt/cruise-control
    Copy to Clipboard Toggle word wrap
  4. /opt/cruise-control 目录的所有权更改为 kafka 用户:

    sudo chown -R kafka:kafka /opt/cruise-control
    Copy to Clipboard Toggle word wrap

12.3. 部署 Cruise Control Metrics Reporter

在开始 Cruise Control 前,您必须将 Kafka 代理配置为使用提供的 Cruise Control Metrics Reporter。

在运行时加载时,Metrics Reporter 会将指标发送到 __CruiseControlMetrics 主题,其中有三个自动创建的主题之一。Cruise Control 使用这些指标来创建和更新工作负载模型,并计算优化建议。

先决条件

流程

对于 Kafka 集群中的每个代理,一次一个:

  1. 停止 Kafka 代理:

    /opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap
  2. 将 Cruise Control Metrics Reporter .jar 文件复制到 Kafka 库目录中:

    cp /opt/cruise-control/libs/cruise-control-metrics-reporter-y.y.yyy.redhat-0000x.jar /opt/kafka/libs
    Copy to Clipboard Toggle word wrap
  3. 在 Kafka 配置文件中 (/opt/kafka/config/server.properties) 配置 Cruise Control Metrics Reporter:

    1. CruiseControlMetricsReporter 类添加到 metric.reporters 配置选项。不要删除任何现有的指标报告器。

      metric.reporters=com.linkedin.kafka.cruisecontrol.metricsreporter.CruiseControlMetricsReporter
      Copy to Clipboard Toggle word wrap
    2. 在 Kafka 配置文件中添加以下配置选项和值:

      cruise.control.metrics.topic.auto.create=true
      cruise.control.metrics.topic.num.partitions=1
      cruise.control.metrics.topic.replication.factor=1
      Copy to Clipboard Toggle word wrap

      这些选项允许 Cruise Control Metrics Reporter 创建 __CruiseControlMetrics 主题,其日志清理策略为 DELETE。如需更多信息,请参阅 Auto-created topicsLog cleanup policy for Cruise Control Metrics topic

  4. 如果需要,配置 SSL。

    1. 在 Kafka 配置文件中(/opt/kafka/config/server.properties)通过设置相关的客户端配置属性在 Cruise Control Metrics Reporter 和 Kafka 代理之间配置 SSL。

      Metrics Reporter 接受带有 cruise.control.metrics.reporter 前缀的所有特定于标准制作者的配置属性。例如: cruise.control.metrics.reporter.ssl.truststore.password

    2. 在 Cruise Control 属性文件中(/opt/cruise-control/config/cruisecontrol.properties)通过设置相关的客户端配置属性在 Kafka 代理和 Cruise Control 服务器之间配置 SSL。

      Cruise Control 从 Kafka 中继承 SSL 客户端属性选项,并将这些属性用于所有 Cruise Control 服务器客户端。

  5. 重启 Kafka 代理:

    /opt/kafka/bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  6. 对剩余的代理重复步骤 1-5。

12.4. 配置并启动 Cruise Control

配置 Cruise Control 使用的属性,然后使用 cruise-control-start.sh 脚本启动 Cruise Control 服务器。服务器托管到整个 Kafka 集群的单个机器上。

Cruise Control 启动时会自动创建三个主题。如需更多信息,请参阅 自动创建的主题

先决条件

流程

  1. 编辑 Cruise Control 属性文件 (/opt/cruise-control/config/cruisecontrol.properties)。
  2. 配置以下示例配置中显示的属性:

    # The Kafka cluster to control.
    bootstrap.servers=localhost:9092 
    1
    
    
    # The replication factor of Kafka metric sample store topic
    sample.store.topic.replication.factor=2 
    2
    
    
    # The configuration for the BrokerCapacityConfigFileResolver (supports JBOD, non-JBOD, and heterogeneous CPU core capacities)
    #capacity.config.file=config/capacity.json
    #capacity.config.file=config/capacityCores.json
    capacity.config.file=config/capacityJBOD.json 
    3
    
    
    # The list of goals to optimize the Kafka cluster for with pre-computed proposals
    default.goals={List of default optimization goals} 
    4
    
    
    # The list of supported goals
    goals={list of master optimization goals} 
    5
    
    
    # The list of supported hard goals
    hard.goals={List of hard goals} 
    6
    
    
    # How often should the cached proposal be expired and recalculated if necessary
    proposal.expiration.ms=60000 
    7
    
    
    # The zookeeper connect of the Kafka cluster
    zookeeper.connect=localhost:2181 
    8
    Copy to Clipboard Toggle word wrap
    1
    Kafka 代理的主机和端口号(始终为端口 9092)。
    2
    Kafka 指标示例存储主题的复制因素。如果要在单节点 Kafka 和 ZooKeeper 集群中评估 Cruise Control,请将此属性设置为 1。对于生产环境,请将此属性设置为 2 或以上。
    3
    为代理资源设置最大容量限制的配置文件。使用适用于 Kafka 部署配置的文件。如需更多信息,请参阅 容量配置
    4
    使用完全限定域名(FQDN)的以逗号分隔的默认优化目标列表。很多 master 优化目标(请参阅 5)已设置为默认优化目标;如果需要,您可以添加或删除目标。如需更多信息,请参阅 第 12.5 节 “优化目标概述”
    5
    使用 FQDN 的逗号分隔列表 master 优化目标。要完全排除用于生成优化提议的目标,请将它们从列表中删除。更多信息请参阅 第 12.5 节 “优化目标概述”
    6
    使用 FQDN 以逗号分隔的硬目标列表。七个 master 优化目标已设置为硬目标;如果需要,您可以添加或删除目标。如需更多信息,请参阅 第 12.5 节 “优化目标概述”
    7
    刷新从默认优化目标生成的缓存的优化建议的时间间隔(以毫秒为单位)。更多信息请参阅 第 12.6 节 “优化提议概述”
    8
    ZooKeeper 连接的主机和端口号(始终端口 2181)。
  3. 启动 Cruise Control 服务器。默认情况下,服务器在端口 9092 上启动;(可选)指定不同的端口。

    cd /opt/cruise-control/
    ./bin/cruise-control-start.sh config/cruisecontrol.properties PORT
    Copy to Clipboard Toggle word wrap
  4. 要验证 Cruise Control 是否正在运行,请将 GET 请求发送到 Cruise Control 服务器的 /state 端点:

    curl 'http://HOST:PORT/kafkacruisecontrol/state'
    Copy to Clipboard Toggle word wrap
自动创建的主题

下表显示了在 Cruise Control 启动时自动创建的三个主题。Cruise Control 需要这些主题才能正常工作,且不得删除或更改。

Expand
表 12.1. 自动创建的主题
自动创建的主题创建人功能

__CruiseControlMetrics

Cruise Control Metrics Reporter

将 Metrics Reporter 中的原始指标存储在每个 Kafka 代理中。

__KafkaCruiseControlPartitionMetricSamples

Sything Control

存储每个分区的派生指标。它们由指标示例聚合器创建。

__KafkaCruiseControlModelTrainingSamples

Sything Control

存储用于创建 Cluster Workload Model 的指标样本。

要确保在自动创建的主题中禁用日志压缩,请确保配置 Cruise Control Metrics Reporter,如 第 12.3 节 “部署 Cruise Control Metrics Reporter” 所述。日志压缩可以删除 Cruise Control 所需的记录,并防止它正常工作。

12.5. 优化目标概述

要重新平衡 Kafka 集群,Cruise Control 使用优化目标来 生成优化建议。优化目标是在 Kafka 集群中重新发布工作负载和资源利用率的限制。

Red Hat Enterprise Linux 上的 AMQ Streams 支持在 Cruise Control 项目中开发的所有优化目标。支持的目标(以优先级默认降序排列)如下:

  1. 机架感知性
  2. 每个代理对一组主题的最小领导副本数
  3. 副本容量
  4. 容量:磁盘容量、网络入站容量、网络出站容量
  5. CPU 容量
  6. 副本分发
  7. 潜在的网络输出
  8. 资源分布:磁盘使用分发、网络入站使用分布、网络出站使用分布
  9. 领导字节速率分布
  10. 主题副本分发
  11. CPU 用量分布
  12. 领导副本分发
  13. 首选领导选举机制
  14. Kafka Assigner 磁盘用量发行版本
  15. intra-broker 磁盘容量
  16. intra-broker 磁盘用量

有关每个优化目标的更多信息,请参阅 Cruise Control Wiki 中的 目标

Cruise Control 属性文件中的目标配置

您可以在 cruise-control/config/ 目录中的 cruisecontrol.properties 文件中设置优化目标。有 优化目标的配置必须满足,以及 master默认优化目标

可选,用户提供的 优化目标是在运行时设置的,作为对 /rebalance 端点的请求中的参数。

优化目标取决于代理资源的任何 容量限制

以下小节更详细地描述了每个目标配置。

主优化目标

主优化目标可供所有用户使用。master 优化目标中没有列出的目标在 Cruise Control 操作中不可用。

以下 master 优化目标在 cruisecontrol.properties 文件中预先设置,在 goals 属性中以降序排列:

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal
Copy to Clipboard Toggle word wrap

为了简单起见,我们建议您不要更改预先设置的 master 优化目标,除非您需要完全排除一个或多个目标来生成优化方案。如果需要,可以在配置中修改 master 优化目标的优先级顺序,以实现默认优化目标。

如果您需要修改预先设置的 master 优化目标,请在 goals 属性中指定目标列表(按优先级降序排列)。使用 cruisecontrol.properties 文件中所示的完全限定域名。

您必须至少指定一个 master 目标,或者 Cruise Control 将会崩溃。

注意

如果更改了预先设置的 master 优化目标,您必须确保配置的 hard.goals 是您配置的 master 优化目标的子集。否则,在生成优化建议时会出现错误。

硬目标和软目标

硬目标是在优化提议时 必须满足 的目标。没有作为硬目标配置的目标被成为软目标。您可以将软目标视为 best effort 目标:它们不需要在优化建议方面满足,但包含在优化计算中。

Cruise Control 将计算满足所有硬目标以及尽可能多的软目标(按优先级顺序)的优化建议。满足所有硬目标的优化方法由 Analyzer 拒绝,不会向用户发送。

注意

例如,您可能有一个软目标来在集群间平均分配主题的副本(主题分布目标)。如果这样做可让所有配置的硬目标满足,则 Cruise Control 将忽略这个目标。

以下 master 优化目标在 cruisecontrol.properties 文件中预先设置为 hard 目标(在 hard.goals 属性中):

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal
Copy to Clipboard Toggle word wrap

要更改硬目标,请编辑 hard.goals 属性,并使用其完全限定域名指定所需的目标。

增加硬目标数量可减少 Cruise Control 计算并生成有效优化方案的可能性。

默认优化目标

Cruise Control 使用默认的优化目标 列表来生成 缓存的优化建议。更多信息请参阅 第 12.6 节 “优化提议概述”

您可以通过设置 用户提供的优化目标,在运行时覆盖默认优化目标。

以下默认优化目标在 cruisecontrol.properties 文件中预先设置,在 default.goals 属性中以降序排列:

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal
Copy to Clipboard Toggle word wrap

您必须至少指定一个默认目标,否则 Cruise Control 将会崩溃。

要修改默认优化目标,请在 default.goals 属性中指定目标列表(以降序排列)。默认目标必须是 master 优化目标的子集;使用完全限定域名。

用户提供的优化目标

用户提供的优化目标 会缩小为特定优化提议配置的默认目标。您可以根据需要将它们设置为 HTTP 请求到 /rebalance 端点的参数。更多信息请参阅 第 12.9 节 “生成优化建议”

用户提供的优化目标可以为不同的场景生成优化建议。例如,您可能想要在不考虑磁盘容量或磁盘利用率的情况下在 Kafka 集群中优化领导副本分布。因此,您将请求发送到 /rebalance 端点,其中包含一个用于领导副本分发的目标。

用户提供的优化目标必须:

要在优化提议中忽略配置的硬目标,请将 skip_hard_goals_check=true 参数添加到请求中。

其他资源

12.6. 优化提议概述

optimization proposal 是要生成一个更加均衡的 Kafka 集群、在代理中平均分配分区工作负载的建议概述。每个优化建议均基于一组用于生成它的 优化目标,受代理资源配置的任何容量限制

所有优化的提议都是对提议重新平衡的影响的估算。您可以批准或拒绝提议。

12.6.1. 批准或拒绝优化建议

优化提议摘要显示了所提议的更改范围。通过 Cruise Control API 对 HTTP 请求返回概述。

当您向 /rebalance 端点发出 POST 请求时,响应中会返回一个优化提议概述。

返回优化提议概述

curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
Copy to Clipboard Toggle word wrap

使用摘要决定是否批准或拒绝优化提议。

批准优化提议
您可以通过向 /rebalance 端点发出 POST 请求并将 dryrun 参数设置为 false 来批准优化提议(默认为 true)。Cruise Control 将提议应用到 Kafka 集群,并启动集群重新平衡操作。
拒绝优化方案
如果您选择不批准优化方案,您可以更改优化目标更新任何重新平衡性能调优选项,然后生成另一个提议。您可以在没有 dryrun 参数的情况下重新发送请求,以生成新的优化建议。

使用优化建议来评估重新平衡所需的移动。例如,优化提议描述了 inter-broker 和 intra-broker 移动。inter-broker 重新平衡在独立代理间移动数据。intra-broker 重新平衡可在同一代理上的磁盘之间移动数据。即使您没有提前并批准提议,此类信息也很有用。

提议还会显示迁移到不同代理的分区领导数。这需要对 ZooKeeper 配置进行更改,这对性能有低的影响。

因为在重新平衡时在 Kafka 集群中出现额外的负载,您可能会拒绝优化过程或延迟其批准。分区副本的交集移动对性能有严重影响。如果要移动的数据总量较大,您可以拒绝提议,或者在批准重新平衡来限制对 Kafka 集群性能的影响。

重新平衡性能调优选项有助于降低数据移动的影响。如果可扩展重新平衡周期,您可以将重新平衡分成较小的批处理。一次减少数据移动会减少集群的负载。

Balancedness score 是优化提议被批准前后 Kafka 集群的整体平衡度量。平衡分数基于优化目标。如果满足所有目标,则分数为 100。当一个目标不满足时,分数会降低。比较均衡分数,以查看 Kafka 集群是否低于重新平衡。

优化提议概述属性

下表描述了优化提议中包含的属性。

Expand
表 12.2. 优化提议概述中包含的属性
属性描述

n inter-broker replica (y MB) moves

n :将在独立代理之间移动的分区副本数量。

在重新平衡操作期间影响性能 :高。

y MB :将移动到独立代理的每个分区副本的大小总和。

在重新平衡操作期间影响性能 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。

n intra-broker replica (y MB) moves

n :集群代理磁盘之间传输的分区副本数量。

重新平衡操作期间的性能影响 : 高,但少于 inter-broker 副本移动

y MB :将在同一代理的磁盘之间移动的每个分区副本的大小总和。

在重新平衡操作期间影响性能 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。在同一代理的磁盘间移动大量数据比独立代理之间的影响较低(请参阅 inter-broker replica moves)。

n 排除主题

优化建议中分区副本/领导移动计算以外的主题数量。

您可以使用以下方法之一排除主题:

cruisecontrol.properties 文件中指定 topics.excluded.from.partition.movement 属性中的正则表达式。

在对 /rebalance 端点的 POST 请求中,在 excluded_topics 参数中指定正则表达式。

与正则表达式匹配的主题列在响应中,并将在集群重新平衡中排除。

N 领导移动

n :其领导要切换到不同副本的分区数量。这涉及更改 ZooKeeper 配置。

在重新平衡操作期间影响性能 :低.

n 最近的窗口

n :优化提议的指标窗口数量。

N% 的分区覆盖

n%: 优化建议涵盖的 Kafka 集群中分区的百分比。

On-demand Balancedness Score Before (nn.yyy) After (nn.yyy)

Kafka 集群的整体平衡的测量。

Cruise Control 根据多个因素(目标在 default.goal 或用户提供的目标列表中,为每一个优化目标分配了一个 Balancedness Score)。按需保证分数的计算方式为:从 100 中减去每个违反的软目标 Balancedness Score 的总和。

Before score 基于 Kafka 集群的当前配置。After 分数基于生成的优化提议。

缓存的优化方案

Cruise Control 根据配置的默认优化目标维护缓存的优化建议。从工作负载模型生成,缓存的优化方案每 15 分钟更新一次,以反映 Kafka 集群的当前状态。

当使用以下目标配置时,返回最新缓存的优化方案:

  • 默认优化目标
  • 用户提供的优化目标,可在当前缓存的提议中满足

要更改缓存的优化提议刷新间隔,请编辑 cruisecontrol.properties 文件中的 proposal.expiration.ms 设置。考虑快速更改集群的间隔较短,尽管这会在 Cruise Control 服务器上增加负载。

12.7. 重新平衡性能调优概述

您可以调整集群重新平衡的几个性能调优选项。这些选项控制如何执行重新平衡中的分区副本和领导移动,以及分配给重新平衡操作的带宽。

分区重新分配命令

优化建议 由单独的分区重新分配命令组成。当您启动提议时,Cruise Control 服务器会将这些命令应用到 Kafka 集群。

分区重新分配命令由以下一种操作组成:

  • 分区移动 :使分区副本及其数据传输到新位置。分区移动可以采用两种形式之一:

    • inter-broker movement :分区副本被移到不同代理上的日志目录中。
    • intra-broker movement :分区副本被移到同一代理的不同日志目录中。
  • 领导移动 :尝试切换分区副本的领导。

Cruise Control 在批处理中向 Kafka 集群发出分区重新分配命令。重新平衡期间集群的性能会受到每个批处理中包含的每种移动数量的影响。

要配置分区重新分配命令,请参阅重新平衡调整选项

副本移动策略

集群重新平衡性能也会受到 副本移动策略的影响,该策略应用于分区重新分配命令的批处理。默认情况下,Cruise Control 使用 BaseReplicaMovementStrategy,它按照生成顺序应用命令。但是,如果提议的早期有一些非常大的分区重新分配,则此策略可能会减慢其他重新分配的应用程序。

Cruise Control 提供了三种替代副本移动策略,可用于优化提议:

  • PrioritizeSmallReplicaMovementStrategy: Order reassignments 以升序大小为单位。
  • PrioritizeLargeReplicaMovementStrategy: Order reassignments 以降序排列。
  • PostponeUrpReplicaMovementStrategy: 优先考虑为没有处于不同步状态的分区的服务的重新分配。

这些策略可以配置为序列。第一个策略尝试使用其内部逻辑比较两个分区重新分配。如果重新分配等同于,那么它将按顺序传递给下一个策略,以确定顺序等。

要配置副本移动策略,请参阅重新平衡调整选项

重新平衡调整选项

Cruise Control 提供多个配置选项用于调优重新平衡参数。这些选项通过以下方式设置:

  • 作为属性,在 cruisecontrol.properties 文件中默认的 Cruise Control 配置中
  • 作为 POST 请求中的参数到 /rebalance 端点

下表总结了这两种方法的相关配置。

Expand
表 12.3. 重新平衡性能调优配置
Cruise Control 属性KafkaRebalance 参数默认描述

num.concurrent.partition.movements.per.broker

concurrent_partition_movements_per_broker

5

每个分区重新分配批处理中的最大 inter-broker 分区移动数

num.concurrent.intra.broker.partition.movements

concurrent_intra_broker_partition_movements

2

每个分区重新分配批处理中的最大 intra-broker 分区移动数

num.concurrent.leader.movements

concurrent_leader_movements

1000

每个分区重新分配批处理中的最大分区领导更改数

default.replication.throttle

replication_throttle

null (无限制)

分配给分区重新分配的带宽(每秒字节数)

default.replica.movement.strategies

replica_movement_strategies

BaseReplicaMovementStrategy

用于决定为生成的提议执行分区重新分配命令的顺序(优先级顺序)的列表。有三个策略: PrioritizeSmallReplicaMovementStrategy,PrioritizeLargeReplicaMovementStrategyPostponeUrpReplicaMovementStrategy。对于 server 设置,请使用带有策略类的完全限定名称的列表(将 com.linkedin.kafka.cruisecontrol.executor.strategy. to the each class name 的开始)。对于重新平衡参数,请使用副本移动策略的类名称的逗号分隔列表。

更改默认设置会影响重新平衡完成所需的时间,以及重新平衡期间在 Kafka 集群上放置的负载。使用较低值可减少负载,但会增加所花费的时间,反之亦然。

其他资源

  • Cruise Control Wiki 中的配置
  • Cruise Control Wiki 中的 REST API

12.8. Cruise Control 配置

config/cruisecontrol.properties 文件包含 Cruise Control 的配置。该文件由以下类型之一属性组成:

  • 字符串
  • Number
  • 布尔值

您可以指定并配置 Cruise Control Wiki 的 Configurations 部分中列出的所有属性。

容量配置

Cruise Control 使用 容量限制 来确定某些基于资源的优化目标是否被破坏。如果将一个或多个基于资源的目标设置为硬目标,则尝试优化会失败,然后中断。这可防止优化用于生成优化建议。

您可以在 cruise-control/config 中的以下三个 .json 文件中为 Kafka 代理资源指定容量限制:

  • capacityJBOD.json :用于 JBOD Kafka 部署(默认文件)。
  • capacity.json: 用于非JBOD Kafka 部署,每个代理都有相同的 CPU 内核数。
  • capacityCores.json: 用于在每个代理都有不同 CPU 内核数的非JBOD Kafka 部署中使用。

cruisecontrol.properties 中的 capacity.config.file 属性中设置文件。所选文件将用于代理容量解析。例如:

capacity.config.file=config/capacityJBOD.json
Copy to Clipboard Toggle word wrap

可以在上述单元中为以下代理资源设置容量限制:

  • DISK :以 MB 为单位的磁盘存储
  • CPU: CPU 使用率为百分比(0-100)或内核数
  • NW_IN :入站网络吞吐量(KB 每秒)
  • NW_OUT :出站网络吞吐量(KB 每秒)

要将相同的容量限制应用到由 Cruise Control 监控的每个代理,请为代理 ID -1 设置容量限制。要为单个代理设置不同的容量限制,请指定每个代理 ID 及其容量配置。

容量限制配置示例

{
  "brokerCapacities":[
    {
      "brokerId": "-1",
      "capacity": {
        "DISK": "100000",
        "CPU": "100",
        "NW_IN": "10000",
        "NW_OUT": "10000"
      },
      "doc": "This is the default capacity. Capacity unit used for disk is in MB, cpu is in percentage, network throughput is in KB."
    },
    {
      "brokerId": "0",
      "capacity": {
        "DISK": "500000",
        "CPU": "100",
        "NW_IN": "50000",
        "NW_OUT": "50000"
      },
      "doc": "This overrides the capacity for broker 0."
    }
  ]
}
Copy to Clipboard Toggle word wrap

如需更多信息,请参阅 Cruise Control Wiki 中的填充 容量配置文件。

Cruise Control Metrics 主题的日志清理策略

非常重要的一点是,自动创建的 __CruiseControlMetrics 主题(请参阅额 auto-created topics)有一个日志清理策略 DELETE 而不是 COMPACT。否则,Cruise Control 所需的记录可能会被删除。

第 12.3 节 “部署 Cruise Control Metrics Reporter” 所述,在 Kafka 配置文件中设置以下选项可确保 COMPACT 日志清理策略被正确设置:

  • cruise.control.metrics.topic.auto.create=true
  • cruise.control.metrics.topic.num.partitions=1
  • cruise.control.metrics.topic.replication.factor=1

如果在 Cruise Control Metrics Reporter 中的主题自动创建为 disabledcruise.control.metrics.topic.auto.create=false),但在 Kafka 集群中是 enabled__CruiseControlMetrics 主题仍然由代理自动创建。在这种情况下,您必须使用 kafka-configs.sh 工具将 __CruiseControlMetrics 主题的日志清理策略改为 DELETE

  1. 获取 __CruiseControlMetrics 主题的当前配置:

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name __CruiseControlMetrics --describe
    Copy to Clipboard Toggle word wrap
  2. 在主题配置中更改日志清理策略:

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name __CruiseControlMetrics --alter --add-config cleanup.policy=delete
    Copy to Clipboard Toggle word wrap

如果在 Cruise Control Metrics Reporter Kafka 集群中都 禁用了 主题自动创建,则必须手动创建 __CruiseControlMetrics 主题,然后使用 kafka-configs.sh 工具将它配置为使用 DELETE 日志清理策略。

更多信息请参阅 第 5.9 节 “修改主题配置”

日志记录配置

Cruise Control 将 log4j1 用于所有服务器日志记录。要更改默认配置,请编辑 /opt/cruise-control/config/log4j.properties 文件中的 log4j.properties 文件。

在更改生效前,您必须重启 Cruise Control 服务器。

12.9. 生成优化建议

当您向 /rebalance 端点发出 POST 请求时,Cruise Control 会根据提供的优化目标生成一个优化建议来重新平衡 Kafka 集群。

优化建议作为空运行方式生成,除非提供了 dryrun 参数,并将其设置为 false。在"dry run mode"中,Cruise Control 会生成优化建议和估算结果,但不通过重新平衡集群来启动提议。

您可以分析优化提议中返回的信息,并决定是否启动它。

以下是对 /rebalance 端点的请求的关键参数。有关所有可用参数的详情,请参考 Cruise Control Wiki 中的 REST API

dryRun

type: boolean, default: true

告知 Cruise 控制是否只生成优化提议(true),或生成优化建议并执行集群重新平衡 (false)。

dryrun=true (默认值)时,您还可以传递 verbose 参数,以返回有关 Kafka 集群状态的更多详细信息。这包括应用优化提议前后每个 Kafka 代理上负载的指标,以及 before 和 after 值之间的区别。

excluded_topics

类型: regex

与优化提议的计算中排除的主题匹配的正则表达式。

目标

type: 字符串列表,默认为配置的 default.goals 列表

用户提供的优化目标列表,用于准备优化方法。如果没有提供目标,则会使用 cruisecontrol.properties 文件中配置的 default.goals 列表。

skip_hard_goals_check

type: boolean, default: false

默认情况下,Cruise Control 会检查用户提供的优化目标(在 goals 参数中)包含所有配置的硬目标(在 hard.goals中)。如果您提供不是配置的 hard.goals 子集的目标,请求会失败。

如果要生成不使用所有配置的 hard.goals 优化目标,则将 skip_hard_goals_check 设置为 true

json

type: boolean, default: false

控制 Cruise Control 服务器返回的响应类型。如果没有提供,或设置为 false,Cruise Control 会返回格式的文本,以便在命令行上显示。如果要以编程方式提取返回的信息元素,请设置 json=true。这将返回 JSON 格式的文本,这些文本可以传送到 jq 等工具,或在脚本和程序中解析它们。

详细

type: boolean, default: false

控制 Cruise Control 服务器返回的响应中详情级别。可与 dryrun=true 一起使用。

先决条件

  • Kafka 和 ZooKeeper 正在运行
  • Cruise Control 正在运行

流程

  1. 要生成为控制台格式化的 "dry run" 优化提议,请将 POST 请求发送到 /rebalance 端点。

    • 使用配置的 default.goals

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
      Copy to Clipboard Toggle word wrap

      缓存的优化提议会立即返回。

      注意

      如果返回 NotEnoughValidWindows,Cruise Control 尚未记录足够的指标数据,以生成优化器。等待几分钟,然后重新发送请求。

    • 要指定用户提供的优化目标,而不是配置的 default.goals,在 goals 参数中提供一个或多个目标:

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal'
      Copy to Clipboard Toggle word wrap

      如果满足提供的目标,则立即返回缓存的优化方案。否则,会使用提供的目标生成新的优化方案;这需要更长的时间来计算。您可以通过在请求中添加 ignore_proposal_cache=true 参数来强制实施此行为。

    • 要指定用户提供的优化目标,它们不包括所有配置的硬目标,请将 skip_hard_goal_check=true 参数添加到请求中:

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal,ReplicaDistributionGoal&skip_hard_goal_check=true'
      Copy to Clipboard Toggle word wrap
  2. 查看响应中包含的优化提议。属性描述待处理的集群重新平衡操作。

    提议包含所提出优化的高级概述,以及各个默认优化目标的总结,以及执行过程后的预期集群状态。

    请特别注意以下信息:

    • 重新平衡概述后集群负载。如果满足您的要求,您应该使用高级别概述来评估所提议更改的影响。
    • n inter-broker replica (y MB) moves 表示在代理间移动的数据量。值越大,重新平衡过程中对 Kafka 集群的潜在性能影响越大。
    • n intra-broker replica (y MB) moves 表示代理本身(生成磁盘)中多少数据。数值越大,对各个代理的潜在性能影响越大(尽管小于 n inter-broker replica (y MB) moves)。
    • 领导机移动的数量。这在重新平衡过程中对集群的性能有可忽略的影响。
异步响应

默认情况下,Cruise Control REST API 端点会在 10 秒后超时,虽然提议生成将继续在服务器上。如果最新缓存的优化器尚未就绪,或者用户提供的优化目标是通过 ignore_proposal_cache=true 指定,则可能会出现超时。

要允许您稍后检索优化过程,请记录请求的唯一标识符,该标识符在 /rebalance 端点的响应标头中提供。

要使用 curl 获取响应,请指定 verbose (-v)选项:

curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
Copy to Clipboard Toggle word wrap

以下是一个标头示例:

* Connected to cruise-control-server (::1) port 9090 (#0)
> POST /kafkacruisecontrol/rebalance HTTP/1.1
> Host: cc-host:9090
> User-Agent: curl/7.70.0
> Accept: /
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 01 Jun 2020 15:19:26 GMT
< Set-Cookie: JSESSIONID=node01wk6vjzjj12go13m81o7no5p7h9.node0; Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< User-Task-ID: 274b8095-d739-4840-85b9-f4cfaaf5c201
< Content-Type: text/plain;charset=utf-8
< Cruise-Control-Version: 2.0.103.redhat-00002
< Cruise-Control-Commit_Id: 58975c9d5d0a78dd33cd67d4bcb497c9fd42ae7c
< Content-Length: 12368
< Server: Jetty(9.4.26.v20200117-redhat-00001)
Copy to Clipboard Toggle word wrap

如果优化提议在超时时间内没有就绪,您可以重新提交 POST 请求,这一次包括标头中原始请求的 User-Task-ID

curl -v -X POST -H 'User-Task-ID: 274b8095-d739-4840-85b9-f4cfaaf5c201' 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
Copy to Clipboard Toggle word wrap

12.10. 启动集群重新平衡

如果您对优化建议满意,您可以指示 Cruise Control 启动集群重新平衡并开始重新分配分区,如提议中所述。

在生成优化提议并启动集群重新平衡之间尽可能少的时间。如果因为您生成了原始优化提议,集群状态可能会改变。因此,启动的集群重新平衡可能与您检查的不同。如果有疑问,首先要生成新的优化方案。

一个集群会重新平衡,状态为"Active",一次才能进行。

先决条件

流程

  1. 要执行最近生成的优化方案,请使用 dryrun=false 参数向 /rebalance 端点发送 POST 请求:

    curl -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?dryrun=false'
    Copy to Clipboard Toggle word wrap

    Cruise Control 启动集群重新平衡并返回优化建议。

  2. 检查优化提议中总结的更改。如果更改不是您期望的 ,您可以停止重新平衡
  3. 使用 /user_tasks 端点检查集群重新平衡的进度。集群重新平衡状态为 "Active"。

    查看 Cruise Control 服务器上执行的所有集群重新平衡任务:

    curl 'cruise-control-server:9090/kafkacruisecontrol/user_tasks'
    
    USER TASK ID      CLIENT ADDRESS  START TIME     STATUS  REQUEST URL
    c459316f-9eb5-482f-9d2d-97b5a4cd294d  0:0:0:0:0:0:0:1       2020-06-01_16:10:29 UTC  Active      POST /kafkacruisecontrol/rebalance?dryrun=false
    445e2fc3-6531-4243-b0a6-36ef7c5059b4  0:0:0:0:0:0:0:1       2020-06-01_14:21:26 UTC  Completed   GET /kafkacruisecontrol/state?json=true
    05c37737-16d1-4e33-8e2b-800dee9f1b01  0:0:0:0:0:0:0:1       2020-06-01_14:36:11 UTC  Completed   GET /kafkacruisecontrol/state?json=true
    aebae987-985d-4871-8cfb-6134ecd504ab  0:0:0:0:0:0:0:1       2020-06-01_16:10:04 UTC
    Copy to Clipboard Toggle word wrap
  4. 要查看特定集群重新平衡任务的状态,请提供 user-task-ids 参数和任务 ID:

    curl 'cruise-control-server:9090/kafkacruisecontrol/user_tasks?user_task_ids=c459316f-9eb5-482f-9d2d-97b5a4cd294d'
    Copy to Clipboard Toggle word wrap

12.11. 停止活跃的集群重新平衡

您可以停止当前正在进行的集群重新平衡。

这指示 Cruise Control 完成当前分区重新分配的批处理,然后停止重新平衡。当重新平衡停止后,已完成的分区重新分配已被应用;因此,与重新平衡操作开始前,Kafka 集群的状态会有所不同。如果需要进一步重新平衡,您应该生成新的优化方案。

注意

在 intermediate(停止)状态中的 Kafka 集群的性能可能比初始状态更糟。

先决条件

  • 集群重新平衡正在进行(由状态"Active")指定。

流程

  • 发送 POST 请求到 /stop_proposal_execution 端点:

    curl -X POST 'cruise-control-server:9090/kafkacruisecontrol/stop_proposal_execution'
    Copy to Clipboard Toggle word wrap

第 13 章 分布式追踪

分布式追踪允许您跟踪分布式系统中的应用程序间事务的进度。在微服务架构中,追踪跟踪服务间事务的进度。跟踪数据对于监控应用程序性能和目标系统和最终用户应用程序的问题非常有用。

在 Red Hat Enterprise Linux 上的 AMQ Streams 中,追踪有助于对消息的端到端跟踪:从源系统到 Kafka,然后从 Kafka 到目标系统和应用程序。追踪补充可用的 JMX 指标

AMQ Streams 如何支持追踪

为以下客户端和组件提供了追踪支持。

Kafka 客户端:

  • Kafka 生成者和消费者
  • Kafka Streams API 应用程序

Kafka 组件:

  • Kafka Connect
  • Kafka Bridge
  • MirrorMaker
  • MirrorMaker 2.0

要启用追踪,您需要执行四个高级别任务:

  1. 启用 Jaeger tracer。
  2. 启用 Interceptors:

  3. 设置 追踪环境变量
  4. 部署客户端或组件。

在检测程序时,客户端会生成 trace 数据。例如,当生成消息或向日志写入偏移时。

trace 根据抽样策略进行抽样,然后在 Jaeger 用户界面中视觉化。

注意

Kafka 代理不支持追踪。

为 AMQ Streams 之外的应用程序和系统设置追踪超出了本章的讨论范围。要了解有关此主题的更多信息,请在 OpenTracing 文档 中搜索"注入和提取"。

流程概述

要为 AMQ Streams 设置追踪,请按照以下步骤执行:

先决条件

  • Jaeger 后端组件部署到 Kubernetes 集群中。有关部署说明,请参阅 Jaeger 文档

13.1. OpenTracing 和 Jaeger 概述

AMQ Streams 使用 OpenTracing 和 Jaeger 项目。

OpenTracing 是一种 API 规范,独立于追踪或监控系统。

  • OpenTracing API 用于检测 应用程序代码
  • 检测的应用程序为分布式系统间的独立事务生成 trace
  • 跟踪由 范围 组成,用于定义一段时间内的特定工作单元

Jaeger 是基于微服务的分布式系统的追踪系统。

  • Jaeger 实现 OpenTracing API,并为工具提供客户端库
  • Jaeger 用户界面允许您查询、过滤和分析 trace 数据

A simple query in the Jaeger user interface

其他资源

13.2. 为 Kafka 客户端设置追踪

初始化 Jaeger tracer 以检测您的客户端应用程序以进行分布式追踪。

13.2.1. 为 Kafka 客户端初始化 Jaeger tracer

使用一组 追踪环境变量 配置并初始化 Jaeger tracer。

流程

在每个客户端应用程序中:

  1. 将 Jaeger 的 Maven 依赖项添加到客户端应用程序的 pom.xml 文件中:

    <dependency>
        <groupId>io.jaegertracing</groupId>
        <artifactId>jaeger-client</artifactId>
        <version>1.5.0.redhat-00001</version>
    </dependency>
    Copy to Clipboard Toggle word wrap
  2. 使用 追踪环境变量 定义 Jaeger tracer 的配置。
  3. 从在第 2 步中定义的环境变量创建 Jaeger tracer:

    Tracer tracer = Configuration.fromEnv().getTracer();
    Copy to Clipboard Toggle word wrap
    注意

    有关初始化 Jaeger tracer 的替代方法,请参阅 Java OpenTracing 库 文档。

  4. 将 Jaeger tracer 注册为全局 tracer:

    GlobalTracer.register(tracer);
    Copy to Clipboard Toggle word wrap

现在,会初始化 Jaeger tracer 供客户端应用程序使用。

13.2.2. 用于追踪的制作者和消费者的工具

使用 Decorator 模式或 Interceptors 检测您的 Java 生成者和消费者应用程序代码以进行追踪。

流程

在每个制作者和消费者应用程序的应用程序代码中:

  1. 将 OpenTracing 的 Maven 依赖项添加到制作者或消费者的 pom.xml 文件中。

    <dependency>
        <groupId>io.opentracing.contrib</groupId>
        <artifactId>opentracing-kafka-client</artifactId>
        <version>0.1.15.redhat-00004</version>
    </dependency>
    Copy to Clipboard Toggle word wrap
  2. 使用 Decorator 模式或 Interceptors 检测您的客户端应用程序代码。

    • 使用 Decorator 模式:

      // Create an instance of the KafkaProducer:
      KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);
      
      // Create an instance of the TracingKafkaProducer:
      TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
              tracer);
      
      // Send:
      tracingProducer.send(...);
      
      // Create an instance of the KafkaConsumer:
      KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);
      
      // Create an instance of the TracingKafkaConsumer:
      TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
              tracer);
      
      // Subscribe:
      tracingConsumer.subscribe(Collections.singletonList("messages"));
      
      // Get messages:
      ConsumerRecords<Integer, String> records = tracingConsumer.poll(1000);
      
      // Retrieve SpanContext from polled record (consumer side):
      ConsumerRecord<Integer, String> record = ...
      SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
      Copy to Clipboard Toggle word wrap
    • 使用 Interceptors:

      // Register the tracer with GlobalTracer:
      GlobalTracer.register(tracer);
      
      // Add the TracingProducerInterceptor to the sender properties:
      senderProps.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG,
                TracingProducerInterceptor.class.getName());
      
      // Create an instance of the KafkaProducer:
      KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);
      
      // Send:
      producer.send(...);
      
      // Add the TracingConsumerInterceptor to the consumer properties:
      consumerProps.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
                TracingConsumerInterceptor.class.getName());
      
      // Create an instance of the KafkaConsumer:
      KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);
      
      // Subscribe:
      consumer.subscribe(Collections.singletonList("messages"));
      
      // Get messages:
      ConsumerRecords<Integer, String> records = consumer.poll(1000);
      
      // Retrieve the SpanContext from a polled message (consumer side):
      ConsumerRecord<Integer, String> record = ...
      SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
      Copy to Clipboard Toggle word wrap
Decorator 模式中的自定义范围名称

span 是 Jaeger 中的逻辑工作单元,带有操作名称、开始时间和持续时间。

要使用 Decorator 模式来检测制作者和消费者应用程序,请在创建 TracingKafkaProducerTracingKafkaConsumer 对象时传递 BiFunction 对象来定义自定义范围名称。OpenTracing Apache Kafka 客户端调用库包括几个内置范围名称。

示例:使用自定义范围名称来在 Decorator 模式中检测客户端应用程序代码

// Create a BiFunction for the KafkaProducer that operates on (String operationName, ProducerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ProducerRecord, String> producerSpanNameProvider =
    (operationName, producerRecord) -> "CUSTOM_PRODUCER_NAME";

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer,
        producerSpanNameProvider);

// Spans created by the tracingProducer will now have "CUSTOM_PRODUCER_NAME" as the span name.

// Create a BiFunction for the KafkaConsumer that operates on (String operationName, ConsumerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ConsumerRecord, String> consumerSpanNameProvider =
    (operationName, consumerRecord) -> operationName.toUpperCase();

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer, passing in the consumerSpanNameProvider BiFunction:

TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer,
        consumerSpanNameProvider);

// Spans created by the tracingConsumer will have the operation name as the span name, in upper-case.
// "receive" -> "RECEIVE"
Copy to Clipboard Toggle word wrap

内置范围名称

在定义自定义 span 名称时,您可以在 ClientSpanNameProvider 类中使用以下 BiFunctions。如果没有指定 spanNameProvider,则使用 CONSUMER_OPERATION_NAMEPRODUCER_OPERATION_NAME

Expand
表 13.1. 用于定义自定义范围名称的 BiFunctions
BiFunction描述

CONSUMER_OPERATION_NAME, PRODUCER_OPERATION_NAME

返回 operationName 作为范围名称: "receive" (消费者)和 "send" for producers。

CONSUMER_PREFIXED_OPERATION_NAME (String prefix), PRODUCER_PREFIXED_OPERATION_NAME (String prefix)

返回 前缀和 operationName 的字符串串联。

CONSUMER_TOPIC, PRODUCER_TOPIC

返回消息发送到或从中检索的主题名称,格式为 (record.topic ())

PREFIXED_CONSUMER_TOPIC (String prefix), PREFIXED_PRODUCER_TOPIC (String prefix)

返回前缀和主题名称 (record.topic () )的字符串串联。

CONSUMER_OPERATION_NAME_TOPIC, PRODUCER_OPERATION_NAME_TOPIC

返回操作名称和主题名称:" operationName - record.topic ()"

CONSUMER_PREFIXED_OPERATION_NAME_TOPIC (String prefix), PRODUCER_PREFIXED_OPERATION_NAME_TOPIC (String prefix)

返回 前缀和 "operationName - record.topic ()" 的字符串串联。

13.2.3. 为追踪检测 Kafka Streams 应用程序

使用供应商接口为分布式追踪检测 Kafka Streams 应用程序。这会在应用程序中启用 Interceptors。

流程

在每个 Kafka Streams 应用程序中:

  1. opentracing-kafka-streams 依赖项添加到 Kafka Streams 应用程序的 pom.xml 文件中。

    <dependency>
        <groupId>io.opentracing.contrib</groupId>
        <artifactId>opentracing-kafka-streams</artifactId>
        <version>0.1.15.redhat-00004</version>
    </dependency>
    Copy to Clipboard Toggle word wrap
  2. 创建 TracingKafkaClientSupplier 供应商接口的实例:

    KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);
    Copy to Clipboard Toggle word wrap
  3. KafkaStreams 提供供应商接口:

    KafkaStreams streams = new KafkaStreams(builder.build(), new StreamsConfig(config), supplier);
    streams.start();
    Copy to Clipboard Toggle word wrap

13.3. 为 MirrorMaker 和 Kafka Connect 设置追踪

本节论述了如何为分布式追踪配置 MirrorMaker、MirrorMaker 2.0 和 Kafka Connect。

您必须为每个组件启用 Jaeger tracer。

13.3.1. 为 MirrorMaker 启用追踪

通过将 Interceptor 属性作为消费者和制作者配置参数传递,为 MirrorMaker 启用分布式追踪。

消息从源集群追踪到目标集群。跟踪数据记录消息进入和离开 MirrorMaker 组件。

流程

  1. 配置并启用 Jaeger tracer。
  2. 编辑 /opt/kafka/config/consumer.properties 文件。

    添加以下 Interceptor 属性:

    consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor
    Copy to Clipboard Toggle word wrap
  3. 编辑 /opt/kafka/config/producer.properties 文件。

    添加以下 Interceptor 属性:

    producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
    Copy to Clipboard Toggle word wrap
  4. 使用消费者和制作者配置文件作为参数启动 MirrorMaker:

    su - kafka
    /opt/kafka/bin/kafka-mirror-maker.sh --consumer.config /opt/kafka/config/consumer.properties --producer.config /opt/kafka/config/producer.properties --num.streams=2
    Copy to Clipboard Toggle word wrap

13.3.2. 为 MirrorMaker 2.0 启用追踪

通过在 MirrorMaker 2.0 属性文件中定义 Interceptor 属性,为 MirrorMaker 2.0 启用分布式追踪。

信息在 Kafka 集群之间追踪。trace 数据记录进入和离开 MirrorMaker 2.0 组件的消息。

流程

  1. 配置并启用 Jaeger tracer。
  2. 编辑 MirrorMaker 2.0 配置文件 ./config/connect-mirror-maker.properties,并添加以下属性:

    header.converter=org.apache.kafka.connect.converters.ByteArrayConverter 
    1
    
    consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor 
    2
    
    producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
    Copy to Clipboard Toggle word wrap
    1
    防止 Kafka Connect 将消息标头(包含 trace ID)转换为 base64 编码。这样可确保在源和目标集群中消息都相同。
    2
    为 MirrorMaker 2.0 启用 Interceptors。
  3. 使用 第 8.7 节 “使用 MirrorMaker 2.0 在 Kafka 集群间同步数据” 中的说明启动 MirrorMaker 2.0。

13.3.3. 为 Kafka Connect 启用追踪

使用配置属性为 Kafka Connect 启用分布式追踪。

只有 Kafka Connect 本身生成和使用的消息才会被 traced。要跟踪 Kafka Connect 和外部系统之间发送的消息,您必须在连接器中为这些系统配置追踪。

流程

  1. 配置并启用 Jaeger tracer。
  2. 编辑相关的 Kafka Connect 配置文件。

    • 如果您以独立模式运行 Kafka 连接,请编辑 /opt/kafka/config/connect-standalone.properties 文件。
    • 如果您以分布式模式运行 Kafka Connect,请编辑 /opt/kafka/config/connect-distributed.properties 文件。
  3. 在配置文件中添加以下属性:

    producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
    consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor
    Copy to Clipboard Toggle word wrap
  4. 保存配置文件。
  5. 设置追踪环境变量,然后在独立或分布式模式下运行 Kafka Connect。

Kafka Connect 的内部使用者和制作者中的 Interceptors 现在被启用。

13.4. 为 Kafka Bridge 启用追踪

通过编辑 Kafka Bridge 配置文件为 Kafka Bridge 启用分布式追踪。然后,您可以部署一个 Kafka Bridge 实例,它配置为分布式追踪到主机操作系统。

在以下情况下生成 trace:

  • Kafka Bridge 将信息发送到 HTTP 客户端,并消耗来自 HTTP 客户端的信息
  • HTTP 客户端通过 Kafka Bridge 发送 HTTP 请求来发送和接收信息

要进行端到端追踪,您必须在 HTTP 客户端中配置追踪。

流程

  1. 编辑 Kafka Bridge 安装目录中的 config/application.properties 文件。

    从以下行中删除代码注释:

    bridge.tracing=jaeger
    Copy to Clipboard Toggle word wrap
  2. 保存配置文件。
  3. 使用配置属性作为参数运行 bin/kafka_bridge_run.sh 脚本:

    cd kafka-bridge-0.xy.x.redhat-0000x
    ./bin/kafka_bridge_run.sh --config-file=config/application.properties
    Copy to Clipboard Toggle word wrap

    Kafka Bridge 的内部使用者和制作者中的 Interceptors 现在被启用。

13.5. 用于追踪的环境变量

在为 Kafka 客户端和组件配置 Jaeger tracer 时使用这些环境变量。

注意

追踪环境变量是 Jaeger 项目的一部分,可能随时更改。有关最新环境变量,请参阅 Jaeger 文档

Expand
表 13.2. Jaeger tracer 环境变量
属性必需Description

JAEGER_SERVICE_NAME

Jaeger tracer 服务的名称。

JAEGER_AGENT_HOST

通过用户数据报协议(UDP)与 jaeger-agent 通信的主机名。

JAEGER_AGENT_PORT

用于通过 UDP 与 jaeger-agent 通信的端口。

JAEGER_ENDPOINT

trace 端点。只有客户端应用程序将绕过 jaeger-agent 并直接连接到 jaeger-collector 时,才定义此变量。

JAEGER_AUTH_TOKEN

要作为 bearer 令牌发送到端点的身份验证令牌。

JAEGER_USER

如果使用基本身份验证,要发送到端点的用户名。

JAEGER_PASSWORD

如果使用基本身份验证,则要发送到端点的密码。

JAEGER_PROPAGATION

用于传播 trace 上下文的以逗号分隔的格式列表。默认为标准 Jaeger 格式。有效值为 jaegerb3

JAEGER_REPORTER_LOG_SPANS

指明报告程序是否还应记录 span。

JAEGER_REPORTER_MAX_QUEUE_SIZE

reporter 的最大队列大小。

JAEGER_REPORTER_FLUSH_INTERVAL

reporter 的 flush 间隔(以 ms 为单位)。定义 Jaeger reporter flushes 跨越批处理的频率。

JAEGER_SAMPLER_TYPE

用于客户端追踪的抽样策略:

  • 常数
  • probabilistic
  • 速率限制
  • remote (默认)

要对所有 trace 进行抽样,使用带有参数 1 的 Constant 抽样策略。

有关 Jaeger 架构和客户端抽样配置参数的概述,请参阅 Jaeger 文档

JAEGER_SAMPLER_PARAM

sampler 参数(数字)。

JAEGER_SAMPLER_MANAGER_HOST_PORT

如果选择了 Remote sampling 策略,要使用的主机名和端口。

JAEGER_TAGS

以逗号分隔的 tracer 级别标签列表,它们被添加到所有报告的 span 中。

该值也可以使用 ${envVarName:default} 格式来引用环境变量。:default 是可选的,并在无法找到环境变量时标识要使用的值。

第 14 章 Kafka Exporter

Kafka Exporter 是一个开源项目,用于增强对 Apache Kafka 代理和客户端的监控。

Kafka Exporter 由 AMQ Streams 提供,以使用 Kafka 集群部署,从与偏移、消费者组、消费者滞后和主题相关的 Kafka 代理提取额外的指标数据。

例如,使用指标数据来帮助识别速度较慢的用户。

lag 数据作为 Prometheus 指标公开,然后可在 Grafana 中显示这些指标数据进行分析。

如果您已经使用 Prometheus 和 Grafana 监控内置 Kafka 指标,您可以将 Prometheus 配置为同时提取 Kafka Exporter Prometheus 端点。

其他资源

Kafka 通过 JMX 公开指标,然后可作为 Prometheus 指标导出。

14.1. 消费者滞后

消费者滞后表示消息的速度与消息的消耗的差别。具体来说,给定消费者组的消费者滞后指示分区中最后一个消息与当前由该消费者获取的消息之间的延迟。lag 反映了与分区日志末尾相关的消费者偏移位置。

这种差异有时被称为生成者偏移和消费者偏移之间的 delta,在 Kafka 代理主题分区中的读写位置。

假设主题将 100 个消息流过一秒。生成者偏移(主题分区头)和消费者读取的最后偏移之间的 1000 个消息表示有 10 秒的延迟。

监控消费者滞后的重要性

对于依赖于实时数据的处理的应用程序,监控消费者来判断其是否不会变得太大。整个过程越好,流程从实时处理目标中得到的增长。

例如,消费者滞后可能是消耗太多的旧数据(这些数据尚未被清除)或出现计划外的关闭。

减少消费者滞后

减少滞后的典型操作包括:

  • 通过添加新消费者来扩展消费者组
  • 增加消息的保留时间,以保留在主题中
  • 添加更多磁盘容量以增加消息缓冲

减少消费者滞后的操作取决于底层基础架构和 AMQ Streams 支持的用例。例如,分发的消费者不太可能从其磁盘缓存中获取请求的服务从代理服务。在某些情况下,可能可以接受自动丢弃信息,直到消费者发现为止。

14.2. Kafka Exporter 警报规则示例

特定于 Kafka Exporter 的警报通知规则示例如下:

UnderReplicatedPartition
警告警告主题正在复制时的警报,并且代理没有复制充足的分区。如果主题有一个或多个重复分区,默认配置是警报。该警报可能会表示 Kafka 实例已停机,或者 Kafka 集群过载。可能需要计划重启 Kafka 代理才能重启复制过程。
TooLargeConsumerGroupLag
警告警告消费者组的滞后对于特定主题分区而言太大。默认配置是 1000 记录。大型滞后可能表示消费者太慢,并落于生产者。
NoMessageForTooLong
警告在一段时间内没有收到消息的警报。时间段的默认配置为 10 分钟。延迟可能是防止制作者将消息发布到主题的配置问题。

您可以根据您的特定需求调整警报规则。

其他资源

有关设置警报规则的更多信息,请参阅 Prometheus 文档中的 配置

14.3. Kafka Exporter 指标

Lag 信息由 Kafka Exporter 公开,作为 Grafana 中表示的 Prometheus 指标。

Kafka Exporter 会公开代理、主题和消费者组的指标数据。

Expand
表 14.1. 代理指标输出
Name信息

kafka_brokers

Kafka 集群中的代理数量

Expand
表 14.2. 主题指标输出
Name信息

kafka_topic_partitions

主题的分区数

kafka_topic_partition_current_offset

代理的当前主题分区偏移

kafka_topic_partition_oldest_offset

代理的最旧的主题分区偏移

kafka_topic_partition_in_sync_replica

主题分区的 in-sync 副本数

kafka_topic_partition_leader

主题分区的领导代理 ID

kafka_topic_partition_leader_is_preferred

如果主题分区正在使用首选代理,显示 1

kafka_topic_partition_replicas

本主题分区的副本数

kafka_topic_partition_under_replicated_partition

如果主题分区复制不足,显示 1

Expand
表 14.3. 消费者组指标输出
Name信息

kafka_consumergroup_current_offset

消费者组的当前主题分区偏移

kafka_consumergroup_lag

主题分区中消费者组的当前大约滞后

14.4. 运行 Kafka Exporter

Kafka Exporter 提供了用于安装 AMQ Streams 的下载存档。

您可以运行它来公开 Prometheus 指标,以便在 Grafana 仪表板中进行演示。

此流程假设您已经访问 Grafana 用户界面,并添加了 Prometheus 作为数据源。

流程

  1. 使用适当的配置参数值运行 Kafka Exporter 脚本。

    ./bin/kafka_exporter --kafka.server=<kafka-bootstrap-address>:9092 --kafka.version=3.1.0  --<my-other-parameters>
    Copy to Clipboard Toggle word wrap

    参数需要双假设惯例,如 --kafka.server

    Expand
    表 14.4. Kafka Exporter 配置参数
    选项描述默认

    kafka.server

    Kafka 服务器的 host/post 地址。

    kafka:9092

    kafka.version

    Kafka 代理版本。

    1.0.0

    group.filter

    指定指标中包含的消费者组的正则表达式。

    adtrust (all)

    topic.filter

    指定指标中包含的主题的正则表达式。

    adtrust (all)

    sasl.<parameter>

    使用 SASL/PLAIN 身份验证启用和连接到 Kafka 集群的参数,使用用户名和密码。

    false

    tls.<parameter>

    启用使用 TLS 身份验证连接到 Kafka 集群的参数,以及可选的证书和密钥。

    false

    web.listen-address

    公开指标的端口地址。

    :9308

    web.telemetry-path

    公开指标的路径。

    /metrics

    log.level

    日志记录配置,以记录给定严重性(debug、info、warn、error、fatal)或更高严重性的消息。

    info

    log.enable-sarama

    启用 Sarama 日志记录的布尔值,这是 Kafka Exporter 使用的 Go 客户端库。

    false

    legacy.partitions

    布尔值,以启用从非活动主题分区以及活跃的分区中获取指标。如果您希望 Kafka Exporter 返回不活跃分区的指标,设置为 true

    false

    您可以使用 kafka_exporter --help 来获取有关属性的信息。

  2. 配置 Prometheus 以监控 Kafka 导出器指标。

    有关配置 Prometheus 的更多信息,请参阅 Prometheus 文档

  3. 启用 Grafana 以显示 Prometheus 公开的 Kafka 导出器指标数据。

    如需更多信息,请参阅在 Grafana 中呈现 Kafka Exporter 指标

14.5. 在 Grafana 中显示 Kafka Exporter 指标

使用 Kafka Exporter Prometheus 指标作为数据源,您可以创建一个 Grafana chart 的仪表板。

例如,在指标数据中,您可以创建以下 Grafana chart:

  • 每秒的消息(来自主题)
  • 每分钟的消息(来自主题)
  • 消费者组滞后
  • 每分钟消耗的消息(按消费者组)

当收集指标数据一段时间时,Kafka Exporter chart 会被填充。

使用 Grafana chart 分析滞后,检查操作是否对受影响的消费者组产生影响。例如,如果对 Kafka 代理进行了调整以减少滞后,仪表板将显示 Lag by consumer group 图表下降,Messages consumed per minute 图表增加。

第 15 章 AMQ Streams 和 Kafka 升级

AMQ Streams 可以在没有集群停机时间的情况下升级。每个 AMQ Streams 版本都支持一个或多个 Apache Kafka 版本:只要您的 AMQ Streams 版本支持,就可以升级到更高的 Kafka 版本。较新版本的 AMQ Streams 可能支持较新版本的 Kafka,但您需要升级 AMQ Streams,然后才能升级到 更高的支持的 Kafka 版本。

注意

有关如何升级到该版本的信息,请参阅支持特定版本的 AMQ Streams 文档。

15.1. 升级先决条件

在开始升级过程前,请确保:

15.2. Kafka 版本

Kafka 的日志消息格式版本和 inter-broker 协议版本分别指定,日志格式版本附加到消息以及集群中使用的 Kafka 协议版本。为确保使用了正确的版本,升级过程涉及对现有 Kafka 代理和客户端应用程序(使用者和生产者)进行配置更改。

下表显示了 Kafka 版本之间的区别:

Expand
Kafka 版本Interbroker 协议版本日志消息格式版本ZooKeeper 版本

3.1.0

3.1

3.1

3.6.3

3.0.0

3.0

3.0

3.6.3

inter-broker 协议版本

在 Kafka 中,用于代理间通信的网络协议被称为 inter-broker 协议。Kafka 的每个版本都有了一个内部代理协议的兼容版本。协议的次要版本通常会增加以匹配 Kafka 的次要版本,如上表中所示。

inter-broker 协议版本在 Kafka 资源中设置 cluster wide。要更改它,您可以编辑 Kafka.spec.kafka.config 中的 inter.broker.protocol.version 属性。

日志消息格式版本

当制作者发送消息到 Kafka 代理时,消息会使用特定的格式进行编码。格式可能会在 Kafka 发行版本之间改变,因此消息指定它们编码的消息格式版本。

用于设置特定消息格式版本的属性如下:

  • 主题的 message.format.version 属性
  • Kafka 代理的 log.message.format.version 属性

从 Kafka 3.0.0,消息格式版本值被假定为与 inter.broker.protocol.version 匹配,且不需要设置。该值反映了使用的 Kafka 版本。

当升级到 Kafka 3.0.0 或更高版本时,您可以在更新 inter.broker.protocol.version 时删除这些设置。否则,根据您要升级到的 Kafka 版本设置消息格式版本。

由在 Kafka 代理中设置的 log.message.format.version 定义的 message.format.version 的默认值。您可以通过修改主题配置来手动设置主题的 message.format.version

15.3. 升级 Kafka 代理和 ZooKeeper

此流程描述了如何在主机中升级 Kafka 代理和 ZooKeeper 以使用 AMQ Streams 的最新版本。

您可以更新您的文件,然后配置并重启所有 Kafka 代理以使用新的 inter-broker 协议版本。执行这些步骤后,数据会使用新的 inter-broker 协议版本在 Kafka 代理之间传输。

注意

从 Kafka 3.0.0 开始,消息格式版本值被假定为与 inter.broker.protocol.version 匹配,不需要设置。该值反映了使用的 Kafka 版本。

收到的消息仍然以较早的消息格式版本附加到消息日志中。

先决条件

  • kafka 用户身份登录 Red Hat Enterprise Linux。

流程

对于 AMQ Streams 集群中的每个 Kafka 代理,一次一个:

  1. 从 AMQ Streams 软件下载页面 下载 AMQ Streams 存档。

    注意

    如有提示,登录到您的红帽帐户。

  2. 在命令行中,创建一个临时目录并提取 amq-streams-x.y.z-bin.zip 文件的内容。

    mkdir /tmp/kafka
    unzip amq-streams-x.y.z-bin.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap
  3. 如果运行,停止 ZooKeeper 和主机上运行的 Kafka 代理。

    /opt/kafka/bin/zookeeper-server-stop.sh
    /opt/kafka/bin/kafka-server-stop.sh
    jcmd | grep zookeeper
    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap
  4. 从现有安装中删除 libsbin 目录:

    rm -rf /opt/kafka/libs /opt/kafka/bin
    Copy to Clipboard Toggle word wrap
  5. 从临时目录中复制 libsbin 目录:

    cp -r /tmp/kafka/kafka_y.y-x.x.x/libs /opt/kafka/
    cp -r /tmp/kafka/kafka_y.y-x.x.x/bin /opt/kafka/
    cp -r /tmp/kafka/kafka_y.y-x.x.x/docs /opt/kafka/
    Copy to Clipboard Toggle word wrap
  6. 删除临时目录。

    rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap
  7. 在文本编辑器中,打开代理属性文件,通常存储在 /opt/kafka/config/ 目录中。
  8. 检查 inter.broker.protocol.versionlog.message.format.version 属性是否已设置为当前版本:

    inter.broker.protocol.version=3.0
    log.message.format.version=3.0
    Copy to Clipboard Toggle word wrap

    inter.broker.protocol.version 保持不变,可确保代理可以在升级过程中继续相互通信。

    如果没有配置属性,请使用当前版本添加它们。

  9. 重启更新的 ZooKeeper 和 Kafka 代理:

    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

    Kafka 代理和 Zookeeper 将开始使用最新 Kafka 版本的二进制文件。

  10. 验证重启的 Kafka 代理是否有分区副本。

    使用 kafka-topics.sh 工具来确保代理中包含的所有副本都重新同步。具体步骤请参阅 列出和描述主题

    在后续步骤中,更新您的 Kafka 代理以使用新的 inter-broker 协议版本。

    一次更新每个代理。

    警告

    完成以下步骤后,无法降级 AMQ Streams。

  11. 在文本编辑器中,打开您要更新的 Kafka 代理的代理属性文件。代理属性文件通常存储在 /opt/kafka/config/ 目录中。
  12. inter.broker.protocol.version 设置为 3.1

    inter.broker.protocol.version=3.1
    Copy to Clipboard Toggle word wrap
  13. 在命令行中停止您修改的 Kafka 代理:

    /opt/kafka/bin/kafka-server-stop.sh
    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap
  14. 重启您修改的 Kafka 代理:

    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  15. 验证重启的 Kafka 代理是否有分区副本。

    使用 kafka-topics.sh 工具来确保代理中包含的所有副本都重新同步。具体步骤请参阅 列出和描述主题

15.4. 升级 Kafka Connect

这个步骤描述了如何在主机中升级 Kafka Connect 集群。

先决条件

  • kafka 用户身份登录 Red Hat Enterprise Linux。
  • Kafka Connect 尚未启动。

流程

对于 AMQ Streams 集群中的每个 Kafka 代理,一次一个:

  1. 从 AMQ Streams 软件下载页面 下载 AMQ Streams 存档。

    注意

    如有提示,登录到您的红帽帐户。

  2. 在命令行中,创建一个临时目录并提取 amq-streams-x.y.z-bin.zip 文件的内容。

    mkdir /tmp/kafka
    unzip amq-streams-x.y.z-bin.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap
  3. 如果运行,请停止主机上运行的 Kafka 代理和 ZooKeeper。

    /opt/kafka/bin/kafka-server-stop.sh
    /opt/kafka/bin/zookeeper-server-stop.sh
    Copy to Clipboard Toggle word wrap
  4. 从现有安装中删除 libsbin 目录:

    rm -rf /opt/kafka/libs /opt/kafka/bin /opt/kafka/docs
    Copy to Clipboard Toggle word wrap
  5. 从临时目录中复制 libsbin 目录:

    cp -r /tmp/kafka/kafka_y.y-x.x.x/libs /opt/kafka/
    cp -r /tmp/kafka/kafka_y.y-x.x.x/bin /opt/kafka/
    cp -r /tmp/kafka/kafka_y.y-x.x.x/docs /opt/kafka/
    Copy to Clipboard Toggle word wrap
  6. 删除临时目录。

    rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap
  7. 以独立或分布式模式启动 Kafka 连接。

    • 要在独立模式中启动,请运行 connect-standalone.sh 脚本。指定 Kafka Connect 独立配置文件和 Kafka Connect 连接器的配置文件。

      su - kafka
      /opt/kafka/bin/connect-standalone.sh /opt/kafka/config/connect-standalone.properties connector1.properties
      [connector2.properties ...]
      Copy to Clipboard Toggle word wrap
    • 要在分布式模式下启动,请使用所有 Kafka Connect 节点上的 /opt/kafka/config/connect-distributed.properties 配置文件启动 Kafka Connect worker:

      su - kafka
      /opt/kafka/bin/connect-distributed.sh /opt/kafka/config/connect-distributed.properties
      Copy to Clipboard Toggle word wrap
  8. 验证 Kafka Connect 是否正在运行:

    • 在独立模式中:

      jcmd | grep ConnectStandalone
      Copy to Clipboard Toggle word wrap
    • 在分布式模式中:

      jcmd | grep ConnectDistributed
      Copy to Clipboard Toggle word wrap
  9. 验证 Kafka Connect 是否按预期生成和使用数据。

在 Kafka 升级后,您可以升级 Kafka 使用者和 Kafka Streams 应用程序,以使用 增量协作重新平衡 协议进行分区重新平衡,而不是默认的 eager 重新平衡 协议。在 Kafka 2.4.0 中添加新协议。

消费者将分区分配保持在协作重新平衡中,并仅在需要实现均衡的集群时在进程结束时撤销它们。这可减少消费者组或 Kafka Streams 应用程序的不可用。

注意

升级到增量协作重新平衡协议是可选的。eager 重新平衡协议仍被支持。

先决条件

流程

要升级 Kafka 使用者以使用增量协作重新平衡协议:

  1. 将 Kafka 客户端 .jar 文件替换为新版本。
  2. 在消费者配置中,将 cooperative-sticky 附加到 partition.assignment.strategy。例如,如果设置了 范围 策略,请将配置更改为 range, cooperative-sticky
  3. 依次重启组中的每个消费者,等待用户在每次重启后重新加入组。
  4. 通过从消费者配置中删除之前的 partition.assignment.strategy 来重新配置组中的每个消费者,仅保留 cooperative-sticky 策略。
  5. 依次重启组中的每个消费者,等待用户在每次重启后重新加入组。

要升级 Kafka Streams 应用程序以使用增量协作重新平衡协议:

  1. 将 Kafka Streams .jar 文件替换为新版本。
  2. 在 Kafka Streams 配置中,将 upgrade.from 配置参数设置为您要从升级的 Kafka 版本(如 2.3)。
  3. 依次重启每个流处理器(节点)。
  4. 从 Kafka Streams 配置中删除 upgrade.from 配置参数。
  5. 依次重启组中的每个消费者。

第 16 章 使用 JMX 监控集群

ZooKeeper、Kafka 代理、Kafka Connect 和 Kafka 客户端都使用 Java 管理扩展 (JMX)公开管理信息。大多数管理信息采用用于监控 Kafka 集群条件和性能的指标形式。与其他 Java 应用程序一样,Kafka 通过受管 Bean 或 MBeans 提供这些管理信息。

JMX 在 JVM (Java 虚拟机)的级别工作。要获取管理信息,外部工具可以连接到运行 ZooKeeper、Kafka 代理等的 JVM。默认情况下,只有同一计算机上的工具,并且与 JVM 相同的用户运行才能连接。

注意

ZooKeeper 的管理信息没有记录在此处。您可以在 JConsole 中查看 ZooKeeper 指标。如需更多信息,请参阅使用 JConsole 监控

16.1. JMX 配置选项

您可以使用 JVM 系统属性配置 JMX。由 AMQ Streams 提供的脚本(bin/kafka-server-start.shbin/connect-distributed.sh )使用 KAFKA_JMX_OPTS 环境变量来设置这些系统属性。配置 JMX 的系统属性相同,即使 Kafka 生成者、消费者和流应用程序通常以不同的方式启动 JVM。

16.2. 禁用 JMX 代理

您可以通过禁用 AMQ Streams 组件的 JMX 代理来防止本地 JMX 工具连接到 JVM (例如,出于合规原因)。以下流程解释了如何为 Kafka 代理禁用 JMX 代理。

流程

  1. 使用 KAFKA_JMX_OPTS 环境变量将 com.sun.management.jmxremote 设置为 false

    export KAFKA_JMX_OPTS=-Dcom.sun.management.jmxremote=false
    bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  2. 启动 JVM。

16.3. 从其他机器连接到 JVM

您可以通过配置 JMX 代理侦听的端口从其他计算机连接到 JVM。这是不安全的,因为它允许 JMX 工具从任何位置进行连接,而无需身份验证。

流程

  1. 使用 KAFKA_JMX_OPTS 环境变量设置 -Dcom.sun.management.jmxremote.port=<port>。对于 & lt;port >,请输入您希望 Kafka 代理侦听 JMX 连接的端口名称。

    export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote=true
      -Dcom.sun.management.jmxremote.port=<port>
      -Dcom.sun.management.jmxremote.authenticate=false
      -Dcom.sun.management.jmxremote.ssl=false"
    bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  2. 启动 JVM。
重要

建议您配置身份验证和 SSL 以确保远程 JMX 连接安全。有关执行此操作所需的系统属性的更多信息,请参阅 JMX 文档

16.4. 使用 JConsole 进行监控

JConsole 工具与 Java Development Kit(JDK)一起发布。您可以使用 JConsole 连接到本地或远程 JVM,并从 Java 应用发现和显示管理信息。如果使用 JConsole 连接到本地 JVM,则与 AMQ Streams 不同组件对应的 JVM 进程名称。

Expand
表 16.1. AMQ Streams 组件的 JVM 进程
AMQ Streams 组件JVM 进程

ZooKeeper

org.apache.zookeeper.server.quorum.QuorumPeerMain

Kafka 代理

kafka.Kafka

Kafka Connect 独立

org.apache.kafka.connect.cli.ConnectStandalone

分布式 Kafka Connect

org.apache.kafka.connect.cli.ConnectDistributed

Kafka 生成者、消费者或流应用程序

包含应用程序 main 方法的类名称。

使用 JConsole 连接到远程 JVM 时,请使用适当的主机名和 JMX 端口。

其他很多工具和监控产品都可用于使用 JMX 获取指标,并根据这些指标提供监控和警报。有关这些工具,请参阅产品文档。

16.5. 重要的 Kafka 代理指标

Kafka 提供了多个 MBeans 来监控 Kafka 集群中代理的性能。它们应用到单独的代理而不是整个集群。

下表介绍了这些代理级 MBeans 的选择,它们被组织到服务器、网络、日志记录和控制器指标中。

16.5.1. Kafka 服务器指标

下表显示了报告 Kafka 服务器信息的指标选择。

Expand
表 16.2. Kafka 服务器的指标
指标mbean描述预期值

每秒的消息

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec

代理使用单个消息的速率。

与集群中的其他代理相同。

每秒字节数

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec

从制作者发送的数据被代理消耗的速率。

与集群中的其他代理相同。

每秒复制字节数

kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec

来自其他代理发送数据的速率由 follower 代理使用。

N/A

每秒的字节数

kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

消费者从代理获取和读取数据的速率。

N/A

每秒复制字节数

kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec

从代理发送到其他代理的速率。此指标可用于监控代理是否为一组分区的领导机。

N/A

下复制分区

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

在后续副本中没有完全复制的分区数量。

最小 ISR 分区数

kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount

最小 In-Sync Replica (ISR)数下的分区数量。ISR 计数表示与领导状态保持最新的一组副本。

分区数

kafka.server:type=ReplicaManager,name=PartitionCount

代理中的分区数量。

几乎即使与其他代理相比也是如此。

领导数

kafka.server:type=ReplicaManager,name=LeaderCount

此代理是领导的副本数。

与集群中的其他代理相同。

ISR 每秒缩小

kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

代理中 ISR 数量降低的速率

ISR 每秒扩展

kafka.server:type=ReplicaManager,name=IsrExpandsPerSec

代理中 ISR 数量增加的速率。

最大滞后

kafka.server:type=ReplicaFetcherManager,name=MaxLag,clientId=Replica

在领导副本接收消息由领导副本和后续副本接收的时间之间的最大滞后。

与生成请求的最大批处理大小成比例。

生成者中的请求

kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Produce

在制作者购买中发送请求的数量。

N/A

获取购买的请求

kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Fetch

获取请求中的获取请求数。

N/A

请求处理器平均闲置百分比

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

表示请求处理程序(IO)线程没有使用的时间百分比。

较低值表示代理的工作负载很高。

请求(请求免于节流)

kafka.server:type=Request

免于节流的请求数。

N/A

ZooKeeper 请求延迟(以毫秒为单位)

kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs

来自代理的 ZooKeeper 请求延迟,以毫秒为单位。

N/A

ZooKeeper 会话状态

kafka.server:type=SessionExpireListener,name=SessionState

代理连接到 ZooKeeper 的状态。

已连接

16.5.2. Kafka 网络指标

下表显示了报告有关请求信息的指标选择。

Expand
指标mbean描述预期值

每秒请求数

kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower}

为每秒请求类型发出的请求总数。ProduceFetchConsumerFetchFollower 请求类型各自都有自己的 MBeans。

N/A

请求字节数(请求大小(以字节为单位)

kafka.network:type=RequestMetrics,name=RequestBytes,request=([-.\w]+)

为 MBean 名称的 request 属性标识的请求类型发出的请求大小,以字节为单位。RequestBytes 节点下列出了所有可用请求类型的单独的 MBeans。

N/A

临时内存大小(以字节为单位)

kafka.network:type=RequestMetrics,name=TemporaryMemoryBytes,request={Produce|Fetch}

用于转换消息格式和解压缩消息的临时内存量。

N/A

消息转换时间

kafka.network:type=RequestMetrics,name=MessageConversionsTimeMs,request={Produce|Fetch}

花费在转换消息格式的时间(毫秒)。

N/A

请求总时间(以毫秒为单位)

kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}

处理请求的总时间(以毫秒为单位)。

N/A

请求队列时间(以毫秒为单位)

kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}

请求当前在 request 属性中给定的请求类型的时间(以毫秒为单位)。

N/A

本地时间(领导本地处理时间)以毫秒为单位

kafka.network:type=RequestMetrics,name=LocalTimeMs,request={Produce|FetchConsumer|FetchFollower}

处理请求的领导时间(以毫秒为单位)。

N/A

远程时间(领导远程处理时间)以毫秒为单位

kafka.network:type=RequestMetrics,name=RemoteTimeMs,request={Produce|FetchConsumer|FetchFollower}

请求等待后续程序的时间长度(以毫秒为单位)。RemoteTimeMs 节点下列出了所有可用请求类型的单独的 MBeans。

N/A

以毫秒为单位响应队列时间

kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}

请求在响应队列中等待的时间长度(以毫秒为单位)。

N/A

响应发送时间(以毫秒为单位)

kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request={Produce|FetchConsumer|FetchFollower}

发送响应所需的时间(以毫秒为单位)。

N/A

网络处理器平均空闲百分比

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

网络处理器闲置的平均时间百分比。

在零到一之间.

16.5.3. Kafka 日志指标

下表显示了报告日志记录信息的指标选择。

Expand
指标mbean描述预期值

以毫秒为单位的日志清除率和时间

kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs

写入磁盘的速率(以毫秒为单位)。

N/A

离线日志目录计数

kafka.log:type=LogManager,name=OfflineLogDirectoryCount

离线日志目录数量(例如,硬件故障后)。

16.5.4. Kafka 控制器指标

下表显示了一个报告集群控制器信息的指标选择。

Expand
指标mbean描述预期值

活跃控制器计数

kafka.controller:type=KafkaController,name=ActiveControllerCount

指定为控制器的代理数量。

一个表示代理是集群的控制器。

以毫秒为单位领导选举率和时间

kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs

选择新领导副本的速度。

16.5.5. Yammer 指标

代表速率或时间单位的指标作为 Yammer 指标提供。使用 Yammer 指标的 MBean 类名称前缀为 com.yammer.metrics

Yammer 速率指标具有以下属性来监控请求:

  • 数量
  • EventType (Bytes)
  • FifteenMinuteRate
  • RateUnit (Seconds)
  • MeanRate
  • OneMinuteRate
  • FiveMinuteRate

Yammer 时间指标具有以下属性来监控请求:

  • Max
  • Min
  • 平均
  • StdDev
  • 75/95/98/99/99.9 Percentile

16.6. producer MBeans

Kafka producer 应用程序(包括 Kafka Streams 应用程序和带有源连接器的 Kafka Connect)中会存在以下 MBeans。

这些是生成者级别的指标。

Expand
属性描述

batch-size-avg

每个分区按请求发送的平均字节数。

batch-size-max

每个请求的每分区发送的最大字节数。

batch-split-rate

每秒的批处理平均数量。

batch-split-total

批处理的总数。

buffer-available-bytes

未使用缓冲区内存量(未分配或可用列表)。

buffer-total-bytes

客户端可以使用的最大缓冲区内存量(无论当前是否正在使用)。

bufferpool-wait-time

附加程序等待空间分配的时间部分。

compression-rate-avg

记录批处理的平均压缩率,定义为压缩批处理大小在未压缩大小的平均比率。

connection-close-rate

窗口中每秒关闭的连接。

connection-count

当前活跃的连接数。

connection-creation-rate

窗口中每秒建立的新连接。

failed-authentication-rate

身份验证失败的连接。

incoming-byte-rate

对所有套接字进行字节/秒读取。

io-ratio

I/O 线程处理 I/O 线程的几分时间。

io-time-ns-avg

每个选择调用的 I/O 的平均时间长度(以纳秒为单位)。

io-wait-ratio

I/O 线程等待的时间部分。

io-wait-time-ns-avg

I/O 线程的平均时间长度为等待一个套接字,准备好以纳秒为单位进行读取或写入。

metadata-age

使用的当前制作者元数据的年龄(以秒为单位)。

network-io-rate

每秒所有连接上的网络操作(读或写)的平均数量。

outgoing-byte-rate

每秒发送到所有服务器的平均传出字节数。

produce-throttle-time-avg

请求受代理节流的平均时间(毫秒)。

produce-throttle-time-max

请求被代理节流的最大时间( ms)。

record-error-rate

平均每秒记录发送数会导致错误。

record-error-total

导致错误的记录发送的总数。

record-queue-time-avg

批处理的平均时间( ms 记录批处理)在发送缓冲区中花费。

record-queue-time-max

批处理在发送缓冲区中花费的最大时间( ms 记录)。

record-retry-rate

重试记录的平均每秒数发送。

record-retry-total

重试记录发送的总数。

record-send-rate

每秒发送的平均记录数。

record-send-total

发送的记录总数。

record-size-avg

平均记录大小。

record-size-max

最大记录大小。

records-per-request-avg

每个请求的平均记录数。

request-latency-avg

平均请求延迟(以 ms 为单位)。

request-latency-max

ms 中的最大请求延迟。

request-rate

每秒发送的请求数平均数。

request-size-avg

窗口中所有请求的平均大小。

request-size-max

窗口中发送的任何请求的最大大小。

requests-in-flight

当前用于等待响应的 in-flight 请求数量。

response-rate

每秒发送的响应数。

select-rate

检查 I/O 层每秒执行的 I/O 层的次数。

successful-authentication-rate

使用 SASL 或 SSL 成功进行身份验证的连接。

waiting-threads

用户线程数量会阻止等待缓冲区内存排队其记录。

这些是在生成者级别上有关与每个代理连接的指标。

Expand
属性描述

incoming-byte-rate

节点每秒接收的平均响应数。

outgoing-byte-rate

节点每秒发送的传出字节数。

request-latency-avg

节点的平均请求延迟为 ms。

request-latency-max

节点的最大请求延迟( ms)。

request-rate

节点每秒发送的请求数。

request-size-avg

节点窗口中所有请求的平均大小。

request-size-max

在节点窗口中发送的任何请求的最大大小。

response-rate

节点每秒发送的响应。

这些是在主题级别上的指标,有关生成者要发送消息的主题。

Expand
属性描述

byte-rate

主题每秒发送的平均字节数。

byte-total

为主题发送的字节数。

compression-rate

主题记录批处理的平均压缩率,定义为压缩的批处理大小的平均比率。

record-error-rate

平均每秒记录发送数会导致主题出错。

record-error-total

导致主题出错的记录总数。

record-retry-rate

重试记录的平均每秒次数为主题发送。

record-retry-total

主题发送的重试记录总数。

record-send-rate

主题每秒发送的平均记录数。

record-send-total

为主题发送的记录总数。

16.7. consumer MBeans

Kafka 消费者应用程序包括以下 MBeans,包括 Kafka Streams 应用程序和 Kafka Connect with sink 连接器。

这些是消费者级别的指标。

Expand
属性描述

connection-close-rate

窗口中每秒关闭的连接。

connection-count

当前活跃的连接数。

connection-creation-rate

窗口中每秒建立的新连接。

failed-authentication-rate

身份验证失败的连接。

incoming-byte-rate

对所有套接字进行字节/秒读取。

io-ratio

I/O 线程处理 I/O 线程的几分时间。

io-time-ns-avg

每个选择调用的 I/O 的平均时间长度(以纳秒为单位)。

io-wait-ratio

I/O 线程等待的时间部分。

io-wait-time-ns-avg

I/O 线程的平均时间长度为等待一个套接字,准备好以纳秒为单位进行读取或写入。

network-io-rate

每秒所有连接上的网络操作(读或写)的平均数量。

outgoing-byte-rate

每秒发送到所有服务器的平均传出字节数。

request-rate

每秒发送的请求数平均数。

request-size-avg

窗口中所有请求的平均大小。

request-size-max

窗口中发送的任何请求的最大大小。

response-rate

每秒发送的响应数。

select-rate

检查 I/O 层每秒执行的 I/O 层的次数。

successful-authentication-rate

使用 SASL 或 SSL 成功进行身份验证的连接。

这些是关于连接到每个代理的消费者级别的指标。

Expand
属性描述

incoming-byte-rate

节点每秒接收的平均响应数。

outgoing-byte-rate

节点每秒发送的传出字节数。

request-latency-avg

节点的平均请求延迟为 ms。

request-latency-max

节点的最大请求延迟( ms)。

request-rate

节点每秒发送的请求数。

request-size-avg

节点窗口中所有请求的平均大小。

request-size-max

在节点窗口中发送的任何请求的最大大小。

response-rate

节点每秒发送的响应。

这些是在消费者组的消费者级别的指标。

Expand
属性描述

assigned-partitions

当前分配给此消费者的分区数量。

commit-latency-avg

提交请求所花费的平均时间。

commit-latency-max

提交请求所花费的最大时间。

commit-rate

每秒提交调用数量。

heartbeat-rate

每秒心跳数的平均数量。

heartbeat-response-time-max

接收对心跳请求的响应的最大时间。

join-rate

每秒加入的组数量。

join-time-avg

重新加入组的平均时间。

join-time-max

重新加入组所花费的最大时间。

last-heartbeat-seconds-ago

最后一次控制器心跳后的秒数。

sync-rate

每秒组同步数。

sync-time-avg

组同步的平均时间。

sync-time-max

组同步所花费的最大时间。

这些是消费者获取器的消费者级别的指标。

Expand
属性描述

bytes-consumed-rate

每秒消耗的平均字节数。

bytes-consumed-total

所消耗的字节数。

fetch-latency-avg

获取请求的平均时间。

fetch-latency-max

任何获取请求所花费的最大时间。

fetch-rate

每秒获取请求数。

fetch-size-avg

每个请求获取的平均字节数。

fetch-size-max

每个请求获取的最大字节数。

fetch-throttle-time-avg

平均 throttle 时间( ms)。

fetch-throttle-time-max

ms 中的最大节流时间。

fetch-total

获取请求总数。

records-consumed-rate

每秒消耗的平均记录数。

records-consumed-total

所消耗的记录总数。

records-lag-max

这个窗口中任何分区的记录数上限。

records-lead-min

这个窗口中任何分区的记录数的最小领导数。

records-per-request-avg

每个请求中的平均记录数。

这些是在消费者获取器的主题级别的指标。

Expand
属性描述

bytes-consumed-rate

主题每秒消耗的平均字节数。

bytes-consumed-total

主题消耗的字节数。

fetch-size-avg

主题的每个请求获取的平均字节数。

fetch-size-max

主题的每个请求获取的最大字节数。

records-consumed-rate

主题每秒消耗的平均记录数。

records-consumed-total

为主题使用的记录总数。

records-per-request-avg

每个请求中的一个主题的平均记录数。

这些是有关消费者获取器的分区级别的指标。

Expand
属性描述

preferred-read-replica

分区的当前读取副本,如果从 leader 读取,则为 -1。

records-lag

分区的最新滞后。

records-lag-avg

分区的平均滞后。

records-lag-max

分区的最大滞后。

records-lead

分区的最新领导。

records-lead-avg

分区的平均领导。

records-lead-min

分区的最小领导。

16.8. Kafka Connect MBeans

注意

除了此处记录的,Kafka Connect 还会包含用于源连接器 和消费者 MBeans 的制作者 MBeans。???

这些是连接级别的指标。

Expand
属性描述

connection-close-rate

窗口中每秒关闭的连接。

connection-count

当前活跃的连接数。

connection-creation-rate

窗口中每秒建立的新连接。

failed-authentication-rate

身份验证失败的连接。

incoming-byte-rate

对所有套接字进行字节/秒读取。

io-ratio

I/O 线程处理 I/O 线程的几分时间。

io-time-ns-avg

每个选择调用的 I/O 的平均时间长度(以纳秒为单位)。

io-wait-ratio

I/O 线程等待的时间部分。

io-wait-time-ns-avg

I/O 线程的平均时间长度为等待一个套接字,准备好以纳秒为单位进行读取或写入。

network-io-rate

每秒所有连接上的网络操作(读或写)的平均数量。

outgoing-byte-rate

每秒发送到所有服务器的平均传出字节数。

request-rate

每秒发送的请求数平均数。

request-size-avg

窗口中所有请求的平均大小。

request-size-max

窗口中发送的任何请求的最大大小。

response-rate

每秒发送的响应数。

select-rate

检查 I/O 层每秒执行的 I/O 层的次数。

successful-authentication-rate

使用 SASL 或 SSL 成功进行身份验证的连接。

这些是在连接每个代理的连接级别的指标。

Expand
属性描述

incoming-byte-rate

节点每秒接收的平均响应数。

outgoing-byte-rate

节点每秒发送的传出字节数。

request-latency-avg

节点的平均请求延迟为 ms。

request-latency-max

节点的最大请求延迟( ms)。

request-rate

节点每秒发送的请求数。

request-size-avg

节点窗口中所有请求的平均大小。

request-size-max

在节点窗口中发送的任何请求的最大大小。

response-rate

节点每秒发送的响应。

这些是连接级别的指标。

Expand
属性描述

connector-count

此 worker 中运行连接器的数量。

connector-startup-attempts-total

此 worker 尝试的连接器启动总数。

connector-startup-failure-percentage

此 worker 连接器的平均百分比开始失败。

connector-startup-failure-total

连接器的总数开始失败。

connector-startup-success-percentage

此 worker 连接器的平均百分比开始成功。

connector-startup-success-total

连接器的总数开始成功。

task-count

此 worker 中运行的任务数量。

task-startup-attempts-total

此 worker 试图启动的任务总数。

task-startup-failure-percentage

此 worker 任务的平均百分比开始失败。

task-startup-failure-total

启动失败的任务总数。

task-startup-success-percentage

此 worker 任务的平均百分比开始成功。

task-startup-success-total

任务总数开始成功。

Expand
属性描述

completed-rebalances-total

此 worker 完成的重新平衡总数。

connect-protocol

此集群使用的 Connect 协议。

epoch

此 worker 的 epoch 或生成号。

leader-name

组 leader 的名称。

rebalance-avg-time-ms

此 worker 要重新平衡的平均时间(以毫秒为单位)。

rebalance-max-time-ms

此 worker 要重新平衡的最大时间(毫秒)。

重新平衡

此 worker 当前是重新平衡的。

time-since-last-rebalance-ms

此 worker 完成最新重新平衡后的时间(毫秒)。

Expand
属性描述

connector-class

连接器类的名称。

connector-type

连接器的类型。'source' 或 'sink' 之一。

connector-version

连接器类的版本,如连接器所示。

status

连接器的状态。'unassigned'、'running'、'paused'、'failed' 或 'destroyed' 的一个。

Expand
属性描述

batch-size-avg

连接器处理的平均批处理大小。

batch-size-max

连接器处理的最大批处理大小。

offset-commit-avg-time-ms

此任务所花费的平均时间(以毫秒为单位)提交偏移。

offset-commit-failure-percentage

此任务偏移提交的平均百分比尝试失败。

offset-commit-max-time-ms

此任务提交偏移的最大时间(以毫秒为单位)。

offset-commit-success-percentage

此任务偏移提交的平均百分比尝试成功。

pause-ratio

此任务花费在暂停状态的几部分时间。

running-ratio

此任务花费在 running 状态的时间部分。

status

连接器任务的状态。'unassigned'、'running'、'paused'、'failed' 或 'destroyed' 的一个。

Expand
属性描述

offset-commit-completion-rate

成功完成的偏移提交完成的平均数量。

offset-commit-completion-total

成功完成的偏移提交完成总数。

offset-commit-seq-no

偏移提交的当前序列号。

offset-commit-skip-rate

接收太晚并跳过/忽略的偏移提交完成的平均数量。

offset-commit-skip-total

收到太晚并跳过/忽略的偏移提交完成总数。

partition-count

分配给此任务的主题分区数量属于此 worker 中命名 sink 连接器。

put-batch-avg-time-ms

此任务用于放置批处理接收器记录的平均时间。

put-batch-max-time-ms

此任务放置批处理接收器记录的最大时间。

sink-record-active-count

从 Kafka 读取的记录数量,但还没有完全提交/冲刷/已由 sink 任务提交/确认。

sink-record-active-count-avg

从 Kafka 读取的平均记录数量,但还没有完全提交/冲刷/已由 sink 任务提交/确认。

sink-record-active-count-max

从 Kafka 读取的最大记录数量,但还没有完全提交/冲刷/已由 sink 任务提交/确认。

sink-record-lag-max

sink 任务在消费者的任何主题分区位置后面的记录数量上限。

sink-record-read-rate

从 Kafka 读取的平均每秒记录数,用于属于此 worker 中命名 sink 连接器的此任务。这是应用转换前的。

sink-record-read-total

此任务从 Kafka 读取的记录总数属于这个 worker 中的命名 sink 连接器,因为任务上次重启。

sink-record-send-rate

转换中平均每秒记录输出数,并将/吞吐量发送到此 worker 中名为 sink 连接器的此任务。这是在应用转换后,会排除转换过滤的所有记录。

sink-record-send-total

从转换和发送/计算到此任务的记录输出总数,属于此 worker 中的指定 sink 连接器,因为任务上次重启。

Expand
属性描述

poll-batch-avg-time-ms

此任务轮询源记录的批处理的平均时间(以毫秒为单位)。

poll-batch-max-time-ms

此任务轮询源记录的最长时间(以毫秒为单位)。

source-record-active-count

此任务生成的记录数,但还没有完全写入 Kafka。

source-record-active-count-avg

此任务生成的平均记录数,但还没有完全写入 Kafka。

source-record-active-count-max

此任务生成的最大记录数,但还没有完全写入 Kafka。

source-record-poll-rate

此任务属于此 worker 中命名的源连接器的每秒记录的平均每秒数量(之前转换)。

source-record-poll-total

此任务属于此 worker 中命名的源连接器的生成/polled (以前转换)的记录总数。

source-record-write-rate

从转换后,对此任务的每秒记录输出数平均数写入 Kafka,此任务属于这个 worker 中命名的源连接器。这是在应用转换后,会排除转换过滤的所有记录。

source-record-write-total

此任务属于此 worker 中的指定源连接器的转换和写入 Kafka 的记录输出数量,因为任务上次重启。

Expand
属性描述

deadletterqueue-produce-failures

对死信队列的失败写入数量。

deadletterqueue-produce-requests

尝试写入死信队列的数量。

last-error-timestamp

此任务最后一次遇到错误时的 epoch 时间戳。

total-errors-logged

记录的错误数。

total-record-errors

此任务中的记录处理错误数量。

total-record-failures

此任务中的记录处理失败数量。

total-records-skipped

由于错误,跳过的记录数量。

total-retries

重试的操作数量。

16.9. Kafka Streams MBeans

注意

除了在此处记录的外,流应用还会包含 制作者 和消费者 MBeans。

metrics.recording.level 配置参数是 infodebug 时,会收集这些指标。

Expand
属性描述

commit-latency-avg

在此线程的所有运行任务中,用于提交的平均执行时间(以 ms 为单位)。

commit-latency-max

此线程的所有运行任务间提交的最大执行时间(以 ms 为单位)。

commit-rate

每秒提交的平均数量。

commit-total

所有任务的提交调用总数。

poll-latency-avg

此线程的所有运行任务中用于轮询的平均执行时间(以 ms 为单位)。

poll-latency-max

此线程的所有运行任务中轮询的最大执行时间(以 ms 为单位)。

poll-rate

每秒轮询平均数量。

poll-total

所有任务的轮询调用总数。

process-latency-avg

此线程的所有运行任务中用于处理的平均执行时间(毫秒)。

process-latency-max

此线程的所有运行任务中处理的最大执行时间(以 ms 为单位)。

process-rate

每秒进程调用的平均数量。

process-total

所有任务的进程调用总数。

punctuate-latency-avg

此线程的所有运行任务中的 ms 的平均执行时间(以 ms 为单位)。

punctuate-latency-max

此线程的所有运行任务中标点的最大执行时间(以 ms 为单位)。

punctuate-rate

每秒标点的平均数量。

punctuate-total

所有任务的标点调用总数。

skipped-records-rate

每秒跳过的记录的平均数量。

skipped-records-total

跳过的记录总数。

task-closed-rate

每秒关闭的平均任务数量。

task-closed-total

关闭的任务总数。

task-created-rate

每秒新创建的任务的平均数量。

task-created-total

创建的任务总数。

任务指标。

metrics.recording.level 配置参数是 debug 时,会收集这些指标。

Expand
属性描述

commit-latency-avg

ns 中用于此任务的平均提交时间。

commit-latency-max

ns 中此任务的最大提交时间。

commit-rate

每秒提交调用的平均数量。

commit-total

提交调用的总数。

处理器节点指标.

metrics.recording.level 配置参数是 debug 时,会收集这些指标。

Expand
属性描述

create-latency-avg

ns 中平均创建执行时间。

create-latency-max

ns 中的最大创建执行时间。

create-rate

每秒创建操作的平均数量。

create-total

创建操作的总数,称为.

destroy-latency-avg

ns 中平均销毁执行时间。

destroy-latency-max

ns 中的最大销毁执行时间。

destroy-rate

每秒销毁操作的平均数量。

destroy-total

销毁操作的总数,称为.

forward-rate

记录的平均速率仅从源节点转发,每秒转发。

forward-total

从源节点转发下游的记录总数。

process-latency-avg

ns 中平均进程执行时间。

process-latency-max

ns 中的最大进程执行时间。

process-rate

每秒进程操作的平均数量。

process-total

进程操作总数,称为.

punctuate-latency-avg

ns 中平均标点执行时间。

punctuate-latency-max

ns 中的最大标点执行时间。

punctuate-rate

每秒标点操作的平均数量。

punctuate-total

标点操作总数,称为.

状态存储指标。

metrics.recording.level 配置参数是 debug 时,会收集这些指标。

Expand
属性描述

all-latency-avg

ns 中的平均操作执行时间。

all-latency-max

ns 中所有操作执行时间上限。

all-rate

此存储的平均操作率。

all-total

此存储的所有操作调用总数。

delete-latency-avg

ns 中平均删除执行时间。

delete-latency-max

ns 中的最大删除执行时间。

delete-rate

此存储的平均删除率。

delete-total

此存储的删除调用总数。

flush-latency-avg

ns 中平均清空执行时间。

flush-latency-max

ns 中的最大 flush 执行时间。

flush-rate

此存储的平均冲刷率。

flush-total

此存储的刷新调用总数。

get-latency-avg

ns 中平均获得执行时间。

get-latency-max

ns 中的最大获取执行时间。

get-rate

此存储的平均获得率。

get-total

此存储的获取调用总数。

put-all-latency-avg

平均 put-all 执行时间在 ns 中。

put-all-latency-max

在 ns 中的最大放置执行时间。

put-all-rate

此存储的平均放置率。

put-all-total

此存储的 put-all 调用总数。

put-if-absent-latency-avg

平均 put-if-absent 执行时间在 ns 中。

put-if-absent-latency-max

ns 中的最大 put-if-absent 执行时间。

put-if-absent-rate

此存储的平均 put-if-absent 速率。

put-if-absent-total

此存储的 put-if-absent 调用总数。

put-latency-avg

平均执行时间在 ns 中。

put-latency-max

在 ns 中放置的最大执行时间。

put-rate

此存储的平均位置率。

put-total

此存储的放置调用总数。

range-latency-avg

ns 中平均范围执行时间。

range-latency-max

ns 中的最大范围执行时间。

range-rate

此存储的平均范围率。

range-total

此存储的范围调用总数。

restore-latency-avg

ns 中平均恢复执行时间。

restore-latency-max

ns 中的最大恢复执行时间。

restore-rate

此存储的平均恢复率。

restore-total

此存储的恢复调用总数。

记录缓存指标。

metrics.recording.level 配置参数是 debug 时,会收集这些指标。

Expand
属性描述

hitRatio-avg

平均缓存命中率定义为缓存读取请求的比例。

hitRatio-max

最大缓存命中率。

hitRatio-min

mininum 缓存命中率。

附录 A. 代理配置参数

advertised.listeners

Type: string
Default: null
Importance: high
Dynamic update: per-broker

与监听器配置属性不同,要发布到 ZooKeeper 的监听程序 供客户端使用。在 IaaS 环境中,这可能需要与代理绑定到的接口不同。如果没有设置,则使用 监听程序 的值。与 监听器 不同,公告 0.0.0.0 meta-address 无效。与 监听器 不同,此属性中可能存在重复的端口,以便可以配置一个侦听器来公告另一个侦听器的地址。这在使用外部负载均衡器时很有用。

auto.create.topics.enable

Type: boolean
Default: true
Importance: high
Dynamic update: read-only

在服务器上启用自动创建主题。

auto.leader.rebalance.enable

Type: boolean
Default: true
Importance: high
Dynamic update: read-only

启用自动领导平衡。后台线程会定期检查分区领导分布,由 leader.imbalance.check.interval.seconds 进行配置。如果领导 imbalance 超过 leader.imbalance.per.broker.percentage,则触发领导到分区的首选领导。

background.threads

type: int
Default: 10
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

用于各种后台处理任务的线程数量。

broker.id

type: int
Default: -1
Importance: high
Dynamic update: read-only

此服务器的代理 ID。如果未设置,则会生成唯一的代理 id。要避免 zookeeper 生成的代理 ID 和用户配置的代理 ID 间的冲突,从 reserved.broker.max.id + 1 中生成代理 ids start。

compression.type

Type: string
Default: producer
Importance: high
Dynamic update: cluster-wide

指定给定主题的最终压缩类型。此配置接受标准压缩解码器('gzip', 'snappy', 'lz4', 'zstd')。它还接受等同于没有压缩的 'uncompressed';而 'producer' 表示保留由 producer 设置的原始压缩 codec。

control.plane.listener.name

Type: string
Default: null
Importance: high
Dynamic update: read-only

用于控制器和代理之间的通信的监听程序名称。代理将使用 control.plane.listener.name 在监听器列表中找到端点,以侦听来自控制器的连接。例如,如果代理的配置为:listeners = INTERNAL://192.1.1.8:9092, EXTERNAL://10.1.1.5:9093, CONTROLLER://192.1.1.8:9094 listener.security.protocol.map = INTERNAL:PLAINTEXT, EXTERNAL:SSL, CONTROLLER:SSL control.plane.listener.name = CONTROLLER On startup, the broker will start listening on "192.1.1.8:9094" with security protocol "SSL"。在控制器一侧,当它通过 zookeeper 发现代理发布的端点时,它将使用 control.plane.listener.name 找到端点,它将用来与代理建立连接。例如,如果代理公布的在 zookeeper 上的端的为: "endpoints" : ["INTERNAL://broker1.example.com:9092","EXTERNAL://broker1.example.com:9093","CONTROLLER://broker1.example.com:9094"] and the controller’s config is : listener.security.protocol.map = INTERNAL:PLAINTEXT, EXTERNAL:SSL, CONTROLLER:SSL control.plane.listener.name = CONTROLLER then controller will use "broker1.example.com:9094" with security protocol "SSL" to connect to the broker。如果没有显式配置,则默认值为 null,且没有控制器连接的专用端点。

controller.listener.names

Type: string
Default: null
Importance: high
Dynamic update: read-only

控制器使用的监听程序名称的逗号分隔列表。这在 KRaft 模式下运行时需要。基于 ZK 的控制器不会使用这个配置。

controller.quorum.election.backoff.max.ms

type: int
Default: 1000 (1 second)
Importance: high
Dynamic update: read-only

开始新选举前的最长时间(毫秒)。这在有助于防止网格锁定的二进制指数 backoff 机制中使用。

controller.quorum.election.timeout.ms

type: int
Default: 1000 (1 second)
Importance: high
Dynamic update: read-only

在触发新选举前,等待的最长时间(以毫秒为单位),而无需从领导中获取。

controller.quorum.fetch.timeout.ms

type: int
Default: 2000 (2 seconds)
Importance: high
Dynamic update: read-only

在成为候选人并触发票务选举前,不成功从当前领导获得的最长时间;在询问是否有新时机之前从大多数仲裁中获取的最长时间。

controller.quorum.voters

type: list
Default: ""
Valid Values: non-empty list
Importance: high
Dynamic update: read-only

在以逗号分隔的 {id}@{host}:{port} 条目列表中,为一组 voters 的 id/endpoint 信息映射。例如: 1@localhost:9092,2@localhost:9093,3@localhost:9094.

delete.topic.enable

Type: boolean
Default: true
Importance: high
Dynamic update: read-only

启用删除主题。如果关闭此配置,通过 admin 工具删除主题将无效。

leader.imbalance.check.interval.seconds

Type: long
Default: 300
Importance: high
Dynamic update: read-only

控制器触发分区重新平衡检查的频率。

leader.imbalance.per.broker.percentage

Type: int
Default: 10
Importance: high
Dynamic update: read-only

每个代理允许的 leader 的比率。如果每个代理超过这个值,控制器会触发领导平衡。该值以百分比为单位。

监听器

Type: string
Default: PLAINTEXT://:9092
Importance: high
Dynamic update: per-broker

侦听器列表 - 我们将侦听的 URI 列表和侦听器名称。如果侦听器名称不是安全协议,还必须设置 listener.security.protocol.map。侦听器名称和端口号必须是唯一的。将 hostname 指定为 0.0.0.0 以绑定到所有接口。将 hostname 留空,以绑定到默认接口。法律侦听器列表示例: PLAINTEXT://myhost:9092,SSL://:9091 CLIENT://0.0.0.0:9092,REPLICATION://localhost:9093。

log.dir

type: string
Default: /tmp/kafka-logs
Importance: high
Dynamic update: read-only

保存日志数据的目录(为 log.dirs 属性提供)。

log.dirs

Type: string
Default: null
Importance: high
Dynamic update: read-only

保存日志数据的目录。如果没有设置,则使用 log.dir 的值。

log.flush.interval.messages

type: long
Default: 9223372036854775807
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

在消息刷新到磁盘前,日志分区上积累的消息数量。

log.flush.interval.ms

Type: long
Default: null
Importance: high
Dynamic update: cluster-wide

在刷新到磁盘前,任何主题中的消息保存在内存中的最长时间( ms)。如果没有设置,则使用 log.flush.scheduler.interval.ms 中的值。

log.flush.offset.checkpoint.interval.ms

type: int
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: high
Dynamic update: read-only

更新最后一次刷新的持久记录的频率,该记录充当日志恢复点。

log.flush.scheduler.interval.ms

type: long
Default: 9223372036854775807
Importance: high
Dynamic update: read-only

日志清除程序的频率(ms)检查是否需要清空到磁盘中的日志。

log.flush.start.offset.checkpoint.interval.ms

type: int
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: high
Dynamic update: read-only

我们更新日志启动偏移的永久记录的频率。

log.retention.bytes

Type: long
Default: -1
Importance: high
Dynamic update: cluster-wide

删除日志前的最大大小。

log.retention.hours

type: int
Default: 168
Importance: high
Dynamic update: read-only

删除日志文件前的小时数(以小时为单位),以及 log.retention.ms 属性的几小时数。

log.retention.minutes

type: int
Default: null
Importance: high
Dynamic update: read-only

在删除日志文件前(以分钟为单位)保留日志文件的分钟数,次要到 log.retention.ms 属性。如果没有设置,则使用 log.retention.hours 中的值。

log.retention.ms

Type: long
Default: null
Importance: high
Dynamic update: cluster-wide

删除日志文件前的毫秒数(以毫秒为单位),如果没有设置,则使用 log.retention.minutes 的值。如果设置为 -1,则不会应用时间限制。

log.roll.hours

type: int
Default: 168
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

推出新日志段前的最长时间(以小时为单位),二级到 log.roll.ms 属性。

log.roll.jitter.hours

type: int
Default: 0
Valid Values: [0,…​]
Importance: high
Dynamic update: read-only

从 logRollTimeMillis (以小时为单位)中减去的最大 jitter,次要到 log.roll.jitter.ms 属性。

log.roll.jitter.ms

Type: long
Default: null
Importance: high
Dynamic update: cluster-wide

从 logRollTimeMillis (以毫秒为单位)中减去的最大 jitter。如果没有设置,则使用 log.roll.jitter.hours 中的值。

log.roll.ms

Type: long
Default: null
Importance: high
Dynamic update: cluster-wide

推出新日志段前的最长时间(以毫秒为单位)。如果没有设置,则使用 log.roll.hours 中的值。

log.segment.bytes

type: int
Default: 1073741824 (1 gibibyte)
Valid Values: [14,…​]
Importance: high
Dynamic update: cluster-wide

单个日志文件的最大大小。

log.segment.delete.delay.ms

type: long
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: high
Dynamic update: cluster-wide

从文件系统中删除文件前等待的时间。

message.max.bytes

type: int
Default: 1048588
Valid Values: [0,…​]
Importance: high
Dynamic update: cluster-wide

Kafka 允许的最大记录批处理大小(如果启用了压缩,在压缩后进行压缩)。如果这被增加,且有 0.10.2 旧的消费者,还必须增加用户的获取大小,以便他们可以获取记录批处理。在最新的消息格式版本中,记录始终分组到批处理中,以获得效率。在以前的消息格式版本中,未压缩记录没有分组到批处理中,在这种情况下,这个限制仅适用于单个记录。可以使用主题级别 max.message.bytes 配置为每个主题设置。

metadata.log.dir

Type: string
Default: null
Importance: high
Dynamic update: read-only

此配置决定了将集群元数据日志放在 KRaft 模式的位置。如果没有设置,则元数据日志会放置在 log.dirs 的第一个日志目录中。

metadata.log.max.record.bytes.between.snapshots

type: long
Default: 20971520
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

这是生成新快照前日志的最大字节数,以及生成新快照前所需的高水位线之间的最大字节数。

metadata.log.segment.bytes

type: int
Default: 1073741824 (1 gibibyte)
Valid Values: [12,…​]
Importance: high
Dynamic update: read-only

单个元数据日志文件的最大大小。

metadata.log.segment.ms

Type: long
Default: 604800000 (7 days)
Importance: high
Dynamic update: read-only

推出新元数据日志文件前的最长时间(以毫秒为单位)。

metadata.max.retention.bytes

Type: long
Default: -1
Importance: high
Dynamic update: read-only

在删除旧快照和日志文件前,元数据日志和快照的最大组合大小。由于在任何日志可以被删除之前,至少有一个快照必须存在,所以这是一个软限制。

metadata.max.retention.ms

Type: long
Default: 604800000 (7 days)
Importance: high
Dynamic update: read-only

删除元数据日志文件或快照前的毫秒数。由于在任何日志可以被删除之前,至少有一个快照必须存在,所以这是一个软限制。

min.insync.replicas

type: int
Default: 1
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

当制作者将 acks 设为 "all" (或 "-1"),min.insync.replicas 指定必须确认写入的最少副本数才被视为成功。如果无法满足此最小值,则生成者将引发异常(NotEnoughReplicas 或 NotEnoughReplicasAfterAppend)。当一起使用时,min.insync.replicas 和 acks 允许您强制实施更大的持久性保证。典型的场景是创建带有复制因子 3 的主题,将 min.insync.replicas 设置为 2,并使用 acks of "all" 生成。这将确保如果大多数副本都未收到写入,则生成者引发异常。

node.id

type: int
Default: -1
Importance: high
Dynamic update: read-only

与此进程时所扮演的角色关联的节点 ID 。roles 是非空的。这在以 KRaft 模式运行时是必需的配置。

num.io.threads

type: int
Default: 8
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

服务器用来处理请求的线程数量,其中可能包括磁盘 I/O。

num.network.threads

type: int
Default: 3
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

服务器用来从网络接收请求并将响应发送到网络的线程数量。

num.recovery.threads.per.data.dir

type: int
Default: 1
Valid Values: [1,…​]
Importance: high
Dynamic update: cluster-wide

在启动时用于日志恢复的每个数据目录的线程数量,并在关闭时清除。

num.replica.alter.log.dirs.threads

type: int
Default: null
Importance: high
Dynamic update: read-only

可在日志目录之间移动副本的线程数量,其中可能包括磁盘 I/O。

num.replica.fetchers

Type: int
Default: 1
Importance: high
Dynamic update: cluster-wide

用于从源代理复制消息的获取程序线程数量。增加这个值可以提高后续代理中的 I/O 并行程度。

offset.metadata.max.bytes

Type: int
Default: 4096 (4 kibibytes)
Importance: high
Dynamic update: read-only

与偏移提交关联的元数据条目的最大大小。

offsets.commit.required.acks

Type: short
Default: -1
Importance: high
Dynamic update: read-only

在可以接受提交前所需的 acks。通常,默认(-1)不应被覆盖。

offsets.commit.timeout.ms

type: int
Default: 5000 (5 seconds)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

偏移提交会延迟,直到 offsets 主题的所有副本都接收提交或达到此超时为止。这与制作者请求超时类似。

offsets.load.buffer.size

type: int
Default: 5242880
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

将偏移加载到缓存中时从偏移段读取的批处理大小(如果记录太大,则覆盖)。

offsets.retention.check.interval.ms

type: long
Default: 600000 (10 minutes)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

检查过时偏移的频率。

offsets.retention.minutes

type: int
Default: 10080
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

在消费者组丢失了所有消费者(即变为空)后,在被丢弃前,将为此保留周期保留其偏移量。对于独立的消费者(使用手动分配),偏移将在最后一次提交加此保留周期后过期。

offsets.topic.compression.codec

Type: int
Default: 0
Importance: high
Dynamic update: read-only

偏移主题的压缩 codec - 压缩可用于实现"原子"提交。

offsets.topic.num.partitions

type: int
Default: 50
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

偏移提交主题的分区数量(部署后不应更改)。

offsets.topic.replication.factor

Type: short
Default: 3
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

偏移主题的复制因素(设置更高以确保可用性)。内部主题创建将失败,直到集群大小满足此复制因素要求。

offsets.topic.segment.bytes

type: int
Default: 104857600 (100 mebibytes)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

偏移主题片段字节数应该保持相对小,以便加快日志压缩和缓存负载。

process.roles

type: list
Default: ""
Valid Values: [broker, controller]
Importance: high
Dynamic update: read-only

此进程 play 的角色: 'broker'、'controller' 或 'broker,controller'(如果两者都是)。此配置仅适用于 KRaft (Kafka Raft)模式(而不是 ZooKeeper)中的集群。为 Zookeeper 集群保留此配置未定义或为空。

queued.max.requests

type: int
Default: 500
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

在阻止网络线程前,允许 data-plane 的已排队请求数。

replica.fetch.min.bytes

Type: int
Default: 1
Importance: high
Dynamic update: read-only

每个获取响应的预期最小字节数。如果没有足够字节,请等待 replica.fetch.wait.max.ms (broker config)。

replica.fetch.wait.max.ms

Type: int
Default: 500
Importance: high
Dynamic update: read-only

由后续副本发布的每个获取者请求的最大等待时间。这个值应该始终小于 replica.lag.time.max.ms,以防止频繁缩小 ISR 用于低吞吐量主题。

replica.high.watermark.checkpoint.interval.ms

Type: long
Default: 5000 (5 seconds)
Importance: high
Dynamic update: read-only

将高水位线保存到磁盘的频率。

replica.lag.time.max.ms

type: long
Default: 30000 (30 秒)
Importance: high
Dynamic update: read-only

如果后续者没有发送任何获取请求,或者还没有消耗领导日志结束偏移,则领导机将从 isr 中删除后续者。

replica.socket.receive.buffer.bytes

type: int
Default: 65536 (64 kibibytes)
Importance: high
Dynamic update: read-only

网络请求的套接字接收缓冲区。

replica.socket.timeout.ms

type: int
Default: 30000 (30 秒)
Importance: high
Dynamic update: read-only

网络请求的套接字超时。其值应至少为 replica.fetch.wait.max.ms。

request.timeout.ms

type: int
Default: 30000 (30 秒)
Importance: high
Dynamic update: read-only

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

sasl.mechanism.controller.protocol

Type: string
Default: GSSAPI
Importance: high
Dynamic update: read-only

用于与控制器通信的 SASL 机制。默认为 GSSAPI。

socket.receive.buffer.bytes

type: int
Default: 102400 (100 kibibytes)
Importance: high
Dynamic update: read-only

套接字服务器套接字的 SO_RCVBUF 缓冲。如果值为 -1,则使用操作系统默认值。

socket.request.max.bytes

type: int
Default: 104857600 (100 mebibytes)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

套接字请求中的最大字节数。

socket.send.buffer.bytes

type: int
Default: 102400 (100 kibibytes)
Importance: high
Dynamic update: read-only

套接字服务器套接字的 SO_SNDBUF 缓冲区。如果值为 -1,则使用操作系统默认值。

transaction.max.timeout.ms

type: int
Default: 900000 (15 minutes)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

事务允许的最大超时时间。如果客户端请求的事务时间超过这个值,则代理将在 InitProducerIdRequest 中返回错误。这可防止客户端太大的超时时间,这可能会使消费者从事务中包含的主题中读取。

transaction.state.log.load.buffer.size

type: int
Default: 5242880
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

将制作者 ID 和事务加载到缓存中时从事务日志片段读取的批处理大小(如果记录太大,则覆盖)。

transaction.state.log.min.isr

type: int
Default: 2
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

覆盖 min.insync.replicas 配置,用于事务主题。

transaction.state.log.num.partitions

type: int
Default: 50
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

事务主题的分区数量(部署后不应更改)。

transaction.state.log.replication.factor

Type: short
Default: 3
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

事务主题的复制因素(设置更高),以确保可用性。内部主题创建将失败,直到集群大小满足此复制因素要求。

transaction.state.log.segment.bytes

type: int
Default: 104857600 (100 mebibytes)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

事务主题片段字节数应该保持相对小,以便加快日志压缩和缓存负载。

transactional.id.expiration.ms

type: int
Default: 604800000 (7 days)
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

事务协调器将在不接收当前事务状态更新前等待的时间(毫秒)。此设置也会影响生成者 id 过期 - 制作者 ids 在最后一次使用给定制作者 id 写入后过期。请注意,因为主题的保留设置,如果从制作者 ID 最后一次写入被删除,则制作者 id 可能会更早过期。

unclean.leader.election.enable

Type: boolean
Default: false
Importance: high
Dynamic update: cluster-wide

指明是否启用 ISR 集中的副本作为最后的手段,即使这样做可能会导致数据丢失。

zookeeper.connect

Type: string
Default: null
Importance: high
Dynamic update: read-only

hostname:port 指定 ZooKeeper 连接字符串,其中 host 和 port 是 ZooKeeper 服务器的主机和端口。当 ZooKeeper 机器停机时,要允许连接到其他 ZooKeeper 节点,您还可以以 hostname1:port1,hostname2:port2,hostname3:port3 格式指定多个主机。服务器也可以具有 ZooKeeper chroot 路径作为其 ZooKeeper 连接字符串的一部分,将其数据置于全局 ZooKeeper 命名空间中的一些路径下。例如,要提供 chroot 路径 /chroot/path,您可以将连接字符串指定为 hostname1:port1,hostname2:port2,hostname3:port3/chroot/path

zookeeper.connection.timeout.ms

type: int
Default: null
Importance: high
Dynamic update: read-only

客户端等待建立与 zookeeper 的连接的最大时间。如果没有设置,则使用 zookeeper.session.timeout.ms 中的值。

zookeeper.max.in.flight.requests

type: int
Default: 10
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

客户端在阻止前发送到 Zookeeper 的最大未确认请求数。

zookeeper.session.timeout.ms

Type: int
Default: 18000 (18 seconds)
Importance: high
Dynamic update: read-only

ZooKeeper 会话超时。

zookeeper.set.acl

Type: boolean
Default: false
Importance: high
Dynamic update: read-only

将 client 设置为使用安全 ACL。

broker.heartbeat.interval.ms

type: int
Default: 2000 (2 seconds)
Importance: medium
Dynamic update: read-only

代理心跳之间时间长度(以毫秒为单位)。在 KRaft 模式下运行时使用。

broker.id.generation.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

在服务器上启用自动代理 ID 生成。启用为 reserved.broker.max.id 配置的值时,应检查。

broker.rack

Type: string
Default: null
Importance: medium
Dynamic update: read-only

代理的机架。这将用于机架感知为容错的复制分配。示例: RACK1、 us-east-1d.

broker.session.timeout.ms

type: int
Default: 9000 (9 seconds)
Importance: medium
Dynamic update: read-only

没有心跳时代理租期最后一次的时间长度(以毫秒为单位)。在 KRaft 模式下运行时使用。

connections.max.idle.ms

Type: long
Default: 600000 (10 minutes)
Importance: medium
Dynamic update: read-only

闲置连接超时:服务器套接字处理器线程关闭闲置超过这个连接。

connections.max.reauth.ms

Type: long
Default: 0
Importance: medium
Dynamic update: read-only

当明确设置为正数(默认值为 0,而不是正数)时,不会超过配置的值的会话生命周期会在验证时与 v2.2.0 或更高版本的客户端进行通信。代理将断开在会话生命周期中未重新验证的任何这样的连接,然后用于除重新身份验证以外的任何目的。配置名称可以选择在小写中使用监听程序前缀和 SASL 机制名称作为前缀。例如,listener.name.sasl_ssl.oauthbearer.connections.max.reauth.ms=3600000。

controlled.shutdown.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

启用服务器的受控关闭。

controlled.shutdown.max.retries

type: int
Default: 3
Importance: medium
Dynamic update: read-only

受控关闭可能会因为多个原因失败。这决定了发生此类失败时的重试次数。

controlled.shutdown.retry.backoff.ms

Type: long
Default: 5000 (5 seconds)
Importance: medium
Dynamic update: read-only

每次重试前,系统需要从导致之前失败的状态中恢复(Controller 故障转移、副本滞后等)。此配置决定了重试前等待的时间。

controller.quorum.append.linger.ms

type: int
Default: 25
Importance: medium
Dynamic update: read-only

领导领导将等待写入的时间(以毫秒为单位),然后再将它们刷新到磁盘。

controller.quorum.request.timeout.ms

type: int
Default: 2000 (2 seconds)
Importance: medium
Dynamic update: read-only

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

controller.socket.timeout.ms

type: int
Default: 30000 (30 秒)
Importance: medium
Dynamic update: read-only

controller-to-broker 频道的套接字超时。

default.replication.factor

Type: int
Default: 1
Importance: medium
Dynamic update: read-only

自动创建主题的默认复制因素。

delegation.token.expiry.time.ms

type: long
Default: 86400000 (1 day)
Valid Values: [1,…​]
Importance: medium
Dynamic update: read-only

需要续订令牌前,令牌的有效性时间(以 miliseconds 为单位)。默认值为 1 天。

delegation.token.master.key

Type: password
Default: null
Importance: medium
Dynamic update: read-only

DEPRECATED : delegation.token.secret.key 的别名,它应该被使用而不是此配置。

delegation.token.max.lifetime.ms

Type: long
Default: 604800000 (7 days)
Valid Values: [1,…​]
Importance: medium
Dynamic update: read-only

令牌具有最长生命周期,其无法再续订。默认值为 7 天。

delegation.token.secret.key

Type: password
Default: null
Importance: medium
Dynamic update: read-only

生成和验证委托令牌的 secret 密钥。必须在所有代理间配置相同的密钥。如果密钥未设置或设置为空字符串,代理将禁用委派令牌支持。

delete.records.purgatory.purge.interval.requests

Type: int
Default: 1
Importance: medium
Dynamic update: read-only

删除记录的清除间隔(请求数)

fetch.max.bytes

type: int
Default: 57671680 (55 mebibytes)
Valid Values: [1024,…​]
Importance: medium
Dynamic update: read-only

我们将返回获取请求的最大字节数。必须至少为 1024。

fetch.purgatory.purge.interval.requests

type: int
Default: 1000
Importance: medium
Dynamic update: read-only

获取请求的清除间隔(请求数)。

group.initial.rebalance.delay.ms

type: int
Default: 3000 (3 秒)
Importance: medium
Dynamic update: read-only

在执行第一次重新平衡前,组协调器将等待更多消费者加入新组的时间。较长的延迟意味着重新平衡可能会减少,但会增加处理开始的时间。

group.max.session.timeout.ms

Type: int
Default: 1800000 (30 minutes)
Importance: medium
Dynamic update: read-only

注册消费者允许的最大会话超时。超时时间较长,可让消费者在心跳之间处理消息的时间较长,以检测故障的时间。

group.max.size

type: int
Default: 2147483647
Valid Values: [1,…​]
Importance: medium
Dynamic update: read-only

单个消费者组可以容纳的最大消费者数量。

group.min.session.timeout.ms

type: int
Default: 6000 (6 seconds)
Importance: medium
Dynamic update: read-only

注册使用者允许的最小会话超时。超时时间较短,会导致在更频繁的消费者心跳的情况下更快地检测失败,这可能会造成代理资源的问题。

initial.broker.registration.timeout.ms

type: int
Default: 60000 (1 minute)
Importance: medium
Dynamic update: read-only

最初注册控制器仲裁时,在声明失败并退出代理进程前要等待的毫秒数。

inter.broker.listener.name

Type: string
Default: null
Importance: medium
Dynamic update: read-only

用于代理间通信的监听程序名称。如果未设置,监听程序名称由 security.inter.broker.protocol 定义。同时设置这个和 security.inter.broker.protocol 属性是一个错误。

inter.broker.protocol.version

Type: string
Default: 3.1-IV0
Valid Values: [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 1.1-IV0, 1.1-IV0, 1.1-IV0, 2.0-iv0, 2.0-iv1, 2.1-iv0, 2.1-iv1, 2.1-iv2, 2.2-iv0, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv1, 2.5-iv0, 2.6-iv0, 2.7-iv0, 2.7-iv1, 2.7-iv2, 2.8-iv0, 2.8-iv1, 3.0-iv0, 3.0-iv1, 3.0-iv0, 3.0-iv1, 3.1-IV0]
Importance: medium
Dynamic update: read-only

指定要使用的 inter-broker 协议的版本。这通常会在所有代理都升级到新版本后被禁止。一些有效值的示例为: 0.8.0, 0.8.1, 0.8.1.1, 0.8.2, 0.8.2.2.0, 0.8.2.1, 0.9.0.0, 0.9.0.1 Check ApiVersion for the full list。

log.cleaner.backoff.ms

type: long
Default: 15000 (15 秒)
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

没有日志清理时休眠的时间长度。

log.cleaner.dedupe.buffer.size

Type: long
Default: 134217728
Importance: medium
Dynamic update: cluster-wide

在所有清理线程中用于日志 deduplication 的总内存。

log.cleaner.delete.retention.ms

Type: long
Default: 86400000 (1 day)
Importance: medium
Dynamic update: cluster-wide

删除记录的保留的时长?

log.cleaner.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

启用日志清理程序,以在服务器上运行。如果使用包含 cleanup.policy=compact 的任何主题,则应启用,包括内部偏移主题。如果禁用了这些主题,则不会压缩并持续增大。

log.cleaner.io.buffer.load.factor

type: double
Default: 0.9
Importance: medium
Dynamic update: cluster-wide

Log cleaner deduer dedupe 缓冲区负载因素。去除重复缓冲区的百分比可能会变为。较高的值将允许一次清理更多日志,但会导致更多的哈希冲突。

log.cleaner.io.buffer.size

type: int
Default: 524288
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

在所有清理线程中用于日志清理 I/O 缓冲区的总内存。

log.cleaner.io.max.bytes.per.second

type: double
Default: 1.7976931348623157E308
Importance: medium
Dynamic update: cluster-wide

日志清理器将被节流,其 read 和 write i/o 的总和将小于这个值。

log.cleaner.max.compaction.lag.ms

type: long
Default: 9223372036854775807
Importance: medium
Dynamic update: cluster-wide

消息在日志中保留无法压缩的最长时间。仅适用于被压缩的日志。

log.cleaner.min.cleanable.ratio

type: double
Default: 0.5
Importance: medium
Dynamic update: cluster-wide

脏日志的最小比率,达到日志的总日志,以满足清理的要求。如果还指定了 log.cleaner.max.compaction.lag.ms 或 log.cleaner.min.compaction.lag.ms 配置,则日志紧凑器会在 log.cleaner.minaction.minaction.gms 期间内马上考虑压缩条件。 或(ii)如果日志在 log.cleaner.max.compaction.lag.ms 期间内有脏(uncompacted)记录。

log.cleaner.min.compaction.lag.ms

Type: long
Default: 0
Importance: medium
Dynamic update: cluster-wide

消息在日志中保持 uncompacted 的最短时间。仅适用于被压缩的日志。

log.cleaner.threads

type: int
Default: 1
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

用于日志清理的后台线程数量。

log.cleanup.policy

type: list
Default: delete
Valid Values: [compact, delete]
Importance: medium
Dynamic update: cluster-wide

除了保留窗口外的片段的默认清理策略。以逗号分隔的有效策略列表。有效策略包括:"delete" 和 "compact"。

log.index.interval.bytes

Type: int
Default: 4096 (4 kibibytes)
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

我们向偏移索引中添加条目的时间间隔。

log.index.size.max.bytes

type: int
Default: 10485760 (10 mebibytes)
Valid Values: [4,…​]
Importance: medium
Dynamic update: cluster-wide

偏移索引的最大大小(以字节为单位)。

log.message.format.version

Type: string
Default: 3.0-IV1
Valid Values: [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 1.1-IV0, 1.1-IV0, 2.0-iv0, 2.0-iv1, 2.1-iv0, 2.1-iv1, 2.1-iv2, 2.2-iv0, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv1, 2.5-iv0, 2.6-iv0, 2.7-iv0, 2.7-iv1, 2.7-iv2, 2.8-iv0, 2.8-iv1, 3.0-iv0, 3.0-iv1, 3.0-iv0, 3.0-iv1, 3.1-IV0]
Importance: medium
Dynamic update: read-only

指定代理用来将消息附加到日志中的消息格式版本。该值应该是一个有效的 ApiVersion。一些示例为:0.8.2, 0.9.0.0, 0.10.0,查看 ApiVersion 了解更多信息。通过设置特定的消息格式版本,用户认证磁盘上所有现有的消息是否都小于或等于指定版本。错误地设置这个值将导致具有旧版本的用户中断,因为它们会收到一个不理解的格式的消息。

log.message.timestamp.difference.max.ms

type: long
Default: 9223372036854775807
Importance: medium
Dynamic update: cluster-wide

代理收到消息和消息中指定的时间戳之间允许的最大区别。如果 log.message.timestamp.type=CreateTime,如果时间戳的差异超过这个阈值,则会被拒绝。如果 log.message.timestamp.type=LogAppendTime。允许的最大时间戳差异不应大于 log.retention.ms,以避免不必要频繁的日志滚动。

log.message.timestamp.type

Type: string
Default: CreateTime
Valid Values: [CreateTime, LogAppendTime]
Importance: medium
Dynamic update: cluster-wide

定义消息中的时间戳是消息创建时间还是日志附加时间。该值应该是 CreateTimeLogAppendTime

log.preallocate

Type: boolean
Default: false
Importance: medium
Dynamic update: cluster-wide

创建新段时,应预先分配文件?如果您在 Windows 上使用 Kafka,您可能需要将其设置为 true。

log.retention.check.interval.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [1,…​]
Importance: medium
Dynamic update: read-only

日志清理程序的频率(以毫秒为单位)检查任何日志是否有资格删除。

max.connection.creation.rate

type: int
Default: 2147483647
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

我们随时在代理中允许的最大连接创建率。也可以通过使用监听器前缀前缀配置监听程序级别的限制,如 listener.name.internal.max.connection.creation.rate.Broker-wide 连接速率限制,但应该根据应用程序要求配置监听程序限制。如果达到监听器或代理限制,则新连接将节流,但 inter-broker 监听程序除外。只有在达到监听器级别速率限制时,才会节流 inter-broker 侦听器上的连接。

max.connections

type: int
Default: 2147483647
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

我们随时允许的最大连接数。除了使用 max.connections.per.ip 配置的任何每个ip 限制外,还会应用这个限制。也可以通过使用监听程序前缀前缀(如 listener.name. internal.max.connections )为配置监听程序 级别的限制来配置。代理范围限制应该基于代理容量,而监听器限制则应该根据应用程序要求进行配置。如果达到监听程序或代理限制,则阻止新的连接。即使达到代理范围限制,也允许 inter-broker 侦听器上的连接。在这种情况下,其他监听器中最早使用的连接将关闭。

max.connections.per.ip

type: int
Default: 2147483647
Valid Values: [0,…​]
Importance: medium
Dynamic update: cluster-wide

我们允许从每个 ip 地址允许的最大连接数。如果使用 max.connections.per.ip.overrides 属性配置覆盖,则可以将其设置为 0。如果达到限制,则将丢弃来自 ip 地址的新连接。

max.connections.per.ip.overrides

Type: string
Default: ""
Importance: medium
Dynamic update: cluster-wide

每个ip 或 hostname 的逗号分隔列表覆盖默认最大连接数。示例值为 "hostName:100,127.0.0.1:200"。

max.incremental.fetch.session.cache.slots

type: int
Default: 1000
Valid Values: [0,…​]
Importance: medium
Dynamic update: read-only

我们将维护的最大增量获取会话数量。

num.partitions

type: int
Default: 1
Valid Values: [1,…​]
Importance: medium
Dynamic update: read-only

每个主题的默认日志分区数量。

password.encoder.old.secret

Type: password
Default: null
Importance: medium
Dynamic update: read-only

用于动态配置的编码密码的旧 secret。这只在更新 secret 时才需要。如果指定,所有动态编码的密码都使用这个旧 secret 进行解码,并在代理启动时使用 password.encoder.secret 重新编码。

password.encoder.secret

Type: password
Default: null
Importance: medium
Dynamic update: read-only

用于为这个代理动态配置的编码密码的 secret。

principal.builder.class

type: class
Default: org.apache.kafka.common.security.authenticator.DefaultKafkaPrincipalBuilder
Importance: medium
Dynamic update: per-broker

实现 KafkaPrincipalBuilder 接口的类的完全限定名称,用于构建授权期间使用的 KafkaPrincipal 对象。如果没有定义主体构建器,则默认行为取决于所使用的安全协议。对于 SSL 身份验证,主体将使用由与客户端证书区分名称(如果提供)的 ssl.principal.mapping.rules 定义的规则派生。否则,如果不需要客户端身份验证,则主体名称为 ANONYMOUS。对于 SASL 身份验证,如果 GSSAPI 正在使用中,则主体将使用 sasl.kerberos.principal.to.local.rules 定义的规则派生,以及其它机制的 SASL 身份验证 ID。对于 PLAINTEXT,主体将是 ANONYMOUS。

producer.purgatory.purge.interval.requests

type: int
Default: 1000
Importance: medium
Dynamic update: read-only

生成者请求的清除间隔(请求数)。

queued.max.request.bytes

Type: long
Default: -1
Importance: medium
Dynamic update: read-only

在没有读取更多请求前允许的排队字节数。

replica.fetch.backoff.ms

type: int
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: medium
Dynamic update: read-only

获取分区错误时休眠的时间长度。

replica.fetch.max.bytes

type: int
Default: 1048576 (1 mebibyte)
Valid Values: [0,…​]
Importance: medium
Dynamic update: read-only

尝试为每个分区获取的信息字节数。这不是绝对的最大值,如果获取的第一个非空分区中的第一个记录批处理大于这个值,则记录批处理仍会返回,以确保可以进行进度。代理接受的最大记录批处理大小通过 message.max.bytes (broker config)或 max.message.bytes (topic config)定义。

replica.fetch.response.max.bytes

type: int
Default: 10485760 (10 mebibytes)
Valid Values: [0,…​]
Importance: medium
Dynamic update: read-only

整个获取响应预期的最大字节数。记录批量获取,如果获取的第一个非空分区中的第一个记录批处理大于这个值,则记录批处理仍会返回,以确保可以进行进度。因此,这不是绝对最大值。代理接受的最大记录批处理大小通过 message.max.bytes (broker config)或 max.message.bytes (topic config)定义。

replica.selector.class

Type: string
Default: null
Importance: medium
Dynamic update: read-only

实现 ReplicaSelector 的完全限定类名称。代理使用它来查找首选读取副本。默认情况下,我们使用返回领导的实施。

reserved.broker.max.id

type: int
Default: 1000
Valid Values: [0,…​]
Importance: medium
Dynamic update: read-only

可用于 broker.id 的最大数量。

sasl.client.callback.handler.class

Type: class
Default: null
Importance: medium
Dynamic update: read-only

实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称。

sasl.enabled.mechanisms

type: list
Default: GSSAPI
Importance: medium
Dynamic update: per-broker

Kafka 服务器中启用的 SASL 机制列表。列表中可以包含安全提供程序可用的机制。只有 GSSAPI 会被默认启用。

sasl.jaas.config

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

用于 SASL 连接的 JAAS 登录上下文参数,其格式供 JAAS 配置文件使用。JAAS 配置文件格式描述 在此处。该值的格式是: loginModuleClass controlFlag (optionName=optionValue)*;。对于代理,配置必须在小写中带有监听前缀和 SASL 机制名称前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;。

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: medium
Dynamic update: per-broker

Kerberos kinit 命令路径。

sasl.kerberos.min.time.before.relogin

type: long
Default: 60000
Importance: medium
Dynamic update: per-broker

刷新尝试之间的登录线程睡眠时间。

sasl.kerberos.principal.to.local.rules

Type: list
Default: DEFAULT
Importance: medium
Dynamic update: per-broker

从主体名称映射到短名称(通常是操作系统用户名)的规则列表。规则按顺序评估,第一个与主体名称匹配的规则用于将其映射到短名称。稍后列表中的任何规则都会被忽略。默认情况下,形式 {username}/{hostname}@{REALM} 的主体名称映射到 {username}。有关格式的详情,请查看 安全授权和 acls。请注意,如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的扩展,则此配置会被忽略。

sasl.kerberos.service.name

Type: string
Default: null
Importance: medium
Dynamic update: per-broker

Kafka 运行的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 配置中定义。

sasl.kerberos.ticket.renew.jitter

type: double
Default: 0.05
Importance: medium
Dynamic update: per-broker

添加到续订时间的随机 jitter 的百分比。

sasl.kerberos.ticket.renew.window.factor

type: double
Default: 0.8
Importance: medium
Dynamic update: per-broker

登录线程将处于睡眠状态,直到达到最后一次刷新到票据到期的时间因素前处于睡眠状态,此时将尝试续订票据。

sasl.login.callback.handler.class

Type: class
Default: null
Importance: medium
Dynamic update: read-only

实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理,登录回调处理器配置必须以监听器前缀和 SASL 机制名称作为前缀作为前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

sasl.login.class

Type: class
Default: null
Importance: medium
Dynamic update: read-only

实现登录接口的类的完全限定名称。对于代理,登录配置必须在小写中带有监听前缀和 SASL 机制名称前缀。For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin.

sasl.login.refresh.buffer.seconds

Type: short
Default: 300
Importance: medium
Dynamic update: per-broker

在刷新凭证时凭证过期前的缓冲时间(以秒为单位)。如果刷新情况比缓冲区秒数接近过期,则刷新将移动,以尽可能多地维护缓冲区时间。法律值介于 0 到 3600 (1 小时)之间;如果没有指定值,则使用默认值 300 (5 分钟)。如果这个值和 sasl.login.refresh.min.period.seconds 超过了凭证剩余的生命周期,则忽略这个值。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.min.period.seconds

Type: short
Default: 60
Importance: medium
Dynamic update: per-broker

登录刷新线程在刷新凭证前等待的时间(以秒为单位)。法律值介于 0 到 900 (15 分钟)之间;如果没有指定值,则使用默认值 60 (1 分钟)。如果这个值和 sasl.login.refresh.buffer.seconds 都会被忽略,如果它们的总和超过凭证的剩余生命周期。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.factor

type: double
Default: 0.8
Importance: medium
Dynamic update: per-broker

登录刷新线程将休眠到与凭证生命周期相关的指定窗口因素,此时将尝试刷新凭证。法律值介于 0.5 (50%)和 1.0 (100%)之间,如果没有指定值,则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.jitter

type: double
Default: 0.05
Importance: medium
Dynamic update: per-broker

与凭证的生命周期相关的最大随机 jitter 量添加到登录刷新线程的睡眠时间中。法律值介于 0 到 0.25(25%)之间,如果没有指定值,则使用默认值 0.05(5%)。目前仅适用于 OAUTHBEARER。

sasl.mechanism.inter.broker.protocol

Type: string
Default: GSSAPI
Importance: medium
Dynamic update: per-broker

用于代理间通信的 SASL 机制。默认为 GSSAPI。

sasl.oauthbearer.jwks.endpoint.url

Type: string
Default: null
Importance: medium
Dynamic update: read-only

可以从中检索供应商的 JWKS (JSON Web Key Set) 的 OAuth/OIDC 供应商 URL。URL 可以是基于 HTTP (S)或基于文件的 URL。如果 URL 基于 HTTP (S),则 JWKS 数据将通过代理启动时配置的 URL 从 OAuth/OIDC 供应商中检索。所有 then-current 密钥都将缓存在代理上以进行传入请求。如果为 JWT 收到了身份验证请求,其中包含缓存中尚未在缓存中的"kid"标头声明值,则将根据需要再次查询 JWKS 端点。但是,代理会轮询每个 sasl.oauthbearer.jwks.endpoint.refresh.ms 毫秒的 URL,以便在收到包含这些密钥的任何 JWT 请求前刷新缓存。如果 URL 基于文件,代理将在启动时从配置的位置加载 JWKS 文件。如果 JWT 包含没有在 JWKS 文件中的 "kid" 标头值,代理将拒绝 JWT 并且身份验证将失败。

sasl.oauthbearer.token.endpoint.url

Type: string
Default: null
Importance: medium
Dynamic update: read-only

OAuth/OIDC 身份提供程序的 URL。如果 URL 基于 HTTP (S),这是签发者的令牌端点 URL,其请求将根据 sasl.jaas.config 中的配置登录。如果 URL 基于文件,它指定一个包含由 OAuth/OIDC 身份提供程序发布的访问令牌( JWT 序列化形式)的文件,以用于授权。

sasl.server.callback.handler.class

Type: class
Default: null
Importance: medium
Dynamic update: read-only

实现 AuthenticateCallbackHandler 接口的 SASL 服务器回调处理程序类的完全限定名称。服务器回调处理程序必须在小写中带有监听器前缀和 SASL 机制名称作为前缀。例如: listener.name.sasl_ssl.plain.sasl.server.callback.handler.class=com.example.CustomPlainCallbackHandler。

security.inter.broker.protocol

Type: string
Default: PLAINTEXT
Importance: medium
Dynamic update: read-only

用于在代理间进行通信的安全协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。这是一个同时设置这个和 inter.broker.listener.name 属性的错误。

socket.connection.setup.timeout.max.ms

type: long
Default: 30000 (30 秒)
Importance: medium
Dynamic update: read-only

客户端等待套接字连接建立的最大时间。当每个连续连接失败时,连接设置超时会达到这个最大值。为避免连接差异,将把一个随机化因值应用于超时,导致计算值高于 20% 的随机范围。

socket.connection.setup.timeout.ms

type: long
Default: 10000 (10 秒)
Importance: medium
Dynamic update: read-only

客户端等待套接字连接建立的时间长度。如果在超时时间前没有构建连接,客户端将关闭套接字频道。

ssl.cipher.suites

type: list
Default: ""
Importance: medium
Dynamic update: per-broker

密码套件列表。这是用来使用 TLS 或 SSL 网络协议协商网络连接的安全设置的身份验证、加密、MAC 和密钥交换算法的命名组合。默认情况下,支持所有可用的密码套件。

ssl.client.auth

Type: string
Default: none
Valid Values: [required, requested, none]
Importance: medium
Dynamic update: per-broker

配置 kafka 代理以请求客户端身份验证。以下设置是通用的:

  • 如果设为所需的客户端身份验证,则需要 ssl.client.auth=required
  • ssl.client.auth=requested 意味着客户端身份验证是可选的。与需要不同,如果设置此选项,则可以选择不提供有关其自身的身份验证信息
  • SSL.client.auth=none 意味着不需要客户端身份验证。
ssl.enabled.protocols

type: list
Default: TLSv1.2,TLSv1.3
Importance: medium
Dynamic update: per-broker

为 SSL 连接启用的协议列表。在使用 Java 11 或更新版本时,默认为 'TLSv1.2,TLSv1.3',否则 'TLSv1.2'。使用 Java 11 的默认值,如果客户端和服务器同时支持 TLSv1.3,则客户端和服务器将首选 TLSv1.3,否则将回退到 TLSv1.2(假设两者都至少支持 TLSv1.2)。对于大多数情况,这个默认值应该可以正常工作。另请参阅 ssl.protocol 的配置文档。

ssl.key.password

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

密钥存储文件或者 'ssl.keystore.key' 中指定的 PEM 密钥的密码。只有在配置了双向身份验证时,客户端才需要这样做。

ssl.keymanager.algorithm

Type: string
Default: SunX509
Importance: medium
Dynamic update: per-broker

密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。

ssl.keystore.certificate.chain

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

使用由 'ssl.keystore.type" 指定的格式的证书链。默认 SSL 引擎工厂仅支持使用 X.509 证书列表的 PEM 格式。

ssl.keystore.key

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

使用 'ssl.keystore.type" 指定的格式的私钥。默认 SSL 引擎工厂只支持使用 PKCS#8 密钥的 PEM 格式。如果密钥加密,必须使用 'ssl.key.password' 指定密钥密码。

ssl.keystore.location

Type: string
Default: null
Importance: medium
Dynamic update: per-broker

密钥存储文件的位置。这对客户端是可选的,可用于客户端进行双向身份验证。

ssl.keystore.password

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

密钥存储文件的存储密码。这对客户端是可选的,只有在配置了 'ssl.keystore.location' 时才需要。PEM 格式不支持密钥存储密码。

ssl.keystore.type

Type: string
Default: JKS
Importance: medium
Dynamic update: per-broker

密钥存储文件的文件格式。这对客户端是可选的。

ssl.protocol

type: string
Default: TLSv1.3
Importance: medium
Dynamic update: per-broker

用于生成 SSLContext 的 SSL 协议。使用 Java 11 或更新版本运行时,默认为 'TLSv1.3',否则 'TLSv1.2'。对于大多数用例,这个值应该可以正常工作。最近的 JVM 中允许的值为 'TLSv1.2' 和 'TLSv1.3'。旧的 JVM 可以支持 'TLS', 'TLSv1.1', 'SSLv2', 'SSLv2' 和 'SSLv3',但由于已知的安全漏洞,不建议使用它们。使用这个配置和 'ssl.enabled.protocols' 的默认值,如果服务器不支持 'TLSv1.3',客户端将降级为 'TLSv1.2'。如果此配置被设置为 'TLSv1.2',客户端将不会使用 'TLSv1.3',即使它是 ssl.enabled.protocols 中的值之一,服务器只支持 'TLSv1.3'。

ssl.provider

Type: string
Default: null
Importance: medium
Dynamic update: per-broker

用于 SSL 连接的安全供应商的名称。默认值是 JVM 的默认安全提供程序。

ssl.trustmanager.algorithm

Type: string
Default: PKIX
Importance: medium
Dynamic update: per-broker

信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。

ssl.truststore.certificates

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

可信证书,格式为 'ssl.truststore.type'。默认 SSL 引擎工厂仅支持使用 X.509 证书使用 PEM 格式。

ssl.truststore.location

Type: string
Default: null
Importance: medium
Dynamic update: per-broker

信任存储文件的位置。

ssl.truststore.password

Type: password
Default: null
Importance: medium
Dynamic update: per-broker

信任存储文件的密码。如果没有设置密码,则仍然使用配置的信任存储文件,但禁用完整性检查。PEM 格式不支持信任存储密码。

ssl.truststore.type

Type: string
Default: JKS
Importance: medium
Dynamic update: per-broker

信任存储文件的文件格式。

zookeeper.clientCnxnSocket

Type: string
Default: null
Importance: medium
Dynamic update: read-only

通常,在使用 TLS 连接到 ZooKeeper 时,将 org.apache.zookeeper.ClientCnxnSocketNetty 设置为 org.apache.zookeeper.ClientCnxnSocketNetty。覆盖通过同名 zookeeper.clientCnxnSocket 系统属性设置的任何显式值。

zookeeper.ssl.client.enable

Type: boolean
Default: false
Importance: medium
Dynamic update: read-only

将 client 设置为在连接到 ZooKeeper 时使用 TLS。显式值会覆盖通过 zookeeper.client.secure 系统属性设置的任何值(请注意不同的名称)。如果没有设置,则默认为 false;如果未设置 zookeeper.clientCnxnSocket nSocket (通常为 org.apache.zookeeper.ClientCnxnSocketNetty);其他值可以包括 zookeeper.ssl.cipher.suites, zookeeper.ssl.crl.enable ,zookeeper. ssl.enabled.protocols, zookeeper.ssl.endpoint.identification.algorithm,zookeeper.ssl.keystore.location,zookeeper.ssl.keystore.password,zookeeper.ssl.keystore.type,zookeeper.ssl.ocsp.enable,zookeeper.ssl.protocol,zookeeper.ssl.truststore.location, zookeeper.ssl.truststore.password,zookeeper.ssl.truststore.type.

zookeeper.ssl.keystore.location

Type: string
Default: null
Importance: medium
Dynamic update: read-only

将客户端证书与 ZooKeeper 的 TLS 连接一起使用时的密钥存储位置。覆盖通过 zookeeper.ssl.keyStore.location 系统属性设置的任何显式值(请注意 camelCase)。

zookeeper.ssl.keystore.password

Type: password
Default: null
Importance: medium
Dynamic update: read-only

将客户端证书与 ZooKeeper 的 TLS 连接一起使用时,密钥存储密码。覆盖通过 zookeeper.ssl.keyStore.password 系统属性设置的任何显式值(请注意 camelCase)。请注意,Zookeeper 不支持与密钥存储密码不同的密钥密码,因此请确保将密钥存储中的密钥密码设置为与密钥存储密码相同;否则,尝试 Zookeeper 的连接将失败。

zookeeper.ssl.keystore.type

Type: string
Default: null
Importance: medium
Dynamic update: read-only

将客户端证书与 ZooKeeper 的 TLS 连接一起使用时,密钥存储类型。覆盖通过 zookeeper.ssl.keyStore.type 系统属性设置的任何显式值(请注意 camelCase)。默认值 null 表示类型将根据密钥存储的文件名扩展名自动探测到。

zookeeper.ssl.truststore.location

Type: string
Default: null
Importance: medium
Dynamic update: read-only

使用 TLS 连接到 ZooKeeper 时的 truststore 位置。覆盖通过 zookeeper.ssl.trustStore.location 系统属性设置的任何显式值(请注意 camelCase)。

zookeeper.ssl.truststore.password

Type: password
Default: null
Importance: medium
Dynamic update: read-only

使用 TLS 连接到 ZooKeeper 时的 truststore 密码。覆盖通过 zookeeper.ssl.trustStore.password 系统属性设置的任何显式值(请注意 camelCase)。

zookeeper.ssl.truststore.type

Type: string
Default: null
Importance: medium
Dynamic update: read-only

使用 TLS 连接 ZooKeeper 时的 truststore 类型。覆盖通过 zookeeper.ssl.trustStore.type 系统属性设置的任何显式值(请注意 camelCase)。默认值 null 表示类型将根据信任存储的文件名扩展名自动探测到。

alter.config.policy.class.name

Type: class
Default: null
Importance: low
Dynamic update: read-only

应该用于验证的更改配置策略类。该类应实施 org.apache.kafka.server.policy.AlterConfigPolicy 接口。

alter.log.dirs.replication.quota.window.num

type: int
Default: 11
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

要在内存中保留的示例数量,用于更改日志目录复制配额。

alter.log.dirs.replication.quota.window.size.seconds

type: int
Default: 1
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

每个修改日志目录复制配额的时间范围。

authorizer.class.name

Type: string
Default: ""
Importance: low
Dynamic update: read-only

实现 org.apache.kafka.server.authorizer.Authorizer 接口的类的完全限定名称,代理将用于授权。

client.quota.callback.class

Type: class
Default: null
Importance: low
Dynamic update: read-only

实现 ClientQuotaCallback 接口的类的完全限定名称,用于决定应用到客户端请求的配额限制。默认情况下,会应用存储在 ZooKeeper 中的 <user>, <client-id>, <user> 或 <client-id> 配额。对于任何给定请求,会应用与会话的用户主体和请求的 client-id 匹配的最具体配额。

connection.failed.authentication.delay.ms

type: int
Default: 100
Valid Values: [0,…​]
Importance: low
Dynamic update: read-only

在失败的身份验证时连接关闭延迟:这是在身份验证失败时连接关闭的时间(以毫秒为单位)。这必须配置为小于 connection.max.idle.ms,以防止连接超时。

controller.quorum.retry.backoff.ms

type: int
Default: 20
Importance: low
Dynamic update: read-only

尝试重试对给定主题分区失败的请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

controller.quota.window.num

type: int
Default: 11
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

要在内存中为控制器修改配额保留的示例数量。

controller.quota.window.size.seconds

type: int
Default: 1
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

每个控制器修改配额的示例的时间跨度。

create.topic.policy.class.name

Type: class
Default: null
Importance: low
Dynamic update: read-only

应该用于验证的 create 主题策略类。该类应实施 org.apache.kafka.server.policy.CreateTopicPolicy 接口。

delegation.token.expiry.check.interval.ms

type: long
Default: 3600000 (1 hour)
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

扫描间隔,以删除已过期的委托令牌。

kafka.metrics.polling.interval.secs

type: int
Default: 10
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

指标轮询间隔(以秒为单位),可在 kafka.metrics.reporters 实现中使用。

kafka.metrics.reporters

Type: list
Default: ""
Importance: low
Dynamic update: read-only

用作 Yammer 指标定制报告器的类列表。报告者应该实现 kafka.metrics.KafkaMetricsReporter trait。如果客户端想要在自定义报告器上公开 JMX 操作,自定义报告器还需要实施一个 MBean 特征来扩展 kafka.metrics.KafkaMetricsReporterMBean 特征,以便注册的 MBean 符合标准的 MBean 约定。

listener.security.protocol.map

Type: string
Default: PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
Importance: low
Dynamic update: per-broker

在侦听器名称和安全协议之间进行映射。这必须针对同一安全协议定义,才能在多个端口或 IP 中使用。例如,即使两者都需要 SSL,也可以分隔内部和外部流量。另外,用户可以将名为 INTERNAL 和 EXTERNAL 的监听程序定义为: INTERNAL:SSL,EXTERNAL:SSL。如上所示,键和值使用冒号分隔,映射条目则用逗号分开。每个侦听器名称应当仅显示映射中的一次。可以通过向配置名称中添加规范化前缀(监听程序名称小写)来为每个监听程序配置不同的安全(SSL 和 SASL)设置。例如,要为 INTERNAL 侦听器设置不同的密钥存储,将设置名为 listener.name.internal.ssl.keystore.location 的配置。如果没有设置监听程序名称的配置,则配置将回退到通用配置(如 ssl.keystore.location)。请注意,在 KRaft 中,如果不提供显式映射且没有使用其他安全协议,则假定从 controller.listener.names 到 PLAINTEXT 定义的监听程序名称的默认映射。

log.message.downconversion.enable

Type: boolean
Default: true
Importance: low
Dynamic update: cluster-wide

此配置控制消息格式的下行是否启用以满足使用请求的使用。当设置为 false 时,代理不会为希望旧的消息格式的消费者执行 down-conversion。对于来自较旧的客户端的消费请求,代理会以 UNSUPPORTED_VERSION 错误响应。此配置不适用于复制可能需要的任何消息格式转换。

metric.reporters

Type: list
Default: ""
Importance: low
Dynamic update: cluster-wide

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Importance: low
Dynamic update: read-only

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

计算指标示例的时间窗口。

password.encoder.cipher.algorithm

type: string
Default: AES/CBC/PKCS5Padding
Importance: low
Dynamic update: read-only

用于动态配置的编码密码的 Cipher 算法。

password.encoder.iterations

type: int
Default: 4096
Valid Values: [1024,…​]
Importance: low
Dynamic update: read-only

用于动态配置的编码密码的迭代计数。

password.encoder.key.length

type: int
Default: 128
Valid Values: [8,…​]
Importance: low
Dynamic update: read-only

用于动态配置的编码密码的密钥长度。

password.encoder.keyfactory.algorithm

Type: string
Default: null
Importance: low
Dynamic update: read-only

用于动态配置的编码密码的 SecretKeyFactory 算法。如果可用,则默认为 PBKDF2WithHmacSHA512,否则为 PBKDF2WithHmacSHA1。

quota.window.num

type: int
Default: 11
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

要在内存中为客户端配额保留的示例数量。

quota.window.size.seconds

type: int
Default: 1
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

客户端配额的每个示例的时间跨度。

replication.quota.window.num

type: int
Default: 11
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

要在内存中为复制配额保留的示例数量。

replication.quota.window.size.seconds

type: int
Default: 1
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

复制配额的每个示例的时间跨度。

sasl.login.connect.timeout.ms

type: int
Default: null
Importance: low
Dynamic update: read-only

(可选)外部身份验证供应商连接超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.read.timeout.ms

type: int
Default: null
Importance: low
Dynamic update: read-only

(可选)外部身份验证供应商读取超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.max.ms

type: long
Default: 10000 (10 秒)
Importance: low
Dynamic update: read-only

(可选)登录尝试外部身份验证提供程序之间等待的最大等待值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.ms

Type: long
Default: 100
Importance: low
Dynamic update: read-only

(可选)登录尝试外部身份验证提供程序期间初始等待的值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.oauthbearer.clock.skew.seconds

type: int
Default: 30
Importance: low
Dynamic update: read-only

(可选)值(以秒为单位),允许 OAuth/OIDC 身份提供程序和代理间的差别。

sasl.oauthbearer.expected.audience

Type: list
Default: null
Importance: low
Dynamic update: read-only

(可选)代理用逗号分隔的设置来验证是否已为其中一个预期的受众发出 JWT。JWT 将检查是否有标准的 OAuth "aud" 声明,如果设置了这个值,代理将与 JWT 的"aud"声明中的值匹配,以查看是否有完全匹配。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.expected.issuer

Type: string
Default: null
Importance: low
Dynamic update: read-only

代理的 (可选)用于验证 JWT 是否已由预期签发者创建的(可选)设置。JWT 将检查是否有标准 OAuth "iss" 声明,如果设置了这个值,代理会完全匹配 JWT 的"iss"声明中的内容。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.jwks.endpoint.refresh.ms

Type: long
Default: 3600000 (1 hour)
Importance: low
Dynamic update: read-only

(可选)代理在刷新其 JWKS (JSON Web Key Set)缓存之间等待的值,其中包含键以验证 JWT 的签名。

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

type: long
Default: 10000 (10 秒)
Importance: low
Dynamic update: read-only

(可选)尝试从外部身份验证提供程序检索 JWKS (JSON Web Key Set)之间的最大等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

Type: long
Default: 100
Importance: low
Dynamic update: read-only

(可选)在 JWKS (JSON Web Key Set)检索外部身份验证提供程序尝试时的初始等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.scope.claim.name

Type: string
Default: scope
Importance: low
Dynamic update: read-only

范围的 OAuth 声明通常命名为 "scope",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以提供用于 JWT 有效负载声明中包含的范围的名称。

sasl.oauthbearer.sub.claim.name

Type: string
Default: sub
Importance: low
Dynamic update: read-only

该主题的 OAuth 声明通常命名为 "sub",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以为 JWT 有效负载的声明中包含的主题提供不同的名称。

security.providers

Type: string
Default: null
Importance: low
Dynamic update: read-only

每个返回供应商实施安全算法的可配置创建者类列表。这些类应实施 org.apache.kafka.common.security.auth.SecurityProviderCreator 接口。

ssl.endpoint.identification.algorithm

Type: string
Default: https
Importance: low
Dynamic update: per-broker

使用服务器证书验证服务器主机名的端点标识算法。

ssl.engine.factory.class

type: class
Default: null
Importance: low
Dynamic update: per-broker

org.apache.kafka.common.security.auth.SslEngineFactory 类型的类提供 SSLEngine 对象。默认值为 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

ssl.principal.mapping.rules

Type: string
Default: DEFAULT
Importance: low
Dynamic update: read-only

用于映射的规则列表,用于将名称与客户端证书区分到短名称。规则按顺序评估,第一个与主体名称匹配的规则用于将其映射到短名称。稍后列表中的任何规则都会被忽略。默认情况下,可区分 X.500 证书的名称将是主体。有关格式的详情,请查看 安全授权和 acls。请注意,如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的扩展,则此配置会被忽略。

ssl.secure.random.implementation

Type: string
Default: null
Importance: low
Dynamic update: per-broker

用于 SSL 加密操作的 SecureRandom PRNG 实施。

transaction.abort.timed.out.transaction.cleanup.interval.ms

type: int
Default: 10000 (10 秒)
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

回滚超时事务的时间间隔。

transaction.remove.expired.transaction.cleanup.interval.ms

type: int
Default: 3600000 (1 hour)
Valid Values: [1,…​]
Importance: low
Dynamic update: read-only

删除因为 transactional.id.expiration.ms 传递而过期的事务的时间间隔。

zookeeper.ssl.cipher.suites

Type: list
Default: null
Importance: low
Dynamic update: read-only

指定在 ZooKeeper TLS 协商(csv)中使用的启用的密码套件。覆盖通过 zookeeper.ssl.ciphersuites 系统属性明确设置的值(注意单个单词 "ciphersuites")。默认值 null 表示启用的密码套件列表由所使用的 Java 运行时决定。

zookeeper.ssl.crl.enable

Type: boolean
Default: false
Importance: low
Dynamic update: read-only

指定是否在 ZooKeeper TLS 协议中启用证书撤销列表。覆盖通过 zookeeper.ssl.crl 系统属性设置的任何显式值(请注意较短的名称)。

zookeeper.ssl.enabled.protocols

Type: list
Default: null
Importance: low
Dynamic update: read-only

指定 ZooKeeper TLS negotiate (csv)中启用的协议。覆盖通过 zookeeper.ssl.enabledProtocols 系统属性设置的任何显式值(请注意 camelCase)。默认值 null 表示启用的协议将是 zookeeper.ssl.protocol 配置属性值。

zookeeper.ssl.endpoint.identification.algorithm

Type: string
Default: HTTPS
Importance: low
Dynamic update: read-only

指定是否在 ZooKeeper TLS 协商过程中启用主机名验证,使用 (不区分大小写) "https" 表示启用 ZooKeeper 主机名验证,并有一个显式空白值表示它被禁用(仅用于测试目的)。显式值会覆盖通过 zookeeper.ssl.hostnameVerification 系统属性设置的任何 "true" 或 "false" 值(请注意不同的名称和值; true 表示 https 和 false 表示空白)。

zookeeper.ssl.ocsp.enable

Type: boolean
Default: false
Importance: low
Dynamic update: read-only

指定是否在 ZooKeeper TLS 协议中启用在线证书状态协议。覆盖通过 zookeeper.ssl.ocsp 系统属性设置的任何显式值(请注意较短的名称)。

zookeeper.ssl.protocol

type: string
Default: TLSv1.2
Importance: low
Dynamic update: read-only

指定 ZooKeeper TLS 协商中使用的协议。显式值会覆盖通过同名的 zookeeper.ssl.protocol 系统属性设置的任何值。

zookeeper.sync.time.ms

type: int
Default: 2000 (2 seconds)
Importance: low
Dynamic update: read-only

ZK 关注者可以落后于 ZK 的领导。

附录 B. 主题配置参数

cleanup.policy

type: list
Default: delete
Valid Values: [compact, delete]
Server Default Property: log.cleanup.policy
Importance: medium

为 "delete" 或 "compact" 的字符串。这个字符串指定要在旧日志片段中使用的保留策略。当达到保留时间或大小限制时,默认策略("删除")将丢弃旧的片段。"compact"设置将在主题上启用 日志压缩

compression.type

Type: string
Default: producer
Valid Values: [uncompressed, zstd, lz4, snappy, gzip, producer]
Server Default Property: compression.type
Importance: medium

指定给定主题的最终压缩类型。此配置接受标准压缩解码器('gzip', 'snappy', 'lz4', 'zstd')。它还接受等同于没有压缩的 'uncompressed';而 'producer' 表示保留由 producer 设置的原始压缩 codec。

delete.retention.ms

Type: long
Default: 86400000 (1 day)
Valid Values: [0,…​]
Server Default Property: log.cleaner.delete.retention.ms
Importance: medium

日志压缩主题保留 delete tombstone 标记的时间长度。此设置也会在消费者从偏移 0 开始读取的时间绑定,以确保它们获得最终阶段的有效快照(否则,可以在完成扫描前收集该 tombstones)。

file.delete.delay.ms

type: long
Default: 60000 (1 minute)
Valid Values: [0,…​]
Server Default Property: log.segment.delete.delay.ms
Importance: medium

从文件系统中删除文件前等待的时间。

flush.messages

type: long
Default: 9223372036854775807
Valid Values: [0,…​]
Server Default Property: log.flush.interval.messages
Importance: medium

此设置允许指定将强制写入日志的 fsync 数据的间隔。例如,如果将其设置为 1,则每个消息都会执行 fsync;如果这是 5 次,则每五个消息都会执行 fsync。通常,我们建议您不要这样做,并使用复制来实现持久性,并允许操作系统的后台清除功能,因为它效率更高。这个设置可根据每个主题覆盖(请参阅 每个主题配置部分)。

flush.ms

type: long
Default: 9223372036854775807
Valid Values: [0,…​]
Server Default Property: log.flush.interval.ms
Importance: medium

此设置允许指定将强制写入日志的 fsync 数据的时间间隔。例如,如果将其设置为 1000,则在 1000 毫秒被传递后将 fsync。通常,我们建议您不要这样做,并使用复制来实现持久性,并允许操作系统的后台清除功能,因为它效率更高。

follower.replication.throttled.replicas

type: list
Default: ""
Valid Values: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
Server Default Property: follower.replication.throttled.replicas
Importance: medium

应该在后续端节流日志复制的副本列表。该列表应该以 [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…​ 或者通配符 '*' 来节流这个主题的所有副本。

index.interval.bytes

type: int
Default: 4096 (4 kibibytes)
Valid Values: [0,…​]
Server Default Property: log.index.interval.bytes
Importance: medium

此设置控制 Kafka 在偏移索引中添加索引条目的频率。默认设置可确保我们索引一个大约每 4096 字节的消息。通过更多索引,读取可以更接近日志中的确切位置,但使索引变大。您可能不需要更改此设置。

leader.replication.throttled.replicas

type: list
Default: ""
Valid Values: [partitionId]:[brokerId],[partitionId],…​
Server Default Property: leader.replication.throttled.replicas
Importance: medium

日志复制应节流到领导端的副本列表。该列表应该以 [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…​ 或者通配符 '*' 来节流这个主题的所有副本。

max.compaction.lag.ms

type: long
Default: 9223372036854775807
Valid Values: [1,…​]
Server Default Property: log.cleaner.max.compaction.lag.ms
Importance: medium

消息在日志中保留无法压缩的最长时间。仅适用于被压缩的日志。

max.message.bytes

type: int
Default: 1048588
Valid Values: [0,…​]
Server Default Property: message.max.bytes
Importance: medium

Kafka 允许的最大记录批处理大小(如果启用了压缩,在压缩后进行压缩)。如果这被增加,且有 0.10.2 旧的消费者,还必须增加用户的获取大小,以便他们可以获取记录批处理。在最新的消息格式版本中,记录始终分组到批处理中,以获得效率。在以前的消息格式版本中,未压缩记录没有分组到批处理中,在这种情况下,这个限制只适用于单个记录。

message.format.version

Type: string
Default: 3.0-IV1
Valid Values: [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 1.1-IV0, 1.1-IV0, 2.0-iv0, 2.0-iv1, 2.1-iv0, 2.1-iv1, 2.1-iv2, 2.2-iv0, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv1, 2.5-iv0, 2.6-iv0, 2.7-iv0, 2.7-iv1, 2.7-iv2, 2.8-iv0, 2.8-iv1, 3.0-iv0, 3.0-iv1, 3.0-iv0, 3.0-iv1, 3.1-IV0]
服务器默认属性: log.message.format.version
Importance: medium

[DEPRECATED] 指定代理用来将消息附加到日志中的消息格式版本。如果 inter.broker.protocol.version3.0 或更高版本(实际配置值将被忽略),则始终假定此配置的值为 3.0。否则,该值应该是有效的 ApiVersion。一些示例包括: 0.10.0、1.1、2.8、3.0。通过设置特定的消息格式版本,用户认证磁盘上所有现有的消息是否都小于或等于指定版本。错误地设置这个值将导致具有旧版本的用户中断,因为它们会收到一个不理解的格式的消息。

message.timestamp.difference.max.ms

type: long
Default: 9223372036854775807
Valid Values: [0,…​]
Server Default Property: log.message.timestamp.difference.max.ms
Importance: medium

代理收到消息和消息中指定的时间戳之间允许的最大区别。如果 message.timestamp.type=CreateTime,如果时间戳的差异超过这个阈值,则会拒绝一条消息。如果 message.timestamp.type=LogAppendTime,则忽略此配置。

message.timestamp.type

type : string
Default: CreateTime
Valid Values: [CreateTime, LogAppendTime]
Server Default Property: log.message.timestamp.type
Importance: medium

定义消息中的时间戳是消息创建时间还是日志附加时间。该值应该是 CreateTimeLogAppendTime

min.cleanable.dirty.ratio

type: double
Default: 0.5
Valid Values: [0,…​,1]
Server Default Property: log.cleaner.min.cleanable.ratio
Importance: medium

此配置控制日志压缩器将尝试清理日志的频率(假设启用了 日志压缩 )。默认情况下,我们将避免清理日志超过 50% 的日志。这种比例使日志空间达到最大的空间(50% 最多 50% 的日志重复)。较高的比率将意味着较小的、效率更高,但意味着日志中有更多空间。如果还指定了 max.compaction.lag.ms 或 min.compaction.lag.ms 配置,则日志紧凑器会认为日志在 min.compaction.lag.ms 期间立即有资格进行压缩:(i)脏比率阈值,并且日志至少有 min.compaction.lag.ms 持续时间的脏(未紧凑)记录, 或(ii)如果日志在 max.compaction.lag.ms 期间内有脏(uncompacted)记录。

min.compaction.lag.ms

type: long
Default: 0
Valid Values: [0,…​]
Server Default Property: log.cleaner.min.compaction.lag.ms
Importance: medium

消息在日志中保持 uncompacted 的最短时间。仅适用于被压缩的日志。

min.insync.replicas

type: int
Default: 1
Valid Values: [1,…​]
Server Default Property: min.insync.replicas
Importance: medium

当制作者将 acks 设为 "all" (或 "-1"),此配置指定了必须确认写入的最小副本数才被视为成功。如果无法满足此最小值,则生成者将引发异常(NotEnoughReplicas 或 NotEnoughReplicasAfterAppend)。当一起使用时,min.insync.replicasacks 允许您强制实施更大的持久性保证。典型的场景是创建包含复制原因 3 的主题,将 min.insync.replicas 设置为 2,并使用 acks of "all" 生成。这将确保如果大多数副本都未收到写入,则生成者引发异常。

preallocate

type: boolean
Default: false
Server Default Property: log.preallocate
Importance: medium

如果我们在创建新日志段时,应该预先在磁盘上分配该文件则为 true。

retention.bytes

type: long
Default: -1
Server Default Property: log.retention.bytes
Importance: medium

此配置控制分区(由日志片段组成的)在我们使用"删除"保留策略时丢弃旧日志片段以释放空间的最大大小。默认情况下,只有时间限制没有大小限制。由于这个限制在分区级别强制实施,因此乘以分区数量来计算主题保留(以字节为单位)。

retention.ms

Type: long
Default: 604800000 (7 days)
Valid Values: [-1,…​]
Server Default Property: log.retention.ms
Importance: medium

此配置控制在我们使用"删除"保留策略之前,我们将保留日志段的最长时间,以释放空间。这代表了 SLA,即消费者必须多久才能读取其数据。如果设置为 -1,则不会应用时间限制。

segment.bytes

type: int
Default: 1073741824 (1 gibibyte)
Valid Values: [14,…​]
Server Default Property: log.segment.bytes
Importance: medium

此配置控制日志的片段文件大小。保留和清理始终会一次完成一个文件,因此大的片段大小意味着较少的文件,但对保留进行精细的控制。

segment.index.bytes

type: int
Default: 10485760 (10 mebibytes)
Valid Values: [0,…​]
Server Default Property: log.index.size.max.bytes
Importance: medium

此配置控制将偏移映射到文件位置的索引大小。我们预先分配此索引文件,并仅在日志滚动后缩小它。您通常不需要更改此设置。

segment.jitter.ms

type: long
Default: 0
Valid Values: [0,…​]
Server Default Property: log.roll.jitter.ms
Importance: medium

从调度的网段滚动时间中减去的最大随机 jitter,以避免理解网段滚动的混乱。

segment.ms

Type: long
Default: 604800000 (7 days)
Valid Values: [1,…​]
Server Default Property: log.roll.ms
Importance: medium

此配置控制 Kafka 将强制日志回滚的时间周期,即使片段文件没有满,以确保保留可以删除或压缩旧数据。

unclean.leader.election.enable

type: boolean
Default: false
Server Default Property: unclean.leader.election.enable
Importance: medium

指明是否启用 ISR 集中的副本作为最后的手段,即使这样做可能会导致数据丢失。

message.downconversion.enable

type: boolean
Default: true
Server Default Property: log.message.downconversion.enable
Importance: low

此配置控制消息格式的下行是否启用以满足使用请求的使用。当设置为 false 时,代理不会为希望旧的消息格式的消费者执行 down-conversion。对于来自较旧的客户端的消费请求,代理会以 UNSUPPORTED_VERSION 错误响应。此配置不适用于复制可能需要的任何消息格式转换。

附录 C. 消费者配置参数

key.deserializer

type: class
Importance: high

deserializer 类用于实现 org.apache.kafka.common.serialization.Deserializer 接口的密钥。

value.deserializer

type: class
Importance: high

deserializer 类用于实现 org.apache.kafka.common.serialization.Deserializer 接口的值。

bootstrap.servers

type: list
Default: ""
Valid Values: non-null string
Importance: high

用于建立到 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器与此处为引导指定的服务器无关 - 此列表仅影响用于发现完整服务器集的初始主机。此列表的格式应为 host1:port1,host2:port2,…​。由于这些服务器仅用于初始连接来发现完整的群集成员身份(可能会动态更改),因此此列表不需要包含整组服务器(但是如果服务器停机,您可能需要多个服务器)。

fetch.min.bytes

type: int
Default: 1
Valid Values: [0,…​]
Importance: high

服务器应返回的最小数据量,用于获取请求。如果数据不足,请求将等待这么多的数据在回答请求前累积。1 字节的默认设置表示,当一个字节数据可用时,或获取请求超时等待数据到达时,将立即回答获取请求。把它设置为大于 1 的内容将导致服务器等待大量数据累积,这可以提高服务器吞吐量,但有些额外的延迟。

group.id

Type: string
Default: null
Importance: high

标识此消费者所属的消费者组的唯一字符串。如果消费者使用 subscription (topic) 或基于 Kafka 的偏移管理策略,则需要此属性。

heartbeat.interval.ms

Type: int
Default: 3000 (3 秒)
Importance: high

使用 Kafka 的组管理功能时,与消费者协调器之间预期的时间。心跳用于确保消费者保持活跃状态,并在新用户加入或离开该组时促进重新平衡。该值必须小于 session.timeout.ms,但设置的值通常不应超过这个值的 1/3。它可以调整甚至较低,以控制正常重新平衡的预期时间。

max.partition.fetch.bytes

type: int
Default: 1048576 (1 mebibyte)
Valid Values: [0,…​]
Importance: high

服务器将返回的每个分区的最大数据量。记录由消费者批量获取。如果获取的第一个非空分区中的第一个记录批处理大于这个限制,则批处理仍会返回,以确保消费者能够进行进度。代理接受的最大记录批处理大小通过 message.max.bytes (broker config)或 max.message.bytes (topic config)定义。如需限制消费者请求大小,请参阅 fetch.max.bytes。

session.timeout.ms

Type: int
Default: 45000 (45 seconds)
Importance: high

使用 Kafka 的组管理功能时检测客户端故障的超时。客户端发送定期心跳以指示其存活度到代理。如果在这个会话超时前代理没有接收心跳,则代理将从组中删除此客户端并启动重新平衡。请注意,该值必须在允许范围内,如 group.min.session.timeout.msgroup.max.session.timeout.ms 中配置。

ssl.key.password

Type: password
Default: null
Importance: high

密钥存储文件或者 'ssl.keystore.key' 中指定的 PEM 密钥的密码。只有在配置了双向身份验证时,客户端才需要这样做。

ssl.keystore.certificate.chain

Type: password
Default: null
Importance: high

使用由 'ssl.keystore.type" 指定的格式的证书链。默认 SSL 引擎工厂仅支持使用 X.509 证书列表的 PEM 格式。

ssl.keystore.key

Type: password
Default: null
Importance: high

使用 'ssl.keystore.type" 指定的格式的私钥。默认 SSL 引擎工厂只支持使用 PKCS#8 密钥的 PEM 格式。如果密钥加密,必须使用 'ssl.key.password' 指定密钥密码。

ssl.keystore.location

Type: string
Default: null
Importance: high

密钥存储文件的位置。这对客户端是可选的,可用于客户端进行双向身份验证。

ssl.keystore.password

Type: password
Default: null
Importance: high

密钥存储文件的存储密码。这对客户端是可选的,只有在配置了 'ssl.keystore.location' 时才需要。PEM 格式不支持密钥存储密码。

ssl.truststore.certificates

Type: password
Default: null
Importance: high

可信证书,格式为 'ssl.truststore.type'。默认 SSL 引擎工厂仅支持使用 X.509 证书使用 PEM 格式。

ssl.truststore.location

Type: string
Default: null
Importance: high

信任存储文件的位置。

ssl.truststore.password

Type: password
Default: null
Importance: high

信任存储文件的密码。如果没有设置密码,则仍然使用配置的信任存储文件,但禁用完整性检查。PEM 格式不支持信任存储密码。

allow.auto.create.topics

Type: boolean
Default: true
Importance: medium

在订阅或分配主题时,允许对代理自动创建主题。只有在代理允许使用 auto.create.topics.enable 代理配置时,才会自动创建订阅的主题。当使用早于 0.11.0 的代理时,此配置必须设置为 false

auto.offset.reset

Type: string
Default: latest
Valid Values: [latest, earliest, none]
Importance: medium

当 Kafka 中没有初始偏移,或者服务器上不存在当前偏移时该怎么办(例如,因为数据已被删除):

  • 最早:自动将偏移重置为最早的偏移
  • latest :自动将偏移重置为最新的偏移
  • none:如果没有为消费者的组找到以前的偏移,则向消费者丢弃异常
  • 任何其他内容:向消费者抛出异常。
client.dns.lookup

Type: string
Default: use_all_dns_ips
Valid Values: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips,请按顺序连接到每个返回的 IP 地址,直到成功建立连接。断开连接后,会使用下一个 IP。当所有 IP 都被一次使用后,客户端会再次解析主机名(JVM 和 OS 缓存 DNS 名称查找)中的 IP。如果设置为 resolve_canonical_bootstrap_servers_only,请将每个 bootstrap 地址解析为规范名称列表。bootstrap 阶段后,它的行为与 use_all_dns_ips 相同。

connections.max.idle.ms

Type: long
Default: 540000 (9 minutes)
Importance: medium

在这个配置指定的毫秒数后关闭闲置连接。

default.api.timeout.ms

type: int
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: medium

指定客户端 API 的超时时间(以毫秒为单位)。此配置用作没有指定 timeout 参数的所有客户端操作的默认超时时间。

enable.auto.commit

Type: boolean
Default: true
Importance: medium

如果为 true,则消费者的偏移将在后台定期提交。

exclude.internal.topics

Type: boolean
Default: true
Importance: medium

订阅中是否应该排除与订阅模式匹配的内部主题。始终可以明确订阅内部主题。

fetch.max.bytes

type: int
Default: 52428800 (50 mebibytes)
Valid Values: [0,…​]
Importance: medium

服务器应返回的最大数据量,用于获取请求。记录批处理由消费者批量获取,如果获取的第一个非空分区中的第一个记录批处理大于这个值,则记录批处理仍会返回,以确保消费者进行进度。因此,这不是绝对最大值。代理接受的最大记录批处理大小通过 message.max.bytes (broker config)或 max.message.bytes (topic config)定义。请注意,消费者并行执行多个获取。

group.instance.id

Type: string
Default: null
Importance: medium

最终用户提供的消费者实例的唯一标识符。只允许非空字符串。如果设置,消费者被视为静态成员,这意味着任何时候都只允许具有此 ID 的一个实例。这可与更大的会话超时结合使用,以避免由临时不可用造成的组重新平衡(如进程重启)。如果没有设置,消费者将加入组作为动态成员,这是传统行为。

isolation.level

Type: string
Default: read_uncommitted
Valid Values: [read_committed, read_uncommitted]
Importance: medium

控制如何读取事务写的消息。如果设置为 read_committed,则 consumer.poll ()将仅返回已提交的事务消息。如果设置为 read_uncommitted (默认值),则 consumer.poll ()将返回所有消息,即使已中止的事务消息也是如此。非事务性消息将在任一模式中无条件返回。

消息将始终以偏移顺序返回。因此,在 read_committed 模式中,consumer.poll ()将仅返回最多最后一个稳定偏移(LSO)的消息,这是第一个打开事务的偏移量。特别是,在属于持续事务的消息后出现的任何消息都会被告知,直到相关事务完成为止。因此,在有机机交易时,read_committed 的消费者将无法读取高水位线。

Further, when in `read_committed` the seekToEnd method will return the LSO.
Copy to Clipboard Toggle word wrap
max.poll.interval.ms

Type: int
Default: 300000 (5 minutes)
Valid Values: [1,…​]
Importance: medium

使用消费者组管理时,poll ()调用之间的最大延迟。这会在获取更多记录前将上限放在消费者可以闲置的时间长度。如果在这个超时时间前没有调用 poll (),则消费者被视为失败,并且组将重新平衡,以便将分区重新分配给另一个成员。对于使用达到这个超时的非null group.instance.id 的用户,不会立即重新分配分区。相反,消费者将停止发送心跳,分区将在 session.timeout.ms 过期后被重新分配。这会镜像已关闭的静态消费者的行为。

max.poll.records

Type: int
Default: 500
Valid Values: [1,…​]
Importance: medium

单个调用返回到 poll ()中返回的最大记录数。请注意,max.poll.records 不会影响底层获取行为。消费者将从每个获取请求中缓存记录,并从每个轮询递增返回记录。

partition.assignment.strategy

Type: list
Default: class org.apache.kafka.clients.consumer.RangeAssignor,class org.apache.kafka.clients.consumer.CooperativeStickyAssignor
Valid Values: non-null string
Importance: medium

类名称或类类型列表,按首选顺序排列,在使用组管理时客户端将用于在消费者实例之间分发分区所有权。可用的选项有:

  • org.apache.kafka.clients.consumer.RangeAssignor: 根据每个主题分配分区。
  • org.apache.kafka.clients.consumer.RoundRobinAssignor: 以轮循方式将分区分配给消费者。
  • org.apache.kafka.clients.consumer.StickyAssignor: Guarantees 的一个分配量是最大平衡的,同时保留尽可能多的现有分区分配。
  • org.apache.kafka.clients.consumer.CooperativeStickyAssignor: Follows 相同的 StickyAssignor 逻辑,但允许合作重新平衡。

    默认分配器为 [RangeAssignor, CooperativeStickyAssignor],它默认使用 RangeAssignor,但允许升级到 CooperativeStickyAssignor,它只从列表中删除 RangeAssignor。

    通过实施 org.apache.kafka.clients.consumer.ConsumerPartitionAssignor 接口,您可以插入自定义分配策略。

receive.buffer.bytes

type: int
Default: 65536 (64 kibibytes)
Valid Values: [-1,…​]
Importance: medium

读取数据时要使用的 TCP 接收缓冲区(SO_RCVBUF)的大小。如果值为 -1,则使用操作系统默认值。

request.timeout.ms

type: int
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: medium

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

sasl.client.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称。

sasl.jaas.config

Type: password
Default: null
Importance: medium

用于 SASL 连接的 JAAS 登录上下文参数,其格式供 JAAS 配置文件使用。JAAS 配置文件格式描述 在此处。该值的格式是: loginModuleClass controlFlag (optionName=optionValue)*;。对于代理,配置必须在小写中带有监听前缀和 SASL 机制名称前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;。

sasl.kerberos.service.name

Type: string
Default: null
Importance: medium

Kafka 运行的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 配置中定义。

sasl.login.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理,登录回调处理器配置必须以监听器前缀和 SASL 机制名称作为前缀作为前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

sasl.login.class

Type: class
Default: null
Importance: medium

实现登录接口的类的完全限定名称。对于代理,登录配置必须在小写中带有监听前缀和 SASL 机制名称前缀。For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin.

sasl.mechanism

Type: string
Default: GSSAPI
Importance: medium

用于客户端连接的 SASL 机制。这可能是提供安全提供程序的任何机制。GSSAPI 是默认机制。

sasl.oauthbearer.jwks.endpoint.url

Type: string
Default: null
Importance: medium

可以从中检索供应商的 JWKS (JSON Web Key Set) 的 OAuth/OIDC 供应商 URL。URL 可以是基于 HTTP (S)或基于文件的 URL。如果 URL 基于 HTTP (S),则 JWKS 数据将通过代理启动时配置的 URL 从 OAuth/OIDC 供应商中检索。所有 then-current 密钥都将缓存在代理上以进行传入请求。如果为 JWT 收到了身份验证请求,其中包含缓存中尚未在缓存中的"kid"标头声明值,则将根据需要再次查询 JWKS 端点。但是,代理会轮询每个 sasl.oauthbearer.jwks.endpoint.refresh.ms 毫秒的 URL,以便在收到包含这些密钥的任何 JWT 请求前刷新缓存。如果 URL 基于文件,代理将在启动时从配置的位置加载 JWKS 文件。如果 JWT 包含没有在 JWKS 文件中的 "kid" 标头值,代理将拒绝 JWT 并且身份验证将失败。

sasl.oauthbearer.token.endpoint.url

Type: string
Default: null
Importance: medium

OAuth/OIDC 身份提供程序的 URL。如果 URL 基于 HTTP (S),这是签发者的令牌端点 URL,其请求将根据 sasl.jaas.config 中的配置登录。如果 URL 基于文件,它指定一个包含由 OAuth/OIDC 身份提供程序发布的访问令牌( JWT 序列化形式)的文件,以用于授权。

security.protocol

Type: string
Default: PLAINTEXT
Importance: medium

用于与代理通信的协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。

send.buffer.bytes

type: int
Default: 131072 (128 kibibytes)
Valid Values: [-1,…​]
Importance: medium

发送数据时要使用的 TCP 发送缓冲区(SO_SNDBUF)的大小。如果值为 -1,则使用操作系统默认值。

socket.connection.setup.timeout.max.ms

type: long
Default: 30000 (30 秒)
Importance: medium

客户端等待套接字连接建立的最大时间。当每个连续连接失败时,连接设置超时会达到这个最大值。为避免连接差异,将把一个随机化因值应用于超时,导致计算值高于 20% 的随机范围。

socket.connection.setup.timeout.ms

type: long
Default: 10000 (10 seconds)
Importance: medium

客户端等待套接字连接建立的时间长度。如果在超时时间前没有构建连接,客户端将关闭套接字频道。

ssl.enabled.protocols

type: list
Default: TLSv1.2,TLSv1.3
Importance: medium

为 SSL 连接启用的协议列表。在使用 Java 11 或更新版本时,默认为 'TLSv1.2,TLSv1.3',否则 'TLSv1.2'。使用 Java 11 的默认值,如果客户端和服务器同时支持 TLSv1.3,则客户端和服务器将首选 TLSv1.3,否则将回退到 TLSv1.2(假设两者都至少支持 TLSv1.2)。对于大多数情况,这个默认值应该可以正常工作。另请参阅 ssl.protocol 的配置文档。

ssl.keystore.type

Type: string
Default: JKS
Importance: medium

密钥存储文件的文件格式。这对客户端是可选的。

ssl.protocol

type: string
Default: TLSv1.3
Importance: medium

用于生成 SSLContext 的 SSL 协议。使用 Java 11 或更新版本运行时,默认为 'TLSv1.3',否则 'TLSv1.2'。对于大多数用例,这个值应该可以正常工作。最近的 JVM 中允许的值为 'TLSv1.2' 和 'TLSv1.3'。旧的 JVM 可以支持 'TLS', 'TLSv1.1', 'SSLv2', 'SSLv2' 和 'SSLv3',但由于已知的安全漏洞,不建议使用它们。使用这个配置和 'ssl.enabled.protocols' 的默认值,如果服务器不支持 'TLSv1.3',客户端将降级为 'TLSv1.2'。如果此配置被设置为 'TLSv1.2',客户端将不会使用 'TLSv1.3',即使它是 ssl.enabled.protocols 中的值之一,服务器只支持 'TLSv1.3'。

ssl.provider

Type: string
Default: null
Importance: medium

用于 SSL 连接的安全供应商的名称。默认值是 JVM 的默认安全提供程序。

ssl.truststore.type

Type: string
Default: JKS
Importance: medium

信任存储文件的文件格式。

auto.commit.interval.ms

Type: int
Default: 5000 (5 seconds)
Valid Values: [0,…​]
Importance: low

如果 enable.auto.commit 设置为 true,则消费者偏移的频率(以毫秒为单位)。

check.crcs

Type: boolean
Default: true
Importance: low

自动检查消耗的记录的 CRC32。这样可确保不会发生对消息进行 on-wire 或 on-disk 崩溃。此检查增加了一些开销,因此在寻求极佳性能的情况下可能会禁用它。

client.id

Type: string
Default: ""
Importance: low

在发出请求时传递给服务器的 id 字符串。这样做的目的是通过允许逻辑应用程序名称包含在服务器端请求日志记录中,从而跟踪除 ip/port 以外的请求源。

client.rack

Type: string
Default: ""
Importance: low

此客户端的机架标识符。这可以是任何字符串值,这表示此客户端物理位置。它与代理配置 'broker.rack' 对应。

fetch.max.wait.ms

Type: int
Default: 500
Valid Values: [0,…​]
Importance: low

如果没有足够的数据立即满足 fetch.min.bytes 提供的要求,服务器将在回答获取请求前阻断的最大时间。

interceptor.classes

type: list
Default: ""
Valid Values: non-null string
Importance: low

用作拦截器的类列表。通过实施 org.apache.kafka.clients.consumer.ConsumerInterceptor 接口,您可以截获(并可能修改)消费者收到的记录。默认情况下,没有拦截器。

metadata.max.age.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: low

即使我们未看到任何分区领导力更改来主动发现任何新的代理或分区,我们才会强制刷新元数据的时间(以毫秒为单位)。

metric.reporters

type: list
Default: ""
Valid Values: non-null string
Importance: low

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Valid Values: [INFO, DEBUG, TRACE]
Importance: low

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

计算指标示例的时间窗口。

reconnect.backoff.max.ms

type: long
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: low

重新连接到重复连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供,每个主机的 backoff 将为每个连续的连接失败指数增加,直到最高值。在计算 backoff 增长后,添加了 20% 的随机 jitter,以避免连接状况。

reconnect.backoff.ms

type: long
Default: 50
Valid Values: [0,…​]
Importance: low

尝试重新连接到给定主机前等待的基本时间。这可避免在紧密循环中重复连接到主机。此 backoff 应用到客户端到代理的所有连接尝试。

retry.backoff.ms

Type: long
Default: 100
Valid Values: [0,…​]
Importance: low

尝试重试对给定主题分区失败的请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: low

Kerberos kinit 命令路径。

sasl.kerberos.min.time.before.relogin

Type: long
Default: 60000
Importance: low

刷新尝试之间的登录线程睡眠时间。

sasl.kerberos.ticket.renew.jitter

type: double
Default: 0.05
Importance: low

添加到续订时间的随机 jitter 的百分比。

sasl.kerberos.ticket.renew.window.factor

Type: double
Default: 0.8
Importance: low

登录线程将处于睡眠状态,直到达到最后一次刷新到票据到期的时间因素前处于睡眠状态,此时将尝试续订票据。

sasl.login.connect.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商连接超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.read.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商读取超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.buffer.seconds

Type: short
Default: 300
Valid Values: [0,…​,3600]
Importance: low

在刷新凭证时凭证过期前的缓冲时间(以秒为单位)。如果刷新情况比缓冲区秒数接近过期,则刷新将移动,以尽可能多地维护缓冲区时间。法律值介于 0 到 3600 (1 小时)之间;如果没有指定值,则使用默认值 300 (5 分钟)。如果这个值和 sasl.login.refresh.min.period.seconds 超过了凭证剩余的生命周期,则忽略这个值。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.min.period.seconds

Type: short
Default: 60
Valid Values: [0,…​,900]
Importance: low

登录刷新线程在刷新凭证前等待的时间(以秒为单位)。法律值介于 0 到 900 (15 分钟)之间;如果没有指定值,则使用默认值 60 (1 分钟)。如果这个值和 sasl.login.refresh.buffer.seconds 都会被忽略,如果它们的总和超过凭证的剩余生命周期。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.factor

type: double
Default: 0.8
Valid Values: [0.5,…​,1.0]
Importance: low

登录刷新线程将休眠到与凭证生命周期相关的指定窗口因素,此时将尝试刷新凭证。法律值介于 0.5 (50%)和 1.0 (100%)之间,如果没有指定值,则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.jitter

type: double
Default: 0.05
Valid Values: [0.0,…​,0.25]
Importance: low

与凭证的生命周期相关的最大随机 jitter 量添加到登录刷新线程的睡眠时间中。法律值介于 0 到 0.25(25%)之间,如果没有指定值,则使用默认值 0.05(5%)。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)登录尝试外部身份验证提供程序之间等待的最大等待值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)登录尝试外部身份验证提供程序期间初始等待的值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.oauthbearer.clock.skew.seconds

Type: int
Default: 30
Importance: low

(可选)值(以秒为单位),允许 OAuth/OIDC 身份提供程序和代理间的差别。

sasl.oauthbearer.expected.audience

Type: list
Default: null
Importance: low

(可选)代理用逗号分隔的设置来验证是否已为其中一个预期的受众发出 JWT。JWT 将检查是否有标准的 OAuth "aud" 声明,如果设置了这个值,代理将与 JWT 的"aud"声明中的值匹配,以查看是否有完全匹配。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.expected.issuer

Type: string
Default: null
Importance: low

代理的 (可选)用于验证 JWT 是否已由预期签发者创建的(可选)设置。JWT 将检查是否有标准 OAuth "iss" 声明,如果设置了这个值,代理会完全匹配 JWT 的"iss"声明中的内容。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.jwks.endpoint.refresh.ms

Type: long
Default: 3600000 (1 hour)
Importance: low

(可选)代理在刷新其 JWKS (JSON Web Key Set)缓存之间等待的值,其中包含键以验证 JWT 的签名。

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)尝试从外部身份验证提供程序检索 JWKS (JSON Web Key Set)之间的最大等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)在 JWKS (JSON Web Key Set)检索外部身份验证提供程序尝试时的初始等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.scope.claim.name

Type: string
Default: scope
Importance: low

范围的 OAuth 声明通常命名为 "scope",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以提供用于 JWT 有效负载声明中包含的范围的名称。

sasl.oauthbearer.sub.claim.name

Type: string
Default: sub
Importance: low

该主题的 OAuth 声明通常命名为 "sub",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以为 JWT 有效负载的声明中包含的主题提供不同的名称。

security.providers

Type: string
Default: null
Importance: low

每个返回供应商实施安全算法的可配置创建者类列表。这些类应实施 org.apache.kafka.common.security.auth.SecurityProviderCreator 接口。

ssl.cipher.suites

Type: list
Default: null
Importance: low

密码套件列表。这是用来使用 TLS 或 SSL 网络协议协商网络连接的安全设置的身份验证、加密、MAC 和密钥交换算法的命名组合。默认情况下,支持所有可用的密码套件。

ssl.endpoint.identification.algorithm

Type: string
Default: https
Importance: low

使用服务器证书验证服务器主机名的端点标识算法。

ssl.engine.factory.class

Type: class
Default: null
Importance: low

org.apache.kafka.common.security.auth.SslEngineFactory 类型的类提供 SSLEngine 对象。默认值为 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

ssl.keymanager.algorithm

Type: string
Default: SunX509
Importance: low

密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。

ssl.secure.random.implementation

Type: string
Default: null
Importance: low

用于 SSL 加密操作的 SecureRandom PRNG 实施。

ssl.trustmanager.algorithm

Type: string
Default: PKIX
Importance: low

信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。

附录 D. 生成者配置参数

key.serializer

type: class
Importance: high

serializer 类用于实现 org.apache.kafka.common.serialization.Serializer 接口的密钥。

value.serializer

type: class
Importance: high

Serializer 类用于实现 org.apache.kafka.common.serialization.Serializer 接口的值。

bootstrap.servers

type: list
Default: ""
Valid Values: non-null string
Importance: high

用于建立到 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器与此处为引导指定的服务器无关 - 此列表仅影响用于发现完整服务器集的初始主机。此列表的格式应为 host1:port1,host2:port2,…​。由于这些服务器仅用于初始连接来发现完整的群集成员身份(可能会动态更改),因此此列表不需要包含整组服务器(但是如果服务器停机,您可能需要多个服务器)。

buffer.memory

type: long
Default: 33554432
Valid Values: [0,…​]
Importance: high

制作者可用于缓冲记录等待发送到服务器的内存总量。如果发送记录速度快于可以发送到服务器,则生成者将阻止 max.block.ms 引发异常。

此设置应当与生成者将使用的内存总量对应,但不是硬绑定,因为生产者使用的所有内存都用于缓冲。一些额外的内存将用于压缩(如果启用了压缩),以及维护动态请求。

compression.type

Type: string
Default: none
Importance: high

producer 生成的所有数据的压缩类型。默认为 none (例如,没有压缩)。有效值为 none,gzip,snappy,lz4, 或 zstd。压缩是整个数据的批处理,因此批处理的效率也会影响压缩率(更多批处理意味着更好的压缩)。

retries

type: int
Default: 2147483647
Valid Values: [0,…​,2147483647]
Importance: high

设置大于零的值将导致客户端重新发送发送失败的记录,并显示潜在的临时错误。请注意,这个重试与在收到错误时重新记录不同的是不同的。在不设置 max.in.flight.requests.per.connection 到 1 的重试的情况下,可能会更改记录顺序,因为如果两个批处理发送到单个分区,第一个批处理失败,但第二个批处理中的记录可能会首先出现。请注意,如果在通过 delivery.timeout.ms 配置超时前,生成请求将失败,然后再成功确认前过期。用户通常应不设置此配置,而是使用 delivery.timeout.ms 来控制重试行为。

ssl.key.password

Type: password
Default: null
Importance: high

密钥存储文件或者 'ssl.keystore.key' 中指定的 PEM 密钥的密码。只有在配置了双向身份验证时,客户端才需要这样做。

ssl.keystore.certificate.chain

Type: password
Default: null
Importance: high

使用由 'ssl.keystore.type" 指定的格式的证书链。默认 SSL 引擎工厂仅支持使用 X.509 证书列表的 PEM 格式。

ssl.keystore.key

Type: password
Default: null
Importance: high

使用 'ssl.keystore.type" 指定的格式的私钥。默认 SSL 引擎工厂只支持使用 PKCS#8 密钥的 PEM 格式。如果密钥加密,必须使用 'ssl.key.password' 指定密钥密码。

ssl.keystore.location

Type: string
Default: null
Importance: high

密钥存储文件的位置。这对客户端是可选的,可用于客户端进行双向身份验证。

ssl.keystore.password

Type: password
Default: null
Importance: high

密钥存储文件的存储密码。这对客户端是可选的,只有在配置了 'ssl.keystore.location' 时才需要。PEM 格式不支持密钥存储密码。

ssl.truststore.certificates

Type: password
Default: null
Importance: high

可信证书,格式为 'ssl.truststore.type'。默认 SSL 引擎工厂仅支持使用 X.509 证书使用 PEM 格式。

ssl.truststore.location

Type: string
Default: null
Importance: high

信任存储文件的位置。

ssl.truststore.password

Type: password
Default: null
Importance: high

信任存储文件的密码。如果没有设置密码,则仍然使用配置的信任存储文件,但禁用完整性检查。PEM 格式不支持信任存储密码。

batch.size

type: int
Default: 16384
Valid Values: [0,…​]
Importance: medium

每当将多个记录发送到同一分区时,生成者将尝试将记录一起批处理到较少的请求。这有助于客户端和服务器的性能。此配置控制默认批处理大小(以字节为单位)。

不会尝试批处理记录大于这个大小。

发送到代理的请求将包含多个批处理,每个分区对应一个数据可以发送。

小批处理大小会减少批处理频率,并可能会降低吞吐量(零的批处理将完全禁用批处理)。非常大的批处理大小可能会更严重地使用内存,因为我们将始终在附加记录下分配指定批处理大小的缓冲。

注意:此设置提供要发送的批处理大小的上限。如果我们为这个分区积累的数量少于此指定的字节,那么我们会"闲置" linger.ms 时间来等待更多记录。这个 linger.ms 设置默认为 0,这意味着我们将立即发送记录,即使累积的批处理大小位于这个 batch.size 设置下。

client.dns.lookup

Type: string
Default: use_all_dns_ips
Valid Values: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips,请按顺序连接到每个返回的 IP 地址,直到成功建立连接。断开连接后,会使用下一个 IP。当所有 IP 都被一次使用后,客户端会再次解析主机名(JVM 和 OS 缓存 DNS 名称查找)中的 IP。如果设置为 resolve_canonical_bootstrap_servers_only,请将每个 bootstrap 地址解析为规范名称列表。bootstrap 阶段后,它的行为与 use_all_dns_ips 相同。

client.id

Type: string
Default: ""
Importance: medium

在发出请求时传递给服务器的 id 字符串。这样做的目的是通过允许逻辑应用程序名称包含在服务器端请求日志记录中,从而跟踪除 ip/port 以外的请求源。

connections.max.idle.ms

Type: long
Default: 540000 (9 minutes)
Importance: medium

在这个配置指定的毫秒数后关闭闲置连接。

delivery.timeout.ms

type: int
Default: 120000 (2 minutes)
Valid Values: [0,…​]
Importance: medium

在调用 send () 返回后报告成功或失败的上限。这限制了发送前记录总时间、从代理等待确认时间(如果预期),以及可重新发送失败的时间。如果遇到了无法恢复的错误,则生成者可能报告无法发送记录,或者将记录添加到达到早期交付过期期限的批处理中。此配置的值应大于或等于 request.timeout.mslinger.ms 的总和。

linger.ms

type: long
Default: 0
Valid Values: [0,…​]
Importance: medium

生产者将请求传输之间到达单个批处理请求的任何记录组合在一起。通常,这只在记录到达速度快于发送时发生。然而,在某些情况下,客户端可能希望减少请求的数量,即使负载低下也是如此。此设置通过添加少量人工延迟来实现此目的,即不是立即发送记录,而是等待到给定延迟,允许发送其他记录。这可能被视为与 TCP 中的 Nagle 算法类似。此设置提供批处理延迟的上限:一旦我们获得 批处理。 无论此设置如何,无论此设置如何,它都会立即发送一次记录,但是如果我们为此分区累积了这个字节,我们将"linger"用于等待更多记录显示。此设置默认为 0 (例如,无延迟)。例如,设置 linger.ms=5 会影响减少发送的请求数,但会在没有负载的情况下向发送的记录添加最多 5ms 的延迟。

max.block.ms

type: long
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: medium

这个配置控制 KafkaProducer’s `send(), partitionsFor(), initTransactions(), sendOffsetsToTransaction(), commitTransaction() and abortTransaction() 方法将被阻塞多长时间。对于 send (),这个超时会绑定了元数据获取和缓冲区分配的总时间(在用户提供的 serializers 或 partitioner 中不会计算这个超时)。对于 partitionsFor (),这个超时会绑定等待元数据的时间(如果其不可用)。与事务相关的方法始终阻止,但如果事务协调器无法发现或没有在超时时间内响应,则可能会超时。

max.request.size

type: int
Default: 1048576
Valid Values: [0,…​]
Importance: medium

请求的最大大小(以字节为单位)。此设置将限制制作者将在单个请求中发送的记录批处理数量,以避免发送大量请求。这也实际上是最大未压缩的记录批处理大小的上限。请注意,服务器在记录批处理大小上具有自己的上限(如果启用了压缩,则进行压缩后),这可能与此不同。

partitioner.class

type: class
Default: org.apache.kafka.clients.producer.internals.DefaultPartitioner
Importance: medium

一个类,用于决定在生成记录时要发送到哪个分区。可用的选项有:

  • org.apache.kafka.clients.producer.internals.DefaultPartitioner: 默认分区器。此策略将尝试在批处理已满或 linger.ms 之前放弃分区。它可用于策略:
  • 如果没有指定分区,但存在一个密钥,请根据密钥的哈希值选择一个分区
  • 如果没有分区或密钥,请选择批处理已满或 linger.ms 时更改的粘性分区。
  • org.apache.kafka.clients.producer.RoundRobinPartitioner :此分区策略是将一系列连续记录中的每个记录发送到不同的分区(无论我们提供了 'key' 或 not),直到我们耗尽分区并再次开始。注意:存在一个已知问题,在创建新批处理时会导致不均匀分布。请检查 KAFKA-9965 以获取更多详细信息。
  • org.apache.kafka.clients.producer.UniformStickyPartitioner :此分区策略将尝试坚持使用分区(无论提供了 'key' 或 linger.ms 为 up)。

    通过实施 org.apache.kafka.clients.producer.Partitioner 接口,您可以插入自定义分区程序。

receive.buffer.bytes

type: int
Default: 32768 (32 kibibytes)
Valid Values: [-1,…​]
Importance: medium

读取数据时要使用的 TCP 接收缓冲区(SO_RCVBUF)的大小。如果值为 -1,则使用操作系统默认值。

request.timeout.ms

type: int
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: medium

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。这应该大于 replica.lag.time.max.ms (代理配置),以减少因为不必要的制作者重试而出现消息重复的可能性。

sasl.client.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称。

sasl.jaas.config

Type: password
Default: null
Importance: medium

用于 SASL 连接的 JAAS 登录上下文参数,其格式供 JAAS 配置文件使用。JAAS 配置文件格式描述 在此处。该值的格式是: loginModuleClass controlFlag (optionName=optionValue)*;。对于代理,配置必须在小写中带有监听前缀和 SASL 机制名称前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;。

sasl.kerberos.service.name

Type: string
Default: null
Importance: medium

Kafka 运行的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 配置中定义。

sasl.login.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理,登录回调处理器配置必须以监听器前缀和 SASL 机制名称作为前缀作为前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

sasl.login.class

Type: class
Default: null
Importance: medium

实现登录接口的类的完全限定名称。对于代理,登录配置必须在小写中带有监听前缀和 SASL 机制名称前缀。For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin.

sasl.mechanism

Type: string
Default: GSSAPI
Importance: medium

用于客户端连接的 SASL 机制。这可能是提供安全提供程序的任何机制。GSSAPI 是默认机制。

sasl.oauthbearer.jwks.endpoint.url

Type: string
Default: null
Importance: medium

可以从中检索供应商的 JWKS (JSON Web Key Set) 的 OAuth/OIDC 供应商 URL。URL 可以是基于 HTTP (S)或基于文件的 URL。如果 URL 基于 HTTP (S),则 JWKS 数据将通过代理启动时配置的 URL 从 OAuth/OIDC 供应商中检索。所有 then-current 密钥都将缓存在代理上以进行传入请求。如果为 JWT 收到了身份验证请求,其中包含缓存中尚未在缓存中的"kid"标头声明值,则将根据需要再次查询 JWKS 端点。但是,代理会轮询每个 sasl.oauthbearer.jwks.endpoint.refresh.ms 毫秒的 URL,以便在收到包含这些密钥的任何 JWT 请求前刷新缓存。如果 URL 基于文件,代理将在启动时从配置的位置加载 JWKS 文件。如果 JWT 包含没有在 JWKS 文件中的 "kid" 标头值,代理将拒绝 JWT 并且身份验证将失败。

sasl.oauthbearer.token.endpoint.url

Type: string
Default: null
Importance: medium

OAuth/OIDC 身份提供程序的 URL。如果 URL 基于 HTTP (S),这是签发者的令牌端点 URL,其请求将根据 sasl.jaas.config 中的配置登录。如果 URL 基于文件,它指定一个包含由 OAuth/OIDC 身份提供程序发布的访问令牌( JWT 序列化形式)的文件,以用于授权。

security.protocol

Type: string
Default: PLAINTEXT
Importance: medium

用于与代理通信的协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。

send.buffer.bytes

type: int
Default: 131072 (128 kibibytes)
Valid Values: [-1,…​]
Importance: medium

发送数据时要使用的 TCP 发送缓冲区(SO_SNDBUF)的大小。如果值为 -1,则使用操作系统默认值。

socket.connection.setup.timeout.max.ms

type: long
Default: 30000 (30 秒)
Importance: medium

客户端等待套接字连接建立的最大时间。当每个连续连接失败时,连接设置超时会达到这个最大值。为避免连接差异,将把一个随机化因值应用于超时,导致计算值高于 20% 的随机范围。

socket.connection.setup.timeout.ms

type: long
Default: 10000 (10 seconds)
Importance: medium

客户端等待套接字连接建立的时间长度。如果在超时时间前没有构建连接,客户端将关闭套接字频道。

ssl.enabled.protocols

type: list
Default: TLSv1.2,TLSv1.3
Importance: medium

为 SSL 连接启用的协议列表。在使用 Java 11 或更新版本时,默认为 'TLSv1.2,TLSv1.3',否则 'TLSv1.2'。使用 Java 11 的默认值,如果客户端和服务器同时支持 TLSv1.3,则客户端和服务器将首选 TLSv1.3,否则将回退到 TLSv1.2(假设两者都至少支持 TLSv1.2)。对于大多数情况,这个默认值应该可以正常工作。另请参阅 ssl.protocol 的配置文档。

ssl.keystore.type

Type: string
Default: JKS
Importance: medium

密钥存储文件的文件格式。这对客户端是可选的。

ssl.protocol

type: string
Default: TLSv1.3
Importance: medium

用于生成 SSLContext 的 SSL 协议。使用 Java 11 或更新版本运行时,默认为 'TLSv1.3',否则 'TLSv1.2'。对于大多数用例,这个值应该可以正常工作。最近的 JVM 中允许的值为 'TLSv1.2' 和 'TLSv1.3'。旧的 JVM 可以支持 'TLS', 'TLSv1.1', 'SSLv2', 'SSLv2' 和 'SSLv3',但由于已知的安全漏洞,不建议使用它们。使用这个配置和 'ssl.enabled.protocols' 的默认值,如果服务器不支持 'TLSv1.3',客户端将降级为 'TLSv1.2'。如果此配置被设置为 'TLSv1.2',客户端将不会使用 'TLSv1.3',即使它是 ssl.enabled.protocols 中的值之一,服务器只支持 'TLSv1.3'。

ssl.provider

Type: string
Default: null
Importance: medium

用于 SSL 连接的安全供应商的名称。默认值是 JVM 的默认安全提供程序。

ssl.truststore.type

Type: string
Default: JKS
Importance: medium

信任存储文件的文件格式。

acks

Type: string
Default: all
Valid Values: [all, -1, 0, 1]
Importance: low

在考虑请求完成前,生成者需要收到的确认数量。这控制发送的记录的持久性。允许以下设置:

  • acks=0 如果设为零,则生成者不会等待来自服务器的任何确认。记录将立即添加到套接字缓冲区中并被视为发送。无法保证服务器已收到记录,重试 配置不会生效(因为客户端通常不知道任何失败)。每个记录给出的偏移始终设置为 -1
  • acks=1 意味着领导人将记录写入其本地日志,但不会等待所有后续人的完全确认。在这种情况下,领导机在确认记录后马上失败,但在后续者复制之前,记录将会丢失。
  • acks=all 意味着领导机将等待一整组同步副本确认记录。这样可保证记录在至少一个同步副本仍然处于活动状态时不会丢失。这是最强的可用保证。这等同于 acks=-1 设置。
enable.idempotence

Type: boolean
Default: true
Importance: low

当设置为 'true' 时,生成者将确保每个消息的确切副本在流中写入。如果 'false',则因代理失败而重试的制作者可能会在流中写入重试消息的副本。请注意,启用 idempotence 需要 max.in.flight.requests.per.connection 小于或等于 5 (为任何允许值保留消息排序),重试 大于 0,ack s 必须是 'all'。如果用户没有明确设置这些值,则会选择合适的值。如果设置了不兼容的值,则会抛出 ConfigException

interceptor.classes

type: list
Default: ""
Valid Values: non-null string
Importance: low

用作拦截器的类列表。通过实施 org.apache.kafka.clients.producer.ProducerInterceptor 接口,您可以在生成者发布到 Kafka 集群前截获(并可能修改)制作者收到的记录。默认情况下,没有拦截器。

max.in.flight.requests.per.connection

type: int
Default: 5
Valid Values: [1,…​]
Importance: low

客户端在阻止前在单个连接上发送的最大未确认请求数。请注意,如果将此配置设置为大于 1,并且 enable.idempotence 被设置为 false,则因为重试失败(例如,如果启用了重试)后消息重新排序的风险(例如,如果启用了重试)。

metadata.max.age.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: low

即使我们未看到任何分区领导力更改来主动发现任何新的代理或分区,我们才会强制刷新元数据的时间(以毫秒为单位)。

metadata.max.idle.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [5000,…​]
Importance: low

控制制作者将缓存闲置主题的元数据的时长。如果自上次生成了一个主题后经过的时间超过元数据空闲持续时间,则主题的元数据会被忘记,下一次访问将强制进行元数据获取请求。

metric.reporters

type: list
Default: ""
Valid Values: non-null string
Importance: low

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Valid Values: [INFO, DEBUG, TRACE]
Importance: low

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

计算指标示例的时间窗口。

reconnect.backoff.max.ms

type: long
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: low

重新连接到重复连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供,每个主机的 backoff 将为每个连续的连接失败指数增加,直到最高值。在计算 backoff 增长后,添加了 20% 的随机 jitter,以避免连接状况。

reconnect.backoff.ms

type: long
Default: 50
Valid Values: [0,…​]
Importance: low

尝试重新连接到给定主机前等待的基本时间。这可避免在紧密循环中重复连接到主机。此 backoff 应用到客户端到代理的所有连接尝试。

retry.backoff.ms

Type: long
Default: 100
Valid Values: [0,…​]
Importance: low

尝试重试对给定主题分区失败的请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: low

Kerberos kinit 命令路径。

sasl.kerberos.min.time.before.relogin

Type: long
Default: 60000
Importance: low

刷新尝试之间的登录线程睡眠时间。

sasl.kerberos.ticket.renew.jitter

type: double
Default: 0.05
Importance: low

添加到续订时间的随机 jitter 的百分比。

sasl.kerberos.ticket.renew.window.factor

Type: double
Default: 0.8
Importance: low

登录线程将处于睡眠状态,直到达到最后一次刷新到票据到期的时间因素前处于睡眠状态,此时将尝试续订票据。

sasl.login.connect.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商连接超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.read.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商读取超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.buffer.seconds

Type: short
Default: 300
Valid Values: [0,…​,3600]
Importance: low

在刷新凭证时凭证过期前的缓冲时间(以秒为单位)。如果刷新情况比缓冲区秒数接近过期,则刷新将移动,以尽可能多地维护缓冲区时间。法律值介于 0 到 3600 (1 小时)之间;如果没有指定值,则使用默认值 300 (5 分钟)。如果这个值和 sasl.login.refresh.min.period.seconds 超过了凭证剩余的生命周期,则忽略这个值。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.min.period.seconds

Type: short
Default: 60
Valid Values: [0,…​,900]
Importance: low

登录刷新线程在刷新凭证前等待的时间(以秒为单位)。法律值介于 0 到 900 (15 分钟)之间;如果没有指定值,则使用默认值 60 (1 分钟)。如果这个值和 sasl.login.refresh.buffer.seconds 都会被忽略,如果它们的总和超过凭证的剩余生命周期。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.factor

type: double
Default: 0.8
Valid Values: [0.5,…​,1.0]
Importance: low

登录刷新线程将休眠到与凭证生命周期相关的指定窗口因素,此时将尝试刷新凭证。法律值介于 0.5 (50%)和 1.0 (100%)之间,如果没有指定值,则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.jitter

type: double
Default: 0.05
Valid Values: [0.0,…​,0.25]
Importance: low

与凭证的生命周期相关的最大随机 jitter 量添加到登录刷新线程的睡眠时间中。法律值介于 0 到 0.25(25%)之间,如果没有指定值,则使用默认值 0.05(5%)。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)登录尝试外部身份验证提供程序之间等待的最大等待值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)登录尝试外部身份验证提供程序期间初始等待的值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.oauthbearer.clock.skew.seconds

Type: int
Default: 30
Importance: low

(可选)值(以秒为单位),允许 OAuth/OIDC 身份提供程序和代理间的差别。

sasl.oauthbearer.expected.audience

Type: list
Default: null
Importance: low

(可选)代理用逗号分隔的设置来验证是否已为其中一个预期的受众发出 JWT。JWT 将检查是否有标准的 OAuth "aud" 声明,如果设置了这个值,代理将与 JWT 的"aud"声明中的值匹配,以查看是否有完全匹配。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.expected.issuer

Type: string
Default: null
Importance: low

代理的 (可选)用于验证 JWT 是否已由预期签发者创建的(可选)设置。JWT 将检查是否有标准 OAuth "iss" 声明,如果设置了这个值,代理会完全匹配 JWT 的"iss"声明中的内容。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.jwks.endpoint.refresh.ms

Type: long
Default: 3600000 (1 hour)
Importance: low

(可选)代理在刷新其 JWKS (JSON Web Key Set)缓存之间等待的值,其中包含键以验证 JWT 的签名。

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)尝试从外部身份验证提供程序检索 JWKS (JSON Web Key Set)之间的最大等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)在 JWKS (JSON Web Key Set)检索外部身份验证提供程序尝试时的初始等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.scope.claim.name

Type: string
Default: scope
Importance: low

范围的 OAuth 声明通常命名为 "scope",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以提供用于 JWT 有效负载声明中包含的范围的名称。

sasl.oauthbearer.sub.claim.name

Type: string
Default: sub
Importance: low

该主题的 OAuth 声明通常命名为 "sub",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以为 JWT 有效负载的声明中包含的主题提供不同的名称。

security.providers

Type: string
Default: null
Importance: low

每个返回供应商实施安全算法的可配置创建者类列表。这些类应实施 org.apache.kafka.common.security.auth.SecurityProviderCreator 接口。

ssl.cipher.suites

Type: list
Default: null
Importance: low

密码套件列表。这是用来使用 TLS 或 SSL 网络协议协商网络连接的安全设置的身份验证、加密、MAC 和密钥交换算法的命名组合。默认情况下,支持所有可用的密码套件。

ssl.endpoint.identification.algorithm

Type: string
Default: https
Importance: low

使用服务器证书验证服务器主机名的端点标识算法。

ssl.engine.factory.class

Type: class
Default: null
Importance: low

org.apache.kafka.common.security.auth.SslEngineFactory 类型的类提供 SSLEngine 对象。默认值为 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

ssl.keymanager.algorithm

Type: string
Default: SunX509
Importance: low

密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。

ssl.secure.random.implementation

Type: string
Default: null
Importance: low

用于 SSL 加密操作的 SecureRandom PRNG 实施。

ssl.trustmanager.algorithm

Type: string
Default: PKIX
Importance: low

信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。

transaction.timeout.ms

type: int
Default: 60000 (1 minute)
Importance: low

事务协调器在主动中止持续事务处理前等待事务状态更新的最长时间。如果这个值大于代理中的 transaction.max.timeout.ms 设置,请求将失败,并显示 InvalidTxnTimeoutException 错误。

transactional.id

Type: string
Default: null
Valid Values: non-empty string
Importance: low

用于事务发送的 TransactionalId。这可实现跨越多个制作者会话的可靠性语义,因为它允许客户端保证在启动任何新事务前使用相同的 TransactionalId 事务已完成。如果没有提供 TransactionalId,则生成者将限制为幂等交付。如果配置了 TransactionalId,则代表 enable.idempotence。默认情况下,TransactionId 没有配置,这意味着无法使用事务。请注意,默认情况下,事务需要至少三个代理集群,这是生产环境的建议设置;对于开发,您可以通过调整代理设置 transaction.state.log.replication.factor

附录 E. 管理客户端配置参数

bootstrap.servers

type: list
Importance: high

用于建立到 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器与此处为引导指定的服务器无关 - 此列表仅影响用于发现完整服务器集的初始主机。此列表的格式应为 host1:port1,host2:port2,…​。由于这些服务器仅用于初始连接来发现完整的群集成员身份(可能会动态更改),因此此列表不需要包含整组服务器(但是如果服务器停机,您可能需要多个服务器)。

ssl.key.password

Type: password
Default: null
Importance: high

密钥存储文件或者 'ssl.keystore.key' 中指定的 PEM 密钥的密码。只有在配置了双向身份验证时,客户端才需要这样做。

ssl.keystore.certificate.chain

Type: password
Default: null
Importance: high

使用由 'ssl.keystore.type" 指定的格式的证书链。默认 SSL 引擎工厂仅支持使用 X.509 证书列表的 PEM 格式。

ssl.keystore.key

Type: password
Default: null
Importance: high

使用 'ssl.keystore.type" 指定的格式的私钥。默认 SSL 引擎工厂只支持使用 PKCS#8 密钥的 PEM 格式。如果密钥加密,必须使用 'ssl.key.password' 指定密钥密码。

ssl.keystore.location

Type: string
Default: null
Importance: high

密钥存储文件的位置。这对客户端是可选的,可用于客户端进行双向身份验证。

ssl.keystore.password

Type: password
Default: null
Importance: high

密钥存储文件的存储密码。这对客户端是可选的,只有在配置了 'ssl.keystore.location' 时才需要。PEM 格式不支持密钥存储密码。

ssl.truststore.certificates

Type: password
Default: null
Importance: high

可信证书,格式为 'ssl.truststore.type'。默认 SSL 引擎工厂仅支持使用 X.509 证书使用 PEM 格式。

ssl.truststore.location

Type: string
Default: null
Importance: high

信任存储文件的位置。

ssl.truststore.password

Type: password
Default: null
Importance: high

信任存储文件的密码。如果没有设置密码,则仍然使用配置的信任存储文件,但禁用完整性检查。PEM 格式不支持信任存储密码。

client.dns.lookup

Type: string
Default: use_all_dns_ips
Valid Values: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips,请按顺序连接到每个返回的 IP 地址,直到成功建立连接。断开连接后,会使用下一个 IP。当所有 IP 都被一次使用后,客户端会再次解析主机名(JVM 和 OS 缓存 DNS 名称查找)中的 IP。如果设置为 resolve_canonical_bootstrap_servers_only,请将每个 bootstrap 地址解析为规范名称列表。bootstrap 阶段后,它的行为与 use_all_dns_ips 相同。

client.id

Type: string
Default: ""
Importance: medium

在发出请求时传递给服务器的 id 字符串。这样做的目的是通过允许逻辑应用程序名称包含在服务器端请求日志记录中,从而跟踪除 ip/port 以外的请求源。

connections.max.idle.ms

Type: long
Default: 300000 (5 minutes)
Importance: medium

在这个配置指定的毫秒数后关闭闲置连接。

default.api.timeout.ms

type: int
Default: 60000 (1 minute)
Valid Values: [0,…​]
Importance: medium

指定客户端 API 的超时时间(以毫秒为单位)。此配置用作没有指定 timeout 参数的所有客户端操作的默认超时时间。

receive.buffer.bytes

type: int
Default: 65536 (64 kibibytes)
Valid Values: [-1,…​]
Importance: medium

读取数据时要使用的 TCP 接收缓冲区(SO_RCVBUF)的大小。如果值为 -1,则使用操作系统默认值。

request.timeout.ms

type: int
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: medium

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

sasl.client.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称。

sasl.jaas.config

Type: password
Default: null
Importance: medium

用于 SASL 连接的 JAAS 登录上下文参数,其格式供 JAAS 配置文件使用。JAAS 配置文件格式描述 在此处。该值的格式是: loginModuleClass controlFlag (optionName=optionValue)*;。对于代理,配置必须在小写中带有监听前缀和 SASL 机制名称前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;。

sasl.kerberos.service.name

Type: string
Default: null
Importance: medium

Kafka 运行的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 配置中定义。

sasl.login.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理,登录回调处理器配置必须以监听器前缀和 SASL 机制名称作为前缀作为前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

sasl.login.class

Type: class
Default: null
Importance: medium

实现登录接口的类的完全限定名称。对于代理,登录配置必须在小写中带有监听前缀和 SASL 机制名称前缀。For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin.

sasl.mechanism

Type: string
Default: GSSAPI
Importance: medium

用于客户端连接的 SASL 机制。这可能是提供安全提供程序的任何机制。GSSAPI 是默认机制。

sasl.oauthbearer.jwks.endpoint.url

Type: string
Default: null
Importance: medium

可以从中检索供应商的 JWKS (JSON Web Key Set) 的 OAuth/OIDC 供应商 URL。URL 可以是基于 HTTP (S)或基于文件的 URL。如果 URL 基于 HTTP (S),则 JWKS 数据将通过代理启动时配置的 URL 从 OAuth/OIDC 供应商中检索。所有 then-current 密钥都将缓存在代理上以进行传入请求。如果为 JWT 收到了身份验证请求,其中包含缓存中尚未在缓存中的"kid"标头声明值,则将根据需要再次查询 JWKS 端点。但是,代理会轮询每个 sasl.oauthbearer.jwks.endpoint.refresh.ms 毫秒的 URL,以便在收到包含这些密钥的任何 JWT 请求前刷新缓存。如果 URL 基于文件,代理将在启动时从配置的位置加载 JWKS 文件。如果 JWT 包含没有在 JWKS 文件中的 "kid" 标头值,代理将拒绝 JWT 并且身份验证将失败。

sasl.oauthbearer.token.endpoint.url

Type: string
Default: null
Importance: medium

OAuth/OIDC 身份提供程序的 URL。如果 URL 基于 HTTP (S),这是签发者的令牌端点 URL,其请求将根据 sasl.jaas.config 中的配置登录。如果 URL 基于文件,它指定一个包含由 OAuth/OIDC 身份提供程序发布的访问令牌( JWT 序列化形式)的文件,以用于授权。

security.protocol

Type: string
Default: PLAINTEXT
Importance: medium

用于与代理通信的协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。

send.buffer.bytes

type: int
Default: 131072 (128 kibibytes)
Valid Values: [-1,…​]
Importance: medium

发送数据时要使用的 TCP 发送缓冲区(SO_SNDBUF)的大小。如果值为 -1,则使用操作系统默认值。

socket.connection.setup.timeout.max.ms

type: long
Default: 30000 (30 秒)
Importance: medium

客户端等待套接字连接建立的最大时间。当每个连续连接失败时,连接设置超时会达到这个最大值。为避免连接差异,将把一个随机化因值应用于超时,导致计算值高于 20% 的随机范围。

socket.connection.setup.timeout.ms

type: long
Default: 10000 (10 seconds)
Importance: medium

客户端等待套接字连接建立的时间长度。如果在超时时间前没有构建连接,客户端将关闭套接字频道。

ssl.enabled.protocols

type: list
Default: TLSv1.2,TLSv1.3
Importance: medium

为 SSL 连接启用的协议列表。在使用 Java 11 或更新版本时,默认为 'TLSv1.2,TLSv1.3',否则 'TLSv1.2'。使用 Java 11 的默认值,如果客户端和服务器同时支持 TLSv1.3,则客户端和服务器将首选 TLSv1.3,否则将回退到 TLSv1.2(假设两者都至少支持 TLSv1.2)。对于大多数情况,这个默认值应该可以正常工作。另请参阅 ssl.protocol 的配置文档。

ssl.keystore.type

Type: string
Default: JKS
Importance: medium

密钥存储文件的文件格式。这对客户端是可选的。

ssl.protocol

type: string
Default: TLSv1.3
Importance: medium

用于生成 SSLContext 的 SSL 协议。使用 Java 11 或更新版本运行时,默认为 'TLSv1.3',否则 'TLSv1.2'。对于大多数用例,这个值应该可以正常工作。最近的 JVM 中允许的值为 'TLSv1.2' 和 'TLSv1.3'。旧的 JVM 可以支持 'TLS', 'TLSv1.1', 'SSLv2', 'SSLv2' 和 'SSLv3',但由于已知的安全漏洞,不建议使用它们。使用这个配置和 'ssl.enabled.protocols' 的默认值,如果服务器不支持 'TLSv1.3',客户端将降级为 'TLSv1.2'。如果此配置被设置为 'TLSv1.2',客户端将不会使用 'TLSv1.3',即使它是 ssl.enabled.protocols 中的值之一,服务器只支持 'TLSv1.3'。

ssl.provider

Type: string
Default: null
Importance: medium

用于 SSL 连接的安全供应商的名称。默认值是 JVM 的默认安全提供程序。

ssl.truststore.type

Type: string
Default: JKS
Importance: medium

信任存储文件的文件格式。

metadata.max.age.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: low

即使我们未看到任何分区领导力更改来主动发现任何新的代理或分区,我们才会强制刷新元数据的时间(以毫秒为单位)。

metric.reporters

Type: list
Default: ""
Importance: low

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Valid Values: [INFO, DEBUG, TRACE]
Importance: low

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

计算指标示例的时间窗口。

reconnect.backoff.max.ms

type: long
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: low

重新连接到重复连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供,每个主机的 backoff 将为每个连续的连接失败指数增加,直到最高值。在计算 backoff 增长后,添加了 20% 的随机 jitter,以避免连接状况。

reconnect.backoff.ms

type: long
Default: 50
Valid Values: [0,…​]
Importance: low

尝试重新连接到给定主机前等待的基本时间。这可避免在紧密循环中重复连接到主机。此 backoff 应用到客户端到代理的所有连接尝试。

retries

type: int
Default: 2147483647
Valid Values: [0,…​,2147483647]
Importance: low

设置大于零的值将导致客户端重新发送失败并可能出现临时错误的请求。建议将值设为 0 或 MAX_VALUE,并使用对应的超时参数来控制客户端应重试请求的时长。

retry.backoff.ms

Type: long
Default: 100
Valid Values: [0,…​]
Importance: low

尝试重试失败请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: low

Kerberos kinit 命令路径。

sasl.kerberos.min.time.before.relogin

Type: long
Default: 60000
Importance: low

刷新尝试之间的登录线程睡眠时间。

sasl.kerberos.ticket.renew.jitter

type: double
Default: 0.05
Importance: low

添加到续订时间的随机 jitter 的百分比。

sasl.kerberos.ticket.renew.window.factor

Type: double
Default: 0.8
Importance: low

登录线程将处于睡眠状态,直到达到最后一次刷新到票据到期的时间因素前处于睡眠状态,此时将尝试续订票据。

sasl.login.connect.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商连接超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.read.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商读取超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.buffer.seconds

Type: short
Default: 300
Valid Values: [0,…​,3600]
Importance: low

在刷新凭证时凭证过期前的缓冲时间(以秒为单位)。如果刷新情况比缓冲区秒数接近过期,则刷新将移动,以尽可能多地维护缓冲区时间。法律值介于 0 到 3600 (1 小时)之间;如果没有指定值,则使用默认值 300 (5 分钟)。如果这个值和 sasl.login.refresh.min.period.seconds 超过了凭证剩余的生命周期,则忽略这个值。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.min.period.seconds

Type: short
Default: 60
Valid Values: [0,…​,900]
Importance: low

登录刷新线程在刷新凭证前等待的时间(以秒为单位)。法律值介于 0 到 900 (15 分钟)之间;如果没有指定值,则使用默认值 60 (1 分钟)。如果这个值和 sasl.login.refresh.buffer.seconds 都会被忽略,如果它们的总和超过凭证的剩余生命周期。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.factor

type: double
Default: 0.8
Valid Values: [0.5,…​,1.0]
Importance: low

登录刷新线程将休眠到与凭证生命周期相关的指定窗口因素,此时将尝试刷新凭证。法律值介于 0.5 (50%)和 1.0 (100%)之间,如果没有指定值,则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.jitter

type: double
Default: 0.05
Valid Values: [0.0,…​,0.25]
Importance: low

与凭证的生命周期相关的最大随机 jitter 量添加到登录刷新线程的睡眠时间中。法律值介于 0 到 0.25(25%)之间,如果没有指定值,则使用默认值 0.05(5%)。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)登录尝试外部身份验证提供程序之间等待的最大等待值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)登录尝试外部身份验证提供程序期间初始等待的值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.oauthbearer.clock.skew.seconds

Type: int
Default: 30
Importance: low

(可选)值(以秒为单位),允许 OAuth/OIDC 身份提供程序和代理间的差别。

sasl.oauthbearer.expected.audience

Type: list
Default: null
Importance: low

(可选)代理用逗号分隔的设置来验证是否已为其中一个预期的受众发出 JWT。JWT 将检查是否有标准的 OAuth "aud" 声明,如果设置了这个值,代理将与 JWT 的"aud"声明中的值匹配,以查看是否有完全匹配。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.expected.issuer

Type: string
Default: null
Importance: low

代理的 (可选)用于验证 JWT 是否已由预期签发者创建的(可选)设置。JWT 将检查是否有标准 OAuth "iss" 声明,如果设置了这个值,代理会完全匹配 JWT 的"iss"声明中的内容。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.jwks.endpoint.refresh.ms

Type: long
Default: 3600000 (1 hour)
Importance: low

(可选)代理在刷新其 JWKS (JSON Web Key Set)缓存之间等待的值,其中包含键以验证 JWT 的签名。

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)尝试从外部身份验证提供程序检索 JWKS (JSON Web Key Set)之间的最大等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)在 JWKS (JSON Web Key Set)检索外部身份验证提供程序尝试时的初始等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.scope.claim.name

Type: string
Default: scope
Importance: low

范围的 OAuth 声明通常命名为 "scope",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以提供用于 JWT 有效负载声明中包含的范围的名称。

sasl.oauthbearer.sub.claim.name

Type: string
Default: sub
Importance: low

该主题的 OAuth 声明通常命名为 "sub",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以为 JWT 有效负载的声明中包含的主题提供不同的名称。

security.providers

Type: string
Default: null
Importance: low

每个返回供应商实施安全算法的可配置创建者类列表。这些类应实施 org.apache.kafka.common.security.auth.SecurityProviderCreator 接口。

ssl.cipher.suites

Type: list
Default: null
Importance: low

密码套件列表。这是用来使用 TLS 或 SSL 网络协议协商网络连接的安全设置的身份验证、加密、MAC 和密钥交换算法的命名组合。默认情况下,支持所有可用的密码套件。

ssl.endpoint.identification.algorithm

Type: string
Default: https
Importance: low

使用服务器证书验证服务器主机名的端点标识算法。

ssl.engine.factory.class

Type: class
Default: null
Importance: low

org.apache.kafka.common.security.auth.SslEngineFactory 类型的类提供 SSLEngine 对象。默认值为 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

ssl.keymanager.algorithm

Type: string
Default: SunX509
Importance: low

密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。

ssl.secure.random.implementation

Type: string
Default: null
Importance: low

用于 SSL 加密操作的 SecureRandom PRNG 实施。

ssl.trustmanager.algorithm

Type: string
Default: PKIX
Importance: low

信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。

附录 F. Kafka Connect 配置参数

config.storage.topic

type: string
Importance: high

存储连接器配置的 Kafka 主题的名称。

group.id

type: string
Importance: high

标识此 worker 所属的 Connect 集群组的唯一字符串。

key.converter

type: class
Importance: high

转换器类用于在 Kafka Connect 格式和写入 Kafka 的序列化形式之间进行转换。这会控制写入或从 Kafka 读取的消息中的密钥格式,因为这独立于连接器,因此任何连接器都可以使用任何序列化格式。常见格式示例包括 JSON 和 Avro。

offset.storage.topic

type: string
Importance: high

存储连接器偏移的 Kafka 主题的名称。

status.storage.topic

type: string
Importance: high

存储连接器和任务状态的 Kafka 主题的名称。

value.converter

type: class
Importance: high

转换器类用于在 Kafka Connect 格式和写入 Kafka 的序列化形式之间进行转换。这会控制写入或从 Kafka 读取的消息中的值格式,因为这独立于连接器,因此任何连接器都可以使用任何序列化格式。常见格式示例包括 JSON 和 Avro。

bootstrap.servers

type: list
Default: localhost:9092
Importance: high

用于建立到 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器与此处为引导指定的服务器无关 - 此列表仅影响用于发现完整服务器集的初始主机。此列表的格式应为 host1:port1,host2:port2,…​。由于这些服务器仅用于初始连接来发现完整的群集成员身份(可能会动态更改),因此此列表不需要包含整组服务器(但是如果服务器停机,您可能需要多个服务器)。

heartbeat.interval.ms

Type: int
Default: 3000 (3 秒)
Importance: high

使用 Kafka 的组管理功能时,与组协调器的心跳之间预期的时间。心跳用于确保 worker 的会话保持活动状态,并在新成员加入或离开组时促进重新平衡。该值必须小于 session.timeout.ms,但设置的值通常不应超过这个值的 1/3。它可以调整甚至较低,以控制正常重新平衡的预期时间。

rebalance.timeout.ms

type: int
Default: 60000 (1 minute)
Importance: high

每个 worker 允许的最大时间在重新平衡后加入组。这基本上是所有任务清除任何待处理数据和提交偏移所需的时间的限制。如果超过了超时,则 worker 将从组中删除,这会导致偏移提交失败。

session.timeout.ms

type: int
Default: 10000 (10 seconds)
Importance: high

用于检测 worker 失败的超时。worker 发送定期心跳以指示其存活度到代理。如果在这个会话超时前代理没有接收心跳,则代理将从组中删除 worker 并启动重新平衡。请注意,该值必须在允许范围内,如 group.min.session.timeout.msgroup.max.session.timeout.ms 中配置。

ssl.key.password

Type: password
Default: null
Importance: high

密钥存储文件或者 'ssl.keystore.key' 中指定的 PEM 密钥的密码。只有在配置了双向身份验证时,客户端才需要这样做。

ssl.keystore.certificate.chain

Type: password
Default: null
Importance: high

使用由 'ssl.keystore.type" 指定的格式的证书链。默认 SSL 引擎工厂仅支持使用 X.509 证书列表的 PEM 格式。

ssl.keystore.key

Type: password
Default: null
Importance: high

使用 'ssl.keystore.type" 指定的格式的私钥。默认 SSL 引擎工厂只支持使用 PKCS#8 密钥的 PEM 格式。如果密钥加密,必须使用 'ssl.key.password' 指定密钥密码。

ssl.keystore.location

Type: string
Default: null
Importance: high

密钥存储文件的位置。这对客户端是可选的,可用于客户端进行双向身份验证。

ssl.keystore.password

Type: password
Default: null
Importance: high

密钥存储文件的存储密码。这对客户端是可选的,只有在配置了 'ssl.keystore.location' 时才需要。PEM 格式不支持密钥存储密码。

ssl.truststore.certificates

Type: password
Default: null
Importance: high

可信证书,格式为 'ssl.truststore.type'。默认 SSL 引擎工厂仅支持使用 X.509 证书使用 PEM 格式。

ssl.truststore.location

Type: string
Default: null
Importance: high

信任存储文件的位置。

ssl.truststore.password

Type: password
Default: null
Importance: high

信任存储文件的密码。如果没有设置密码,则仍然使用配置的信任存储文件,但禁用完整性检查。PEM 格式不支持信任存储密码。

client.dns.lookup

Type: string
Default: use_all_dns_ips
Valid Values: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips,请按顺序连接到每个返回的 IP 地址,直到成功建立连接。断开连接后,会使用下一个 IP。当所有 IP 都被一次使用后,客户端会再次解析主机名(JVM 和 OS 缓存 DNS 名称查找)中的 IP。如果设置为 resolve_canonical_bootstrap_servers_only,请将每个 bootstrap 地址解析为规范名称列表。bootstrap 阶段后,它的行为与 use_all_dns_ips 相同。

connections.max.idle.ms

Type: long
Default: 540000 (9 minutes)
Importance: medium

在这个配置指定的毫秒数后关闭闲置连接。

connector.client.config.override.policy

Type: string
Default: All
Importance: medium

ConnectorClientConfigOverridePolicy 的类名称或别名实现。定义连接器可以覆盖哪些客户端配置。默认实现是 All,这意味着连接器配置可以覆盖所有客户端属性。框架中的其他可能策略包括 None 来禁止连接者覆盖客户端属性,和 Principal 来允许连接者只能覆盖客户端的主体。

receive.buffer.bytes

type: int
Default: 32768 (32 kibibytes)
Valid Values: [0,…​]
Importance: medium

读取数据时要使用的 TCP 接收缓冲区(SO_RCVBUF)的大小。如果值为 -1,则使用操作系统默认值。

request.timeout.ms

type: int
Default: 40000 (40 seconds)
Valid Values: [0,…​]
Importance: medium

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

sasl.client.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称。

sasl.jaas.config

Type: password
Default: null
Importance: medium

用于 SASL 连接的 JAAS 登录上下文参数,其格式供 JAAS 配置文件使用。JAAS 配置文件格式描述 在此处。该值的格式是: loginModuleClass controlFlag (optionName=optionValue)*;。对于代理,配置必须在小写中带有监听前缀和 SASL 机制名称前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;。

sasl.kerberos.service.name

Type: string
Default: null
Importance: medium

Kafka 运行的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 配置中定义。

sasl.login.callback.handler.class

Type: class
Default: null
Importance: medium

实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理,登录回调处理器配置必须以监听器前缀和 SASL 机制名称作为前缀作为前缀。例如: listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler。

sasl.login.class

Type: class
Default: null
Importance: medium

实现登录接口的类的完全限定名称。对于代理,登录配置必须在小写中带有监听前缀和 SASL 机制名称前缀。For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin.

sasl.mechanism

Type: string
Default: GSSAPI
Importance: medium

用于客户端连接的 SASL 机制。这可能是提供安全提供程序的任何机制。GSSAPI 是默认机制。

sasl.oauthbearer.jwks.endpoint.url

Type: string
Default: null
Importance: medium

可以从中检索供应商的 JWKS (JSON Web Key Set) 的 OAuth/OIDC 供应商 URL。URL 可以是基于 HTTP (S)或基于文件的 URL。如果 URL 基于 HTTP (S),则 JWKS 数据将通过代理启动时配置的 URL 从 OAuth/OIDC 供应商中检索。所有 then-current 密钥都将缓存在代理上以进行传入请求。如果为 JWT 收到了身份验证请求,其中包含缓存中尚未在缓存中的"kid"标头声明值,则将根据需要再次查询 JWKS 端点。但是,代理会轮询每个 sasl.oauthbearer.jwks.endpoint.refresh.ms 毫秒的 URL,以便在收到包含这些密钥的任何 JWT 请求前刷新缓存。如果 URL 基于文件,代理将在启动时从配置的位置加载 JWKS 文件。如果 JWT 包含没有在 JWKS 文件中的 "kid" 标头值,代理将拒绝 JWT 并且身份验证将失败。

sasl.oauthbearer.token.endpoint.url

Type: string
Default: null
Importance: medium

OAuth/OIDC 身份提供程序的 URL。如果 URL 基于 HTTP (S),这是签发者的令牌端点 URL,其请求将根据 sasl.jaas.config 中的配置登录。如果 URL 基于文件,它指定一个包含由 OAuth/OIDC 身份提供程序发布的访问令牌( JWT 序列化形式)的文件,以用于授权。

security.protocol

Type: string
Default: PLAINTEXT
Importance: medium

用于与代理通信的协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。

send.buffer.bytes

type: int
Default: 131072 (128 kibibytes)
Valid Values: [0,…​]
Importance: medium

发送数据时要使用的 TCP 发送缓冲区(SO_SNDBUF)的大小。如果值为 -1,则使用操作系统默认值。

ssl.enabled.protocols

type: list
Default: TLSv1.2,TLSv1.3
Importance: medium

为 SSL 连接启用的协议列表。在使用 Java 11 或更新版本时,默认为 'TLSv1.2,TLSv1.3',否则 'TLSv1.2'。使用 Java 11 的默认值,如果客户端和服务器同时支持 TLSv1.3,则客户端和服务器将首选 TLSv1.3,否则将回退到 TLSv1.2(假设两者都至少支持 TLSv1.2)。对于大多数情况,这个默认值应该可以正常工作。另请参阅 ssl.protocol 的配置文档。

ssl.keystore.type

Type: string
Default: JKS
Importance: medium

密钥存储文件的文件格式。这对客户端是可选的。

ssl.protocol

type: string
Default: TLSv1.3
Importance: medium

用于生成 SSLContext 的 SSL 协议。使用 Java 11 或更新版本运行时,默认为 'TLSv1.3',否则 'TLSv1.2'。对于大多数用例,这个值应该可以正常工作。最近的 JVM 中允许的值为 'TLSv1.2' 和 'TLSv1.3'。旧的 JVM 可以支持 'TLS', 'TLSv1.1', 'SSLv2', 'SSLv2' 和 'SSLv3',但由于已知的安全漏洞,不建议使用它们。使用这个配置和 'ssl.enabled.protocols' 的默认值,如果服务器不支持 'TLSv1.3',客户端将降级为 'TLSv1.2'。如果此配置被设置为 'TLSv1.2',客户端将不会使用 'TLSv1.3',即使它是 ssl.enabled.protocols 中的值之一,服务器只支持 'TLSv1.3'。

ssl.provider

Type: string
Default: null
Importance: medium

用于 SSL 连接的安全供应商的名称。默认值是 JVM 的默认安全提供程序。

ssl.truststore.type

Type: string
Default: JKS
Importance: medium

信任存储文件的文件格式。

worker.sync.timeout.ms

Type: int
Default: 3000 (3 秒)
Importance: medium

当 worker 与其他 worker 不同步且需要重新同步配置时,请在放弃前等待这个时间,保留组,并在重新加入前等待 backoff 周期。

worker.unsync.backoff.ms

Type: int
Default: 300000 (5 minutes)
Importance: medium

当 worker 没有与其他 worker 同步,且无法在 worker.sync.timeout.ms 中捕获时,在重新加入前保留 Connect 集群。

access.control.allow.methods

Type: string
Default: ""
Importance: low

通过设置 Access-Control-Allow-Methods 标头来设置跨原始请求支持的方法。Access-Control-Allow-Methods 标头的默认值允许对 GET、POST 和 HEAD 的跨原始请求。

access.control.allow.origin

Type: string
Default: ""
Importance: low

将 Access-Control-Allow-Origin 标头设置为 REST API 请求的值。要启用跨原始访问,将其设置为允许访问 API 的应用程序的域,或 '*' 允许从任何域进行访问。默认值只允许从 REST API 的域访问。

admin.listeners

type: list
Default: null
Valid Values: comma- separated URL 列表,例如: http://localhost:8080,https://localhost:8443.
Importance: low

Admin REST API 将侦听的、以逗号分隔的 URI 列表。支持的协议有 HTTP 和 HTTPS。空字符串或空字符串将禁用此功能。默认行为是使用常规监听程序(由 'listeners' 属性指定)。

client.id

Type: string
Default: ""
Importance: low

在发出请求时传递给服务器的 id 字符串。这样做的目的是通过允许逻辑应用程序名称包含在服务器端请求日志记录中,从而跟踪除 ip/port 以外的请求源。

config.providers

Type: list
Default: ""
Importance: low

以逗号分隔的 ConfigProvider 类名称,加载并按指定顺序使用。通过实施接口 ConfigProvider,您可以替换连接器配置中的变量引用,如用于外部化 secret。

config.storage.replication.factor

Type: short
Default: 3
Valid Values: Positive number not larger than the Kafka 集群中的代理数,或 -1 使用代理的默认
导入: low

创建配置存储主题时使用的复制因素。

connect.protocol

Type: string
Default: sessioned
Valid Values: [eager, compatible, sessioned]
Importance: low

Kafka Connect 协议的兼容性模式。

header.converter

type: class
Default: org.apache.kafka.connect.storage.SimpleHeaderConverter
Importance: low

HeaderConverter 类,用于在 Kafka Connect 格式和写入 Kafka 的序列化表单之间进行转换。这控制写入或从 Kafka 读取的消息中的标头值格式,因为这独立于连接器,因此任何连接器都可以使用任何序列化格式。常见格式示例包括 JSON 和 Avro。默认情况下,simpleHeaderConverter 用于将标头值序列化为字符串,并通过推断模式来反序列化它们。

inter.worker.key.generation.algorithm

Type: string
Default: HmacSHA256
Valid Values: worker JVM
Importance: low 支持的任何 KeyGenerator 算法

用于生成内部请求密钥的算法。

inter.worker.key.size

type: int
Default: null
Importance: low

用于签署内部请求的密钥大小(以位为单位)。如果为 null,则使用密钥生成算法的默认密钥大小。

inter.worker.key.ttl.ms

type: int
Default: 3600000 (1 hour)
Valid Values: [0,…​,2147483647]
Importance: low

用于内部请求验证生成的会话密钥的 TTL (以毫秒为单位)。

inter.worker.signature.algorithm

Type: string
Default: HmacSHA256
Valid Values: worker JVM
Importance: low 支持的任何 MAC 算法

用于为内部请求签名的算法。

inter.worker.verification.algorithms

Type: list
Default: HmacSHA256
Valid Values: 一个或多个 MAC 算法列表,每个算法都由 worker JVM
Importance: low 支持

用于验证内部请求的允许算法列表。

监听器

type: list
Default: http://:8083
Valid Values: comma- separated URL 列表,例如: http://localhost:8080,https://localhost:8443.
Importance: low

REST API 将要侦听的、以逗号分隔的 URI 列表。支持的协议有 HTTP 和 HTTPS。将 hostname 指定为 0.0.0.0 以绑定到所有接口。将 hostname 留空,以绑定到默认接口。法律侦听器列表示例:HTTP://myhost:8083,HTTPS://myhost:8084。

metadata.max.age.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: low

即使我们未看到任何分区领导力更改来主动发现任何新的代理或分区,我们才会强制刷新元数据的时间(以毫秒为单位)。

metric.reporters

Type: list
Default: ""
Importance: low

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Valid Values: [INFO, DEBUG]
Importance: low

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

计算指标示例的时间窗口。

offset.flush.interval.ms

type: long
Default: 60000 (1 minute)
Importance: low

尝试为任务提交偏移的时间间隔。

offset.flush.timeout.ms

Type: long
Default: 5000 (5 seconds)
Importance: low

在取消进程并恢复偏移数据以在以后尝试提交的偏移数据前,等待记录刷新和分区偏移数据的最大毫秒数。

offset.storage.partitions

Type: int
Default: 25
Valid Values: Positive number, 或 -1 使用代理的默认
导入: low

创建偏移存储主题时使用的分区数量。

offset.storage.replication.factor

Type: short
Default: 3
Valid Values: Positive number not larger than the Kafka 集群中的代理数,或 -1 使用代理的默认
导入: low

创建偏移存储主题时使用的复制因素。

plugin.path

Type: list
Default: null
Importance: low

使用逗号(,)分隔的路径列表,其中包含插件(connectors, converters, transformations)。该列表应当由包含任何组合的顶级目录组成,这些目录会立即包含插件及其依赖项 b 的 jar,以及带有插件及其依赖项 c 的 uber-jars,即立即包含插件类别及其依赖项结构的软件包目录结构及其依赖项 注意:符号链接将跟进来发现依赖项或插件。示例: plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors Do not use config provider variables,因为 worker 的扫描程序在配置供应商被初始化并用来替换变量。

reconnect.backoff.max.ms

type: long
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: low

重新连接到重复连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供,每个主机的 backoff 将为每个连续的连接失败指数增加,直到最高值。在计算 backoff 增长后,添加了 20% 的随机 jitter,以避免连接状况。

reconnect.backoff.ms

type: long
Default: 50
Valid Values: [0,…​]
Importance: low

尝试重新连接到给定主机前等待的基本时间。这可避免在紧密循环中重复连接到主机。此 backoff 应用到客户端到代理的所有连接尝试。

response.http.headers.config

Type: string
Default: ""
Valid Values: Comma- separated header rules,其中每个标头规则都是 '[action] [header name]:[header value]',如果标头规则的任何部分包含逗号
导入 low

REST API HTTP 响应标头规则。

rest.advertised.host.name

Type: string
Default: null
Importance: low

如果设置了,这是将分配给其他要连接的 worker 的主机名。

rest.advertised.listener

Type: string
Default: null
Importance: low

设置公告的监听程序(HTTP 或 HTTPS),它将提供给其他 worker 使用。

rest.advertised.port

type: int
Default: null
Importance: low

如果设置了此项,这是将分配给其他要连接的 worker 的端口。

rest.extension.classes

Type: list
Default: ""
Importance: low

以逗号分隔的 ConnectRestExtension 类名称,按指定顺序加载并调用。通过实现接口 ConnectRestExtension,您可以注入 Connect 的 REST API 用户定义的资源,如过滤器。通常用于添加自定义功能,如日志记录、安全性等。

retry.backoff.ms

Type: long
Default: 100
Valid Values: [0,…​]
Importance: low

尝试重试对给定主题分区失败的请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: low

Kerberos kinit 命令路径。

sasl.kerberos.min.time.before.relogin

Type: long
Default: 60000
Importance: low

刷新尝试之间的登录线程睡眠时间。

sasl.kerberos.ticket.renew.jitter

type: double
Default: 0.05
Importance: low

添加到续订时间的随机 jitter 的百分比。

sasl.kerberos.ticket.renew.window.factor

Type: double
Default: 0.8
Importance: low

登录线程将处于睡眠状态,直到达到最后一次刷新到票据到期的时间因素前处于睡眠状态,此时将尝试续订票据。

sasl.login.connect.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商连接超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.read.timeout.ms

type: int
Default: null
Importance: low

(可选)外部身份验证供应商读取超时的值(以毫秒为单位)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.buffer.seconds

Type: short
Default: 300
Valid Values: [0,…​,3600]
Importance: low

在刷新凭证时凭证过期前的缓冲时间(以秒为单位)。如果刷新情况比缓冲区秒数接近过期,则刷新将移动,以尽可能多地维护缓冲区时间。法律值介于 0 到 3600 (1 小时)之间;如果没有指定值,则使用默认值 300 (5 分钟)。如果这个值和 sasl.login.refresh.min.period.seconds 超过了凭证剩余的生命周期,则忽略这个值。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.min.period.seconds

Type: short
Default: 60
Valid Values: [0,…​,900]
Importance: low

登录刷新线程在刷新凭证前等待的时间(以秒为单位)。法律值介于 0 到 900 (15 分钟)之间;如果没有指定值,则使用默认值 60 (1 分钟)。如果这个值和 sasl.login.refresh.buffer.seconds 都会被忽略,如果它们的总和超过凭证的剩余生命周期。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.factor

type: double
Default: 0.8
Valid Values: [0.5,…​,1.0]
Importance: low

登录刷新线程将休眠到与凭证生命周期相关的指定窗口因素,此时将尝试刷新凭证。法律值介于 0.5 (50%)和 1.0 (100%)之间,如果没有指定值,则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。

sasl.login.refresh.window.jitter

type: double
Default: 0.05
Valid Values: [0.0,…​,0.25]
Importance: low

与凭证的生命周期相关的最大随机 jitter 量添加到登录刷新线程的睡眠时间中。法律值介于 0 到 0.25(25%)之间,如果没有指定值,则使用默认值 0.05(5%)。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)登录尝试外部身份验证提供程序之间等待的最大等待值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.login.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)登录尝试外部身份验证提供程序期间初始等待的值(以毫秒为单位)。登录使用基于 sasl.login.retry.backoff.ms 设置的初始等待的指数 backoff 算法,并在尝试到 sasl.login.retry.backoff.max.ms 设置指定的最大等待长度之间加倍。目前仅适用于 OAUTHBEARER。

sasl.oauthbearer.clock.skew.seconds

Type: int
Default: 30
Importance: low

(可选)值(以秒为单位),允许 OAuth/OIDC 身份提供程序和代理间的差别。

sasl.oauthbearer.expected.audience

Type: list
Default: null
Importance: low

(可选)代理用逗号分隔的设置来验证是否已为其中一个预期的受众发出 JWT。JWT 将检查是否有标准的 OAuth "aud" 声明,如果设置了这个值,代理将与 JWT 的"aud"声明中的值匹配,以查看是否有完全匹配。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.expected.issuer

Type: string
Default: null
Importance: low

代理的 (可选)用于验证 JWT 是否已由预期签发者创建的(可选)设置。JWT 将检查是否有标准 OAuth "iss" 声明,如果设置了这个值,代理会完全匹配 JWT 的"iss"声明中的内容。如果没有匹配项,代理将拒绝 JWT,身份验证将失败。

sasl.oauthbearer.jwks.endpoint.refresh.ms

Type: long
Default: 3600000 (1 hour)
Importance: low

(可选)代理在刷新其 JWKS (JSON Web Key Set)缓存之间等待的值,其中包含键以验证 JWT 的签名。

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

type: long
Default: 10000 (10 seconds)
Importance: low

(可选)尝试从外部身份验证提供程序检索 JWKS (JSON Web Key Set)之间的最大等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

Type: long
Default: 100
Importance: low

(可选)在 JWKS (JSON Web Key Set)检索外部身份验证提供程序尝试时的初始等待值(以毫秒为单位)。JWKS 检索使用基于 sasl.oauthbearer.jwks.endpoint.retry.backoff.ms 设置的初始等待算法的指数 backoff 算法,并在尝试到 sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms 设置所指定的最大等待长度之间加倍。

sasl.oauthbearer.scope.claim.name

Type: string
Default: scope
Importance: low

范围的 OAuth 声明通常命名为 "scope",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以提供用于 JWT 有效负载声明中包含的范围的名称。

sasl.oauthbearer.sub.claim.name

Type: string
Default: sub
Importance: low

该主题的 OAuth 声明通常命名为 "sub",但如果 OAuth/OIDC 供应商为该声明使用不同的名称,则此(可选)设置可以为 JWT 有效负载的声明中包含的主题提供不同的名称。

scheduled.rebalance.max.delay.ms

Type: int
Default: 300000 (5 minutes)
Valid Values: [0,…​,2147483647]
Importance: low

调度的最大延迟,以便在重新平衡和将连接器和任务重新分配到组前等待一个或多个分离的 worker 返回。在此期间,未分配的 worker 连接器和任务保持不变。

socket.connection.setup.timeout.max.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

客户端等待套接字连接建立的最大时间。当每个连续连接失败时,连接设置超时会达到这个最大值。为避免连接差异,将把一个随机化因值应用于超时,导致计算值高于 20% 的随机范围。

socket.connection.setup.timeout.ms

type: long
Default: 10000 (10 秒)
Valid Values: [0,…​]
Importance: low

客户端等待套接字连接建立的时间长度。如果在超时时间前没有构建连接,客户端将关闭套接字频道。

ssl.cipher.suites

Type: list
Default: null
Importance: low

密码套件列表。这是用来使用 TLS 或 SSL 网络协议协商网络连接的安全设置的身份验证、加密、MAC 和密钥交换算法的命名组合。默认情况下,支持所有可用的密码套件。

ssl.client.auth

Type: string
Default: none
Importance: low

配置 kafka 代理以请求客户端身份验证。以下设置是通用的:

  • 如果设为所需的客户端身份验证,则需要 ssl.client.auth=required
  • ssl.client.auth=requested 意味着客户端身份验证是可选的。与需要不同,如果设置此选项,则可以选择不提供有关其自身的身份验证信息
  • SSL.client.auth=none 意味着不需要客户端身份验证。
ssl.endpoint.identification.algorithm

Type: string
Default: https
Importance: low

使用服务器证书验证服务器主机名的端点标识算法。

ssl.engine.factory.class

Type: class
Default: null
Importance: low

org.apache.kafka.common.security.auth.SslEngineFactory 类型的类提供 SSLEngine 对象。默认值为 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory。

ssl.keymanager.algorithm

Type: string
Default: SunX509
Importance: low

密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。

ssl.secure.random.implementation

Type: string
Default: null
Importance: low

用于 SSL 加密操作的 SecureRandom PRNG 实施。

ssl.trustmanager.algorithm

Type: string
Default: PKIX
Importance: low

信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。

status.storage.partitions

Type: int
Default: 5
Valid Values: Positive number, 或 -1 使用代理的默认
导入: low

创建状态存储主题时使用的分区数量。

status.storage.replication.factor

Type: short
Default: 3
Valid Values: Positive number not larger than the Kafka 集群中的代理数,或 -1 使用代理的默认
导入: low

创建状态存储主题时使用的复制因素。

task.shutdown.graceful.timeout.ms

Type: long
Default: 5000 (5 seconds)
Importance: low

正常等待任务关闭的时间长度。这是总时间,而不是每个任务。所有任务都触发了关闭,然后按顺序等待它们。

topic.creation.enable

Type: boolean
Default: true
Importance: low

是否允许自动创建源连接器使用的主题,当源连接器配置了 topic.creation. 属性时。每个任务都将使用管理员客户端创建其主题,而不依赖于 Kafka 代理自动创建主题。

topic.tracking.allow.reset

Type: boolean
Default: true
Importance: low

如果设置为 true,则允许用户请求为每个连接器重置活跃主题的集合。

topic.tracking.enable

Type: boolean
Default: true
Importance: low

在运行时,启用跟踪每个连接器的活跃主题集合。

附录 G. Kafka Streams 配置参数

application.id

type: string
Importance: high

流处理应用的标识符。在 Kafka 集群中必须是唯一的。它被用作默认 client-id 前缀,即 2)用于成员资格管理的 group-id,3) changelog 主题前缀。

bootstrap.servers

type: list
Importance: high

用于建立到 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器与此处为引导指定的服务器无关 - 此列表仅影响用于发现完整服务器集的初始主机。此列表的格式应为 host1:port1,host2:port2,…​。由于这些服务器仅用于初始连接来发现完整的群集成员身份(可能会动态更改),因此此列表不需要包含整组服务器(但是如果服务器停机,您可能需要多个服务器)。

num.standby.replicas

Type: int
Default: 0
Importance: high

每个任务的待机副本数。

state.dir

type: string
Default: /tmp/kafka-streams
Importance: high

状态存储的目录位置。这个路径对于共享同一底层文件系统的每个流实例都必须是唯一的。

acceptable.recovery.lag

type: long
Default: 10000
Valid Values: [0,…​]
Importance: medium

客户端被视为活跃任务的最大可接受滞后(用于捕获的偏移数)。在给定工作负载的一分钟内与恢复时间相对应。必须至少为 0。

cache.max.bytes.buffering

type: long
Default: 10485760
Valid Values: [0,…​]
Importance: medium

在所有线程之间用于缓冲的最大内存字节数。

client.id

Type: string
Default: ""
Importance: medium

用于内部消费者、生成者和 restore-consumer 的客户端 ID 的 ID 前缀字符串,特征为 '<client.id>-StreamThread-<threadSequenceNumber>-<consumer|producer|restore-consumer>'。

default.deserialization.exception.handler

type: class
Default: org.apache.kafka.streams.errors.LogAndFailExceptionHandler
Importance: medium

实现 org.apache.kafka.streams.errors.DeserializationExceptionHandler 接口的异常处理类。

default.key.serde

Type: class
Default: null
Importance: medium

用于实现 org.apache.kafka.common.serialization.Serde 接口的密钥的默认序列化器/反序列化器类。请注意,当使用窗口的 serde 类时,还需要设置实现 org.apache.kafka.common.serialization.Serde 接口(通过 'default.windowed.key.serde.inner' 或 'default.windowed.value.serde.inner')的 inner serde 类。

default.list.key.serde.inner

Type: class
Default: null
Importance: medium

默认内部类是实施 org.apache.kafka.common.serialization.Serde 接口的关键。只有在 default.key.serde 配置被设置为 org.apache.kafka.common.serialization.Serdes.ListSerde 时,才会读取此配置。

default.list.key.serde.type

Type: class
Default: null
Importance: medium

用于实施 java.util.List 接口的密钥的默认类。当使用列表 serde 类时,只有 default.key.serde 配置被设置为 org.apache.kafka.common.serialization.Serdes.ListSerde s.ListSerde,才会读取此配置,它需要设置实现 org.apache.kafka.common.serialization.Serde 接口的 inner serde 类。

default.list.value.serde.inner

Type: class
Default: null
Importance: medium

默认内部类是实施 org.apache.kafka.common.serialization.Serde 接口的值。只有在 default.value.serde 配置被设置为 org.apache.kafka.common.serialization.Serdes.ListSerde 时,才会读取此配置。

default.list.value.serde.type

Type: class
Default: null
Importance: medium

用于实现 java.util.List 接口的值的默认类。只有在 default.value.serde 配置且只有这个设置被设置为 org.apache.kafka.common.serialization.Serdes.ListSerde 是才会从这个配置中读取。请注意,当使用 list serde 类时,一个需要设置 inner serde 类,它实现了 org.apache.kafka.common.serialization.Serde 接口(通过 'default.list.value.serde.inner')。

default.production.exception.handler

type: class
Default: org.apache.kafka.streams.errors.DefaultProductionExceptionHandler
Importance: medium

实现 org.apache.kafka.streams.errors.ProductionExceptionHandler 接口的异常处理类。

default.timestamp.extractor

type: class
Default: org.apache.kafka.streams.processor.FailOnInvalidTimestamp
Importance: medium

实现 org.apache.kafka.streams.processor.TimestampExtractor 接口的默认时间戳提取器类。

default.value.serde

Type: class
Default: null
Importance: medium

默认序列化器/反序列化器类用于实现 org.apache.kafka.common.serialization.Serde 接口的值。请注意,当使用窗口的 serde 类时,还需要设置实现 org.apache.kafka.common.serialization.Serde 接口(通过 'default.windowed.key.serde.inner' 或 'default.windowed.value.serde.inner')的 inner serde 类。

max.task.idle.ms

Type: long
Default: 0
Importance: medium

此配置控制加入和合并是否可能会产生超出顺序的结果。当流任务完全在某些(但不全部)输入分区上等待生成者发送额外记录并避免在多个输入流间处理时,配置值是流任务的最大时间(以毫秒为单位)。默认(零)不会等待生成者发送更多记录,但它会等待代理上已存在的数据。此默认值意味着对于已在代理上存在的记录,流将以时间戳顺序处理它们。设置为 -1 可完全禁用闲置并完全处理任何本地可用数据,即使这样做可能会生成没有顺序处理。

max.warmup.replicas

type: int
Default: 2
Valid Values: [1,…​]
Importance: medium

一次可以一次分配的 warmup 副本的最大数量(除配置的 num.standbys 之外),保持任务在一个实例上可用,同时将其重新分配给另一个实例。用于节流额外的代理流量和集群状态可用于高可用性。必须至少为 1。

num.stream.threads

Type: int
Default: 1
Importance: medium

执行流处理的线程数量。

processing.guarantee

Type: string
Default: at_least_once
Valid Values: [at_least_once, exactly_once, exactly_once_beta, exactly_once_v2]
Importance: medium

处理保证应使用。可能的值有 at_least_once (默认)和 exactly_once_v2 (需要代理版本 2.5 或更高版本)。弃用的选项为 exactly_once (需要代理版本 0.11.0 或更高版本)和 exactly_once_beta (需要代理版本 2.5 或更高版本)。请注意,完全处理需要至少三个代理的集群,这是生产的建议设置;通过调整代理设置 transaction.state.log.replication.factortransaction.state.log.min.isr

replication.factor

type: int
Default: -1
Importance: medium

更改由流处理应用程序创建的日志主题和重新分区主题的复制因素。默认值 -1 (主题:使用代理默认复制因素)需要代理版本 2.4 或更新版本。

security.protocol

Type: string
Default: PLAINTEXT
Importance: medium

用于与代理通信的协议。有效值为: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL。

task.timeout.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: medium

任务因为内部错误而停止的最大时间(以毫秒为单位),并重试直到引发错误为止。对于超时为 0ms,任务会引发第一个内部错误的错误。对于大于 0ms 的任何超时,任务将在引发错误前至少重试一次。

topology.optimization

Type: string
Default: none
Valid Values: [none, all]
Importance: medium

如果应该优化拓扑,则告知 Kafka Streams 的配置默认为禁用。

application.server

Type: string
Default: ""
Importance: low

host:port 对指向用户定义的端点,可用于此 KafkaStreams 实例上的状态存储发现和交互式查询。

buffered.records.per.partition

type: int
Default: 1000
Importance: low

每个分区要缓冲的最大记录数。

built.in.metrics.version

Type: string
Default: latest
Valid Values: [latest]
Importance: low

要使用的内置指标的版本。

commit.interval.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

保存处理器位置的频率(以毫秒为单位)。(请注意,如果 processing.guarantee 设置为 exactly_once_v2, exactly_once,则默认值为 100,否则默认值为 30000

connections.max.idle.ms

Type: long
Default: 540000 (9 minutes)
Importance: low

在这个配置指定的毫秒数后关闭闲置连接。

metadata.max.age.ms

Type: long
Default: 300000 (5 minutes)
Valid Values: [0,…​]
Importance: low

即使我们未看到任何分区领导力更改来主动发现任何新的代理或分区,我们才会强制刷新元数据的时间(以毫秒为单位)。

metric.reporters

Type: list
Default: ""
Importance: low

用作指标报告器的类列表。实施 org.apache.kafka.common.metrics.MetricsReporter 接口,允许插入将收到新指标创建通知的类。总是包括 JmxReporter 来注册 JMX 统计信息。

metrics.num.samples

type: int
Default: 2
Valid Values: [1,…​]
Importance: low

为计算指标维护的示例数量。

metrics.recording.level

Type: string
Default: INFO
Valid Values: [INFO, DEBUG, TRACE]
Importance: low

指标的最高记录级别。

metrics.sample.window.ms

type: long
Default: 30000 (30 秒)
Valid Values: [0,…​]
Importance: low

计算指标示例的时间窗口。

poll.ms

Type: long
Default: 100
Importance: low

阻止等待输入的时间(以毫秒为单位)。

probing.rebalance.interval.ms

Type: long
Default: 600000 (10 minutes)
Valid Values: [60000,…​]
Importance: low

触发重新平衡以探测到探测到回收完成并准备好激活的温副本前等待的时间(以毫秒为单位)。在分配平衡前,将继续触发重新平衡。必须至少为 1 分钟。

receive.buffer.bytes

type: int
Default: 32768 (32 kibibytes)
Valid Values: [-1,…​]
Importance: low

读取数据时要使用的 TCP 接收缓冲区(SO_RCVBUF)的大小。如果值为 -1,则使用操作系统默认值。

reconnect.backoff.max.ms

type: long
Default: 1000 (1 second)
Valid Values: [0,…​]
Importance: low

重新连接到重复连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供,每个主机的 backoff 将为每个连续的连接失败指数增加,直到最高值。在计算 backoff 增长后,添加了 20% 的随机 jitter,以避免连接状况。

reconnect.backoff.ms

type: long
Default: 50
Valid Values: [0,…​]
Importance: low

尝试重新连接到给定主机前等待的基本时间。这可避免在紧密循环中重复连接到主机。此 backoff 应用到客户端到代理的所有连接尝试。

request.timeout.ms

type: int
Default: 40000 (40 seconds)
Valid Values: [0,…​]
Importance: low

配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应,客户端将在需要时重新发送请求(如果重试用时失败)。

retries

type: int
Default: 0
Valid Values: [0,…​,2147483647]
Importance: low

设置大于零的值将导致客户端重新发送失败并可能出现临时错误的请求。建议将值设为 0 或 MAX_VALUE,并使用对应的超时参数来控制客户端应重试请求的时长。

retry.backoff.ms

Type: long
Default: 100
Valid Values: [0,…​]
Importance: low

尝试重试对给定主题分区失败的请求前等待的时间。这可避免在某些故障场景中的紧密循环中重复发送请求。

rocksdb.config.setter

Type: class
Default: null
Importance: low

实现 org.apache.kafka.streams.state.RocksDBConfigSetter 接口的 Rocks DB 配置 setter 类或类名称。

send.buffer.bytes

type: int
Default: 131072 (128 kibibytes)
Valid Values: [-1,…​]
Importance: low

发送数据时要使用的 TCP 发送缓冲区(SO_SNDBUF)的大小。如果值为 -1,则使用操作系统默认值。

state.cleanup.delay.ms

Type: long
Default: 600000 (10 minutes)
Importance: low

分区迁移时,在删除状态前等待的时间(以毫秒为单位)。只有尚未修改至少 状态的目录。cleanup.delay.ms 将被删除。

upgrade.from

Type: string
Default: null
Valid Values: [null, 0.10.0, 0.10.1, 0.10.2, 0.11.0, 1.0, 1.1, 2.0, 2.1, 2.2, 2.3]
Importance: low

允许以向后兼容的方式进行升级。从 [0.10.0.0, 1.1] 升级到 2.0+,或者从 [2.0, 2.3] 升级到 2.4+ 时需要。当从 2.4 升级到更新的版本时,不需要指定此配置。默认为 null。可介绍的值为 "0.10.0", "0.10.1", "0.10.2", "0.11.0", "1.0", "1.1", "2.0", "2.1", "2.2", "2.3" (从相应的旧版本进行升级)。

window.size.ms

Type: long
Default: null
Importance: low

为反序列化器设置窗口大小,以计算窗口结束时间。

windowed.inner.class.serde

Type: string
Default: null
Importance: low

窗口记录的内类的默认序列化器/反序列化器。必须实现 "
"'org.apache.kafka.common.serialization.Serde' 接口。请注意,在 KafkaStreams 应用程序中设置此配置会导致错误,因为它只用于从 Plain consumer 客户端中使用。

windowstore.changelog.additional.retention.ms

type: long
Default: 86400000 (1 day)
Importance: low

向窗口添加 maintainMs,以确保不会预先从日志中删除数据。允许时钟偏移。默认值为 1 天。

附录 H. 使用您的订阅

AMQ Streams 通过软件订阅提供。要管理您的订阅,请访问红帽客户门户中的帐户。

访问您的帐户

  1. 转至 access.redhat.com
  2. 如果您还没有帐户,请创建一个帐户。
  3. 登录到您的帐户。

激活订阅

  1. 转至 access.redhat.com
  2. 导航到 My Subscriptions
  3. 导航到 激活订阅 并输入您的 16 位激活号。

下载 Zip 和 Tar 文件

要访问 zip 或 tar 文件,请使用客户门户网站查找下载的相关文件。如果您使用 RPM 软件包,则不需要这一步。

  1. 打开浏览器并登录红帽客户门户网站 产品下载页面,网址为 access.redhat.com/downloads
  2. INTEGRATION AND AUTOMATION 目录中找到 AMQ Streams for Apache Kafka 项。
  3. 选择所需的 AMQ Streams 产品。此时会打开 Software Downloads 页面。
  4. 单击组件的 Download 链接。

更新于 2024-03-20

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat