适用于Apache Kafka的巡航控制

简介

巡航控制是一款帮助大规模运行Apache Kafka集群的产品。由于Apache Kafka的普及,许多公司的Kafka集群越来越大。在LinkedIn,我们有7000多个Kafka代理,这意味着代理宕机几乎是一个日常事件,并且平衡Kafka的工作负载也成为一个大负担。

Kafka巡航控制旨在解决这一操作可扩展性问题。

功能

Kafka巡航控制提供以下开箱即用的功能:

跟踪代理、主题和分区的资源利用率。
查询当前Kafka集群状态,查看在线和离线分区、同步和不同步副本、在min.insync.replicas下的副本、在线和离线日志目录以及集群中副本的分布情况。
针对以下目标生成多目标再平衡方案:
- 机架感知
- 资源容量违规检查(CPU、磁盘、网络I/O)
- 每个代理副本计数违规检查
- 资源利用率平衡(CPU、磁盘、网络I/O)
- 领导者流量分布
- 主题副本分布
- 全局副本分布
- 全局领导者副本分布
- 自定义目标
检测Kafka集群异常、发出警报并自我修复,包括:
- 目标违规
- 代理故障检测
- 指标异常检测
- 磁盘故障检测(在kafka_0_11_and_1_0分支中不可用)
- 慢代理检测(在kafka_0_11_and_1_0分支中不可用)
管理操作,包括:
- 添加代理
- 移除代理
- 降级代理
- 重新平衡集群
- 修复离线副本(在kafka_0_11_and_1_0分支中不可用)
- 执行首选领导者选举(PLE)
- 修复离线副本
- 调整复制因子

环境要求

Cruise Control的main(先前的migrate_to_kafka_2_5)分支与Apache Kafka 2.5+(即Releases带有2.5.*), 2.6(即Releases带有2.5.11+), 2.7(即Releases带有2.5.36+), 2.8(即Releases带有2.5.66+), 3.0(即Releases带有2.5.85+)和3.1(即Releases带有2.5.85+)兼容。
Cruise Control的migrate_to_kafka_2_4分支与Apache Kafka 2.4(即Releases带有2.4.*)兼容。
Cruise Control的kafka_2_0_to_2_3分支(已弃用)与Apache Kafka 2.0、2.1、2.2和2.3(即Releases带有2.0.*)兼容。
Cruise Control的kafka_0_11_and_1_0分支(已弃用)与Apache Kafka 0.11.0.0、1.0和1.1(即Releases带有0.1.*)兼容。
需要message.format.version 0.10.0及以上。
kafka_2_0_to_2_3和kafka_0_11_and_1_0分支使用Scala 2.11编译。
migrate_to_kafka_2_4分支使用Scala 2.12编译。
migrate_to_kafka_2_5分支使用Scala 2.13编译。
本项目需要Java 11。

已知的兼容性问题

支持Apache Kafka 2.0、2.1、2.2和2.3需要KAFKA-8875修复程序。

快速开始

获取Cruise Control
1. (选项1): 通过git clone
  - git clone https://github.com/linkedin/cruise-control.git && cd cruise-control/
2. (选项2): 通过浏览可用版本:
  - 浏览https://github.com/linkedin/cruise-control/releases选择一个版本 -- 例如0.1.10
  - 获取并解压缩版本: wget https://github.com/linkedin/cruise-control/archive/0.1.10.tar.gz && tar zxvf 0.1.10.tar.gz && cd cruise-control-0.1.10/
  - 初始化本地仓库: git init && git add . && git commit -m "Init local repo." && git tag -a 0.1.10 -m "Init local version."
如果使用CruiseControlMetricsReporter进行指标收集(即Cruise Control的默认设置),则需要执行此步骤。指标报告器会定期对代理上的原始Kafka指标进行采样并将其发送到Kafka主题。
- ./gradlew jar (注意: 本项目需要Java 11)
- 将./cruise-control-metrics-reporter/build/libs/cruise-control-metrics-reporter-A.B.C.jar(其中A.B.C是Cruise Control的版本)复制到Kafka服务器依赖项jar文件夹。对于Apache Kafka,文件夹为core/build/dependant-libs-SCALA_VERSION/(对于Kafka源检出)或libs/(对于Kafka发行版下载)。
- 修改Kafka服务器配置,将metric.reporters设置为com.linkedin.kafka.cruisecontrol.metricsreporter.CruiseControlMetricsReporter。对于Apache Kafka,服务器属性位于./config/server.properties。
- 如果启用了SSL,请确保为所有代理在./config/server.properties中正确设置相关的客户端配置。请注意,CruiseControlMetricsReporter使用KafkaProducer的所有配置,但前缀为cruise.control.metrics.reporter.(例如cruise.control.metrics.reporter.ssl.truststore.password)。
- 如果默认的代理清理策略是compact,请确保创建Cruise Control指标报告器应发送消息的主题时使用delete清理策略 -- 默认的指标报告器主题是__CruiseControlMetrics。
启动ZooKeeper和Kafka服务器(见教程).
修改Cruise Control的config/cruisecontrol.properties:
- (必需)填写要监控的Kafka集群的bootstrap.servers和zookeeper.connect。
- (必需)更新capacity.config.file以指向您的容量文件。
  - 容量文件是一个JSON文件,提供了代理的容量信息
  - 您可以使用默认文件(config/capacityJBOD.json)启动Cruise Control服务器,但它可能无法反映代理的实际容量
  - 有关更多信息和示例,请参阅BrokerCapacityConfigurationFileResolver configurations
- (可选)将metric.sampler.class设置为您自己的实现(默认采样器类是CruiseControlMetricsReporterSampler)
- (可选)如果您有自己的实现,将sample.store.class设置为您的实现(默认的SampleStore是KafkaSampleStore)
运行以下命令
```
./gradlew jar copyDependantLibs
./kafka-cruise-control-start.sh [-jars PATH_TO_YOUR_JAR_1,PATH_TO_YOUR_JAR_2] config/cruisecontrol.properties [port]
```
JAR文件对应于您的应用程序,port用于自定义Cruise Control端口号(默认: 9090)。
- (注意)要在特定端口(例如56666)上发出Cruise Control JMX指标,请在运行kafka-cruise-control-start.sh之前执行export JMX_PORT=56666
(验证您的设置)访问http://localhost:9090/kafkacruisecontrol/state(或者如果您在启动Cruise Control时指定了端口,则访问http://localhost:[port]/kafkacruisecontrol/state)。

注意:

Cruise Control需要一些时间从集群中读取原始Kafka指标。
新上线代理的指标可能需要几分钟才能稳定下来。Cruise Control会丢弃不一致的指标(例如当主题字节输入高于代理字节输入时),所以前几个窗口可能没有足够的有效分区。

REST API

Cruise Control提供了一个REST API,供用户与之交互。更多详细信息请参见维基页面。

它是如何工作的

Cruise Control依赖于副本的最近负载信息来优化集群。

Cruise Control定期收集代理级别和分区级别的资源利用率样本,以推断每个分区的流量模式。基于所有分区的流量特性和分布,它推导出每个分区对代理的负载影响。Cruise Control然后构建一个工作负载模型来模拟Kafka集群的工作负载。目标优化器根据用户指定的目标列表探索不同的方式来生成集群工作负载优化方案。

Cruise Control还监控集群中所有代理的存活状态。为了避免冗余丢失,Cruise Control会自动将副本从失败的代理移动到存活的代理上。

关于Cruise Control如何实现这一点的更多详细信息,请参见这些幻灯片。

Cruise Control的配置

要了解更多关于配置的信息,请查看配置维基页面。

Artifactory

在Jfrog Artifactory发布。请参见可用版本。

可插拔组件

关于可插拔组件的更多信息,请参见可插拔组件维基页面。

指标采样器

指标采样器使用户能够将Cruise Control部署到各种环境中,并与现有的指标系统协作。

Cruise Control提供了一个可在Apache Kafka服务器中配置的指标报告程序。指标报告程序会将性能指标生成到一个Kafka指标主题,该主题可由Cruise Control使用。

样本存储

样本存储使收集的指标样本和训练样本能够存储在外部存储中。度量抽样使用原始指标的派生数据,派生数据的准确性取决于集群在该时间点的元数据。因此,当我们查看旧指标时,如果我们不知道收集指标时的元数据,派生数据就不会准确。Sample Store通过直接将派生数据存储到外部存储以供后续加载来解决这个问题。

默认的Sample Store实现将指标样本反馈到Kafka。

目标

Cruise Control中的目标是可插拔的,具有不同的优先级。默认目标按优先级降序如下:

RackAwareGoal - 确保每个分区的所有副本以机架感知方式分配 - 即每个分区最多只有一个副本驻留在同一机架上。
RackAwareDistributionGoal - RackAwareGoal的放宽版本。与RackAwareGoal相反,只要每个分区的副本能够在机架之间实现完美的均匀分布,这个目标就允许将多个分区副本放置在单个机架中。
MinTopicLeadersPerBrokerGoal - 确保每个存活的代理至少拥有某些配置主题的一定数量的Leader副本。
ReplicaCapacityGoal - 确保每个代理的副本数不超过指定的最大限制。
DiskCapacityGoal - 确保每个代理的磁盘空间使用率低于给定阈值。
NetworkInboundCapacityGoal - 确保每个代理的入站网络利用率低于给定阈值。
NetworkOutboundCapacityGoal - 确保每个代理的出站网络利用率低于给定阈值。
CpuCapacityGoal - 确保每个代理的CPU利用率低于给定阈值。
ReplicaDistributionGoal - 试图使集群中所有代理的副本数量相似。
PotentialNwOutGoal - 确保每个代理在所有副本都成为Leader时的潜在网络输出不超过代理的网络出站带宽容量。
DiskUsageDistributionGoal - 试图将代理之间的磁盘空间使用率方差保持在相对于平均磁盘利用率的某个范围内。
NetworkInboundUsageDistributionGoal - 试图将代理之间的入站网络利用率方差保持在相对于平均入站网络利用率的某个范围内。
NetworkOutboundUsageDistributionGoal - 试图将代理之间的出站网络利用率方差保持在相对于平均出站网络利用率的某个范围内。
CpuUsageDistributionGoal - 试图将代理之间的CPU使用率方差保持在相对于平均CPU利用率的某个范围内。
LeaderReplicaDistributionGoal - 试图使集群中所有代理的Leader副本数量相似。
LeaderBytesInDistributionGoal - 尝试使每个主机的Leader输入字节率均等。
TopicReplicaDistributionGoal - 试图在整个集群中维持任何主题分区的均匀分布。
PreferredLeaderElectionGoal - 简单地将Leaders移动到每个分区的第一个副本。
KafkaAssignerDiskUsageDistributionGoal - (Kafka-assigner模式)试图根据交换机制在代理之间均匀分配磁盘使用率。
IntraBrokerDiskCapacityGoal - (Rebalance-disk模式,不适用于kafka_0_11_and_1_0分支)确保每个磁盘的磁盘空间使用率低于给定阈值。
IntraBrokerDiskUsageDistributionGoal - (Rebalance-disk模式,不适用于kafka_0_11_and_1_0分支)试图将代理之间的磁盘空间使用率方差保持在相对于平均代理磁盘利用率的某个范围内。