Kafka运维监控

消息格式和消息压缩

Kafka消息始终以成批的方式写入。一批消息的技术术语是一个记录批，并且一个记录批包含一个或多个记录。在简单的情况下，我们可以有一个包含单个记录的记录批。记录批和记录具有自己的标题。每个文件的格式如下图所示：

上图和日志文件输出项对应关系如下：

first offset          baseOffset(int64)
length                batchLength(int32)
leader epoch          partitionLeaderEpoch(int32)
magic                 magic(int8)
crc32                 crc(int32)
attributes            int16
                      bit0-2 0:no compression,1:snappy,2:lz4,3:zstd
                      4 timestampType
                      5 isTransactional
                      6 isControl
last offset delta     lastOffset
first timestamp       firstTimestamp(int64)
max timestampe        maxTimestamp(int64)
producer id           producerId(int64)
producer epoch        producerEpoch(int16)
first sequence        baseSequence(int32)
records count         count(int32)

Log Compact

Kafka 数据存放在磁盘上一般不会被永久保留，而是在到达一定的量或者时间后对最早写入的数据进行删除。Log Compaction 在默认的删除规则（clean.policy=delete）之外提供了另一种删除过时数据（或者说保留有价值的数据）的方式，Compaction的意思就是对于有相同 Key 的不同数据，只保留最后一条，前面的数据在合适的情况下删除。
日志压缩为我提供了更精细的保留机制，可以至少保留每个Key的最后一次更新。这样可以保证日志包含每个Key的最终值而不只是最近变更的快照。

日志清理状态

日志清理过程中主要涉及三种状态：

• **LogCleaningInProgress：**如果要清除日志，则将进入此状态。在清理分区时，可以请求中止和暂停清除
• **LogCleaningAborted：**清理任务中止后，分区将进入LogCleaningPaused状态
• **LogCleaningPaused：**当分区处于LogCleaningPaused状态时，将不再计划对其进行清理，直到请求恢复清理为止

清理流程

case class LogToClean(topicPartition: TopicPartition,
                              log: Log,
                              firstDirtyOffset: Long,
                              uncleanableOffset: Long,
                              needCompactionNow: Boolean = false) extends Ordered[LogToClean] {
  // firstDirtyOffset：表示本次清理的起始点，其前边的offset将被作清理，并与在其后的message作key的合并;
  val cleanBytes = log.logSegments(-1, firstDirtyOffset).map(_.size.toLong).sum
  val (firstUncleanableOffset, cleanableBytes) = LogCleanerManager.calculateCleanableBytes(log, firstDirtyOffset, uncleanableOffset)
  val totalBytes = cleanBytes + cleanableBytes
  // 需要清理的log的比例。这个值越大，越可能被选中清理
  val cleanableRatio = cleanableBytes / totalBytes.toDouble
  override def compare(that: LogToClean): Int = math.signum(this.cleanableRatio - that.cleanableRatio).toInt
}

日志压缩由Log Cleaner执行，后台线程池重新拷贝日志段，移除那些key存在于Log Head中的记录。每个压缩线程如下工作：

1. 选择Log head与Log tail比率最高的日志
2. 在Head log中为每个Key的最后offset创建一个的简单概要
3. 从日志的开始到结束，删除那些在日志中最新出现的Key的旧值。新的日志立即被交换到日志中，所以只需要一个额外的日志段空间（不是日志的完整副本）

Kafka运维

迁移扩容

Kafka集群中增加Broker非常方便，只需为其分配唯一的 broker ID并在您的新服务器上启动Kafka，但是Topic的Partition不会因为集群中broker的增而自动增加，这些新的服务器也不会自动分配到任何数据分区，除非将分区移动到这些分区，否则直到创建新 topic 时才会提供服务。
每个Partition只有Leader副本对外提供读写服务，并且Partition创建时候默认的Leader副本位于首选，此时Kafka集群是负载均衡的。但当某个Broker宕机，就会导致Leader发生迁移，导致Leader在Kafka集群中不在均衡，因此某些节点的压力会明显大于其他节点。
这个时候我们可以对数据进行迁移或者扩容，以实现再均衡。迁移步骤如下：

1.创建迁移文件

vim topic-move.json

文件内容如下：

{
    "topics": [
        {"topic": "Topic-02"}
    ],
    "version":1 
}

2.生成分区分配计划

主要目的是帮助生成迁移文件

kafka-reassign-partitions.sh --zookeeper localhost:2182 --topics-to-move-json-file topic-move.json --broker-list "2" --generate

3.执行分区分配计划

kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file topic-reassign.json --execute

4.验证分区分配

afka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file topic-reassign.json --verify

Mirror-Maker

Kakfa MirrorMaker是Kafka 官方提供的跨数据中心的流数据同步方案。其实现原理，其实就是通过从Source Cluster消费消息然后将消息生产到Target Cluster，即普通的消息生产和消费。用户只要通过简单的Consumer配置和Producer配置，然后启动Mirror，就可以实现准实时的数据同步。

源集群和目标集群是完全独立的集群：它们可以具有不同数量的分区，偏移量也不同。基于这个原因，镜像集群实际上并不是要用作容错机制（因为Consumer Offset会有所不同）

Kafka自带用于在Kafka群集之间镜像数据的工具。该工具在源集群使用，然后生成到目标集群。这种镜像的常见用例是为一个数据中心提供副本。

使用示例

下面示例了如何从输入集群中镜像名为my-topic主题

bin/kafka-mirror-maker.sh \
      --consumer.config consumer.properties \
      --producer.config producer.properties --whitelist my-topic

–whitelist选项可以用于指定主题列表。此选项允许使用Java的正则表达式。

• 使用–whitelist’A | B’镜像两个名为A和B的主题。可以使用’，‘代替’|'指定主题列表
• 使用–whitelist’*'镜像所有主题

将镜像与配置auto.create.topics.enable = true结合使用，就可以拥有一个副本集群，即使添加新主题，该副本集群也会自动创建和复制源集群中的所有数据

消费者配置文件

consumer.properties主要配置Kafka源集群消费者相关信息

bootstrap-server=192.168.56.105:9092,192.168.56.105:9093,192.168.56.105:9094
group.id=mirrormaker-consumer

生产者配置文件

bootstrap-server=192.168.56.105:10092,192.168.56.105:10093,192.168.56.105:10094

Kafka监控

Kafka使用Yammer Metrics来监控服务器的运行指标。Java客户端可以使用Kafka Metrics，它是一个内置的指标注册表，可最大程度地减少客户端应用程序需要拉取的依赖项。两者都通过JMX暴露指标，并且通过配置可插拔指标统计组件连接到监控系统以便进行指标统计

Yammer Metrics

Yammer Metrics提供六种形式的Metrics收集——Meters，Gauges，Counters，Histograms，Timers，Health Checks。
与此同时，Yammer Metrics将Metric的收集与报告（或者说发布）分离，可以根据需要自由组合。目前它支持的Reporter有Console Reporter，JMX Reporter，HTTP Reporter，CSV Reporter，SLF4J Reporter，Ganglia Reporter，Graphite Reporter。因此，Kafka也支持通过以上几种Reporter输出其Metrics信息。

• Registry：Metrics的核心是MetricRegistry类，该类是所有应用程序指标的容器
• Gauges：瞬时测量值
• Counters：AtomicLong 实例的一个计量器。如：想用更有效的方式来测量队列中的Job
• Meters：测量一段时间内事件的发生率（如：“每秒请求数”）
• Histograms：测量数据流中值的统计分布
• Timers：测量执行一段代码所需的时间及其持续时间的分布
• Healthy checks：服务对外部系统的健康检查

由于Jconsole JMX只能针对某个Broker节点查看统计指标。如果需要监控整个集群，我们可以通过开源的产品来对整个Kafka集群进行运维和监控：

1. Yahoo CMAK（原名为Kafka Manager）
2. 滴滴Kafka_manager（以Kafka Manager为基础进行优化）