Mirror Maker 配置实例
大致流程：
首先，我们会启动两套 Kafka 集群，它们是单节点的伪集群，监听端口分别是 9092 和 9093；
之后，我们会启动 MirrorMaker 工具，实时地将 9092 集群上的消息同步镜像到 9093 集群上；
最后，我们启动额外的消费者来验证消息是否拷贝成功。
第1步启动两套kafka 集群
第2步 启动 MirrorMaker 工具
consumer 文件
consumer.properties：
bootstrap.servers=localhost:9092
group.id=mirrormaker
auto.offset.reset=earliest
Producer 配置文件
producer.properties:
bootstrap.servers=localhost:9093
$ bin/kafka-mirror-maker.sh --producer.config ../producer.config --consumer.config ../consumer.config --num.streams 4 --whitelist ".*"
第三步 验证消息是否拷贝成功
同步之前最好在目标集群上把所要同步的所有主题 按照源集群上的规格等价的创建出来。
MirrorMaker 在镜像位移主题时，如果发现目标集群尚未创建该主题，它就会根据 Broker 端参数 offsets.topic.num.partitions 和 offsets.topic.replication.factor 的值来制定该主题的规格。默认配置是 50 个分区，每个分区 3 个副本。
其他跨集群的镜像方案：
1 Uber的uReplicator 工具
2 LinkedIn 开发的 Brooklin Mirror Maker 工具
3 Confluent 公司研发的 Replicator 工具（企业级收费）
36 Kafka 监控
A 监控维度
1）kakfa主机
2）JVM
3）Kafka 集群
所谓主机监控，指监控Kafka集群Broker所在的节点机器性能。
常见的主机监控指标大致包括以下几种：
机器负载（Load）
CPU 使用率
内存使用率，包括空闲内存（Free Memory）和已使用内存（Used Memory）
磁盘 I/O 使用率，包括读使用率和写使用率
网络 I/O 使用率
TCP 连接数
打开文件数
inode 使用情况
JVM监控
Full GC 发生频率和时长。这个指标帮助你评估 Full GC 对 Broker 进程的影响。长时间的停顿会令 Broker 端抛出各种超时异常。
活跃对象大小。这个指标是你设定堆大小的重要依据，同时它还能帮助你细粒度地调优 JVM 各个代的堆大小。
应用线程总数。这个指标帮助你了解 Broker 进程对 CPU 的使用情况。
集群监控
1. 查看 Broker 进程是否启动，端口是否建立。
2. 查看 Broker 端关键日志。要涉及 Broker 端服务器日志 server.log，控制器日志 controller.log 以及主题分区状态变更日志 state-change.log。
3 查看 Broker 端关键线程的运行状态。如Log Compaction,以 ReplicaFetcherThread 开头的线程
4 查看Broker端的关键JMX指标
BytesIn/BytesOut：即 Broker 端每秒入站和出站字节数。你要确保这组值不要接近你的网络带宽，否则这通常都表示网卡已被“打满”，很容易出现网络丢包的情形。
NetworkProcessorAvgIdlePercent：即网络线程池线程平均的空闲比例。通常来说，你应该确保这个 JMX 值长期大于 30%。如果小于这个值，就表明你的网络线程池非常繁忙，你需要通过增加网络线程数或将负载转移给其他服务器的方式，来给该 Broker 减负。
RequestHandlerAvgIdlePercent：即 I/O 线程池线程平均的空闲比例。同样地，如果该值长期小于 30%，你需要调整 I/O 线程池的数量，或者减少 Broker 端的负载。
UnderReplicatedPartitions：即未充分备份的分区数。所谓未充分备份，是指并非所有的 Follower 副本都和 Leader 副本保持同步。一旦出现了这种情况，通常都表明该分区有可能会出现数据丢失。因此，这是一个非常重要的 JMX 指标。
ISRShrink/ISRExpand：即 ISR 收缩和扩容的频次指标。如果你的环境中出现 ISR 中副本频繁进出的情形，那么这组值一定是很高的。这时，你要诊断下副本频繁进出 ISR 的原因，并采取适当的措施。
ActiveControllerCount：即当前处于激活状态的控制器的数量。正常情况下，Controller 所在 Broker 上的这个 JMX 指标值应该是 1，其他 Broker 上的这个值是 0。如果你发现存在多台 Broker 上该值都是 1 的情况，一定要赶快处理，处理方式主要是查看网络连通性。这种情况通常表明集群出现了脑裂。脑裂问题是非常严重的分布式故障，Kafka 目前依托 ZooKeeper 来防止脑裂。但一旦出现脑裂，Kafka 是无法保证正常工作的。
客户端监控
a> 关心的是客户端所在的机器与Kafka Broker 机器之间的网络往返时延（RTT）
b>kafka-producer-network-thread 开头的线程是你要实时监控的。它是负责实际消息发送的线程。一旦它挂掉了，Producer 将无法正常工作，但你的 Producer 进程不会自动挂掉，因此你有可能感知不到。对于消费者而言，心跳线程事关 Rebalance，也是必须要监控的一个线程。它的名字以 kafka-coordinator-heartbeat-thread 开头。