上一篇【第65篇】Kafka故障转移实战——Broker宕机了怎么办下一篇【第67篇】Kafka请求处理机制深度解析——生产请求与获取请求的完整链路摘要配置调好了副本设置好了你以为万事大吉了别急——“配对了不一定等于真的可靠”。生产环境的可靠性必须经过实际验证才能真正放心。Netflix把Chaos Monkey放进了生产环境我们至少得在测试环境炸一炸。本文介绍三种验证方式用Kafka自带的VerifiableProducer/VerifiableConsumer做确定性测试用配置checklist逐项排查风险以及用混沌工程的方法注入故障来验证系统的韧性。最后给出可靠性SLA的量化衡量标准让你可以用数字说话。一、验证方法论——三种武器【Kafka可靠性验证三大手段】 ┌─────────────────────────────────────────────────┐ │ 可靠性验证方法 │ │ │ │ ┌─────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ 工具测试 │ │ 配置审计 │ │ 混沌工程 │ │ │ │ │ │ │ │ │ │ │ │ Verifiable│ │ Checklist│ │ 故障注入 │ │ │ │ Producer │ │ 逐项排查 │ │ 主动破坏 │ │ │ │ Consumer │ │ 人工检查 │ │ 观察恢复 │ │ │ └────┬────┘ └────┬─────┘ └──────┬───────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ 数据不丢验证 配置是否正确 故障是否自动恢复 │ │ │ └─────────────────────────────────────────────────┘二、工具测试——Kafka官方验证套件2.1 VerifiableProducerKafka自带的VerifiableProducer可以发送带序列号的消息用来精确定位丢失和重复# 启动 VerifiableProducer# 它每秒发送指定数量的消息每条消息包含递增的序列号kafka-verifiable-producer.sh\--bootstrap-server localhost:9092\--topicverify-topic\--max-messages100000\--throughput1000\--acksall\--producer.configproducer.properties输出格式// 每条消息发送后输出{name:startup_complete}{name:producer_send_success,key:null,value:0,// 序列号第0条offset:0,// Broker端offsettimestamp:1717056000000}{name:producer_send_success,key:null,value:1,offset:1,timestamp:1717056000100}...{name:shutdown_complete,sent:100000,acked:99998,// ← 少确认了2条可能是丢了duplicates:15,// ← 有15条重复了connection_closed:5// ← 连接关闭了5次说明有故障发生}2.2 VerifiableConsumer消费者端也有配套工具# 启动 VerifiableConsumerkafka-verifiable-consumer.sh\--bootstrap-server localhost:9092\--topicverify-topic\--group-id verify-group\--max-messages100000\--enable-autocommitfalse输出对比# 消费端输出格式{name:record_consumed,topic:verify-topic,partition:0,key:null,value:42, // 序列号offset:42}# 验证脚本对比生产端和消费端的序列号# 生产端发送 0,1,2,...,99999# 消费端收到 0,1,2,...,99999 ← 完美# 消费端收到 0,1,2,4,5,... ← 丢了3号!# 消费端收到 0,1,2,2,3,... ← 2号重复了!2.3 自动化可靠性测试脚本#!/bin/bash# reliability-test.sh端到端可靠性测试TOPICreliability-test-$(date%s)BROKERlocalhost:9092TOTAL_MSGS100000THROUGHPUT5000echo Kafka 可靠性测试 # 1. 创建测试Topic3副本kafka-topics.sh --bootstrap-server$BROKER\--create--topic$TOPIC\--partitions3--replication-factor3\--configmin.insync.replicas2# 2. 启动消费者监听后台kafka-verifiable-consumer.sh\--bootstrap-server$BROKER\--topic$TOPIC\--group-idverify-$TOPIC\--max-messages$TOTAL_MSGS\consumer_output.jsonCONSUMER_PID$!# 3. 生产消息kafka-verifiable-producer.sh\--bootstrap-server$BROKER\--topic$TOPIC\--max-messages$TOTAL_MSGS\--throughput$THROUGHPUT\--acksall\producer_output.json# 4. 等待消费者完成wait$CONSUMER_PID# 5. 分析结果echo 生产端统计 SENT$(grepproducer_send_successproducer_output.json|wc-l)echo 成功发送:$TOTAL_MSGSecho 预期消费:$SENTecho 消费端统计 CONSUMED$(greprecord_consumedconsumer_output.json|wc-l)echo 实际消费:$CONSUMED# 6. 判断LOSS$((TOTAL_MSGS-CONSUMED))if[$LOSS-gt0];thenecho❌ 丢失了$LOSS条消息!exit1elseecho✅ 消息零丢失测试通过!fi# 7. 清理kafka-topics.sh --bootstrap-server$BROKER--delete--topic$TOPIC三、配置审计 —— 逐项排查checklist光测试还不够配置项的完整性检查同样重要【生产环境 Kafka 可靠性配置检查清单】 □ Broker 端配置 ✅ 副本数 • default.replication.factor ≥ 3 • 关键 Topic 的 replication-factor ≥ 3 ✅ ISR 保护 • min.insync.replicas ≥ 2 • 关键 Topic: min.insync.replicas 2 (RF3 时) ✅ 不稳定选举禁止 • unclean.leader.election.enable false • 绝对不能改成 true ✅ Controller 稳定性 • controller.election.rate.limit 默认 • (KRaft) controller.quorum.voters 3个或5个 ✅ 磁盘保护 • log.dirs 配置多个目录不同磁盘 • log.retention.hours ≥ 72h至少保留3天 • log.segment.bytes ≤ 1GB分段不要太大 ✅ 网络 • num.network.threads ≥ num.brokers • listeners 与 advertised.listeners 配置正确 ✅ 安全 • 生产环境开启 SASL 认证 • 生产环境开启 ACL 授权 • 生产环境开启 TLS 加密 □ Producer 端配置 ✅ acks all或相关参数幂等性自动设置 ✅ enable.idempotence true ✅ retries 设置了合理值 ✅ 有发送失败的回调处理 兜底机制 □ Consumer 端配置 ✅ enable.auto.commit false ✅ 实现了 ConsumerRebalanceListener ✅ 有关闭前 commitSync() ✅ 消费端有幂等去重机制 ✅ session.timeout.ms / max.poll.interval.ms 设置合理 □ 运维准备 ✅ 有 Prometheus Grafana 监控 ✅ 配置了关键告警规则ISR缩减/消费Lag/节点下线 ✅ 滚动重启步骤已文档化并验证 ✅ 有多机房灾备方案对关键业务四、混沌工程——主动炸系统4.1 故障注入矩阵【Kafka混沌工程故障注入矩阵】 ┌────────────────────────────────────────────────┐ │ 故障类型 │ 注入方法 │ 预期行为 │ ├────────────────────────────────────────────────┤ │ 1. 杀 Broker 进程 │ kill -9 pid │ 自动选举 │ │ │ │ 写入恢复 │ ├────────────────────────────────────────────────┤ │ 2. 网络延迟 │ tc qdisc add ... │ 吞吐下降 │ │ │ netem delay 100ms │ 不丢数据 │ ├────────────────────────────────────────────────┤ │ 3. 网络分区 │ iptables -A ... -j │ 脑裂防护 │ │ │ DROP │ 分区不可用 │ ├────────────────────────────────────────────────┤ │ 4. 磁盘满 │ dd if/dev/zero │ 拒绝写入 │ │ │ of/kafka/bigfile │ 已存数据 │ │ │ bs1M count10000 │ 不受影响 │ ├────────────────────────────────────────────────┤ │ 5. 磁盘慢 │ cgroup blkio 限制 │ 写延迟增加 │ │ │ │ 可能踢出ISR│ ├────────────────────────────────────────────────┤ │ 6. CPU 压力 │ stress --cpu 8 │ 吞吐下降 │ │ │ │ 超时增加 │ ├────────────────────────────────────────────────┤ │ 7. 内存压力 │ stress --vm 4 │ GC 增加 │ │ │ │ 页缓存被挤 │ ├────────────────────────────────────────────────┤ │ 8. ZooKeeper 挂 │ kill ZK进程 │ 集群不可用 │ │ │ (KRaft不受影响) │ 但已有数据 │ │ │ │ 不丢 │ └────────────────────────────────────────────────┘4.2 故障注入脚本#!/bin/bash# chaos-test.shKafka混沌测试BROKERlocalhost:9092TOPICchaos-testBROKER_PIDS($(psaux|grepkafka.Kafka|grep-vgrep|awk{print $2}))echo Kafka 混沌测试开始 echo目标Broker PIDs:${BROKER_PIDS[]}# 测试1杀一个Follower Brokerecho--- 测试1杀Follower ---# 先确认哪个是Followerkafka-topics.sh --bootstrap-server$BROKER--describe--topic$TOPIC# 假设Broker3是Follower杀它echo杀掉Broker3# 通过SSH在其他机器执行:# ssh broker3 kill -9 \$(ps aux | grep kafka.Kafka | grep -v grep | awk {print \$2})sleep30echo检查分区状态...kafka-topics.sh --bootstrap-server$BROKER--describe--topic$TOPICecho--- 预期ISR减少写入不受影响 ---# 测试2制造网络延迟echo--- 测试2网络延迟100ms ---# sudo tc qdisc add dev eth0 root netem delay 100mssleep60echo监控吞吐量变化...echo--- 预期吞吐下降但数据不丢 ---# 清理# sudo tc qdisc del dev eth0 root# 测试3磁盘满echo--- 测试3磁盘快满了 ---# 创建一个超大文件占磁盘# dd if/dev/zero of/kafka-data/bigfile bs1M count1000sleep30echo尝试写入...预期拒绝写入而非丢数据# 清理# rm /kafka-data/bigfileecho 混沌测试完成 4.3 测试分析【混沌测试分析表】 测试项 | 预期 | 实际 | 通过 ─────────────────┼──────────────┼──────────────┼────── 杀Follower | 写入不受影响 | 写入正常 | ✅ 杀Leader | 秒级恢复 | 8秒恢复 | ✅ 网络延迟100ms | 吞吐下降50% | 吞吐下降48% | ✅ 磁盘满 | 拒绝写入 | 拒绝写入 | ✅ 断电(硬杀) | 数据不丢 | 丢失0条 | ✅ 连杀2个Broker | 写入拒绝 | 写入拒绝 | ✅ 恢复2个Broker | ISR恢复 | 30秒后恢复 | ✅ 测试结论系统可靠性能达到99.99%数据持久性五、可靠性SLA量化5.1 关键指标【Kafka 可靠性 SLA 指标】 1. 数据持久性Durability ┌────────────────────────────────────────────┐ │ 公式已成功确认消息数 / (已成功确认丢失) │ │ │ │ 目标99.999% (五个9) │ │ 意味着一天写入1亿条最多丢1000条 │ └────────────────────────────────────────────┘ 2. 写入可用性Availability - Write ┌────────────────────────────────────────────┐ │ 公式写入成功时间 / 总时间 │ │ │ │ 目标99.95% │ │ 意味着每月停机不超过21分钟 │ └────────────────────────────────────────────┘ 3. 故障恢复时间MTTR - Mean Time To Recover ┌────────────────────────────────────────────┐ │ 关键指标 │ │ • Leader 选举时间 10秒 │ │ • ISR 恢复时间 5分钟100GB数据量 │ │ • 全量副本同步时间 30分钟 │ └────────────────────────────────────────────┘5.2 监控指标# Prometheus 关键告警规则groups:-name:kafka_reliabilityrules:# 告警1ISR 缩减-alert:KafkaUnderReplicatedPartitionsexpr:kafka_server_replicamanager_underreplicatedpartitions0for:1mlabels:severity:criticalannotations:summary:存在 Under-Replicated 分区description:当前 {{ $value }} 个分区的副本不足数据可靠性降低# 告警2离线分区-alert:KafkaOfflinePartitionsexpr:kafka_controller_kafkacontroller_offlinepartitionscount0for:30slabels:severity:criticalannotations:summary:存在离线分区description:{{ $value }} 个分区处于离线状态数据不可读写# 告警3活跃 Controller 数-alert:KafkaNoActiveControllerexpr:kafka_controller_kafkacontroller_activecontrollercount 0for:1mlabels:severity:criticalannotations:summary:没有活跃的 Controllerdescription:集群没有ControllerLeader选举无法进行# 告警4ISR 扩展速率-alert:KafkaISRShrinkRateexpr:rate(kafka_server_replicamanager_isrshrinks_total[5m])0.1for:5mlabels:severity:warningannotations:summary:ISR 频繁缩减description:ISR 缩减速率: {{ $value }}/秒可能存在网络问题本篇小结可靠性的验证不是一次性的而是一个持续的过程工具测试用VerifiableProducer/Consumer做确定性测试精确衡量丢失率和重复率配置审计逐项检查Broker/Producer/Consumer的配置是否满足可靠性要求混沌工程主动注入故障验证系统在异常下的行为是否符合预期SLA量化用数字衡量可靠性——持久性99.999%、可用性99.95%、故障恢复10秒记住生产环境的可靠性不能用我觉得没问题来衡量必须用测试数据说话。下一篇我们换个角度——从请求处理的底层机制来看一条Produce请求从到达到响应在Broker内部经历了什么。上一篇【第65篇】Kafka故障转移实战——Broker宕机了怎么办下一篇【第67篇】Kafka请求处理机制深度解析——生产请求与获取请求的完整链路
【Kafka源码解读和使用指南】第66篇：Kafka生产环境系统可靠性验证——测试套件与混沌工程
发布时间：2026/6/14 23:26:19
上一篇【第65篇】Kafka故障转移实战——Broker宕机了怎么办下一篇【第67篇】Kafka请求处理机制深度解析——生产请求与获取请求的完整链路摘要配置调好了副本设置好了你以为万事大吉了别急——“配对了不一定等于真的可靠”。生产环境的可靠性必须经过实际验证才能真正放心。Netflix把Chaos Monkey放进了生产环境我们至少得在测试环境炸一炸。本文介绍三种验证方式用Kafka自带的VerifiableProducer/VerifiableConsumer做确定性测试用配置checklist逐项排查风险以及用混沌工程的方法注入故障来验证系统的韧性。最后给出可靠性SLA的量化衡量标准让你可以用数字说话。一、验证方法论——三种武器【Kafka可靠性验证三大手段】 ┌─────────────────────────────────────────────────┐ │ 可靠性验证方法 │ │ │ │ ┌─────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ 工具测试 │ │ 配置审计 │ │ 混沌工程 │ │ │ │ │ │ │ │ │ │ │ │ Verifiable│ │ Checklist│ │ 故障注入 │ │ │ │ Producer │ │ 逐项排查 │ │ 主动破坏 │ │ │ │ Consumer │ │ 人工检查 │ │ 观察恢复 │ │ │ └────┬────┘ └────┬─────┘ └──────┬───────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ 数据不丢验证 配置是否正确 故障是否自动恢复 │ │ │ └─────────────────────────────────────────────────┘二、工具测试——Kafka官方验证套件2.1 VerifiableProducerKafka自带的VerifiableProducer可以发送带序列号的消息用来精确定位丢失和重复# 启动 VerifiableProducer# 它每秒发送指定数量的消息每条消息包含递增的序列号kafka-verifiable-producer.sh\--bootstrap-server localhost:9092\--topicverify-topic\--max-messages100000\--throughput1000\--acksall\--producer.configproducer.properties输出格式// 每条消息发送后输出{name:startup_complete}{name:producer_send_success,key:null,value:0,// 序列号第0条offset:0,// Broker端offsettimestamp:1717056000000}{name:producer_send_success,key:null,value:1,offset:1,timestamp:1717056000100}...{name:shutdown_complete,sent:100000,acked:99998,// ← 少确认了2条可能是丢了duplicates:15,// ← 有15条重复了connection_closed:5// ← 连接关闭了5次说明有故障发生}2.2 VerifiableConsumer消费者端也有配套工具# 启动 VerifiableConsumerkafka-verifiable-consumer.sh\--bootstrap-server localhost:9092\--topicverify-topic\--group-id verify-group\--max-messages100000\--enable-autocommitfalse输出对比# 消费端输出格式{name:record_consumed,topic:verify-topic,partition:0,key:null,value:42, // 序列号offset:42}# 验证脚本对比生产端和消费端的序列号# 生产端发送 0,1,2,...,99999# 消费端收到 0,1,2,...,99999 ← 完美# 消费端收到 0,1,2,4,5,... ← 丢了3号!# 消费端收到 0,1,2,2,3,... ← 2号重复了!2.3 自动化可靠性测试脚本#!/bin/bash# reliability-test.sh端到端可靠性测试TOPICreliability-test-$(date%s)BROKERlocalhost:9092TOTAL_MSGS100000THROUGHPUT5000echo Kafka 可靠性测试 # 1. 创建测试Topic3副本kafka-topics.sh --bootstrap-server$BROKER\--create--topic$TOPIC\--partitions3--replication-factor3\--configmin.insync.replicas2# 2. 启动消费者监听后台kafka-verifiable-consumer.sh\--bootstrap-server$BROKER\--topic$TOPIC\--group-idverify-$TOPIC\--max-messages$TOTAL_MSGS\consumer_output.jsonCONSUMER_PID$!# 3. 生产消息kafka-verifiable-producer.sh\--bootstrap-server$BROKER\--topic$TOPIC\--max-messages$TOTAL_MSGS\--throughput$THROUGHPUT\--acksall\producer_output.json# 4. 等待消费者完成wait$CONSUMER_PID# 5. 分析结果echo 生产端统计 SENT$(grepproducer_send_successproducer_output.json|wc-l)echo 成功发送:$TOTAL_MSGSecho 预期消费:$SENTecho 消费端统计 CONSUMED$(greprecord_consumedconsumer_output.json|wc-l)echo 实际消费:$CONSUMED# 6. 判断LOSS$((TOTAL_MSGS-CONSUMED))if[$LOSS-gt0];thenecho❌ 丢失了$LOSS条消息!exit1elseecho✅ 消息零丢失测试通过!fi# 7. 清理kafka-topics.sh --bootstrap-server$BROKER--delete--topic$TOPIC三、配置审计 —— 逐项排查checklist光测试还不够配置项的完整性检查同样重要【生产环境 Kafka 可靠性配置检查清单】 □ Broker 端配置 ✅ 副本数 • default.replication.factor ≥ 3 • 关键 Topic 的 replication-factor ≥ 3 ✅ ISR 保护 • min.insync.replicas ≥ 2 • 关键 Topic: min.insync.replicas 2 (RF3 时) ✅ 不稳定选举禁止 • unclean.leader.election.enable false • 绝对不能改成 true ✅ Controller 稳定性 • controller.election.rate.limit 默认 • (KRaft) controller.quorum.voters 3个或5个 ✅ 磁盘保护 • log.dirs 配置多个目录不同磁盘 • log.retention.hours ≥ 72h至少保留3天 • log.segment.bytes ≤ 1GB分段不要太大 ✅ 网络 • num.network.threads ≥ num.brokers • listeners 与 advertised.listeners 配置正确 ✅ 安全 • 生产环境开启 SASL 认证 • 生产环境开启 ACL 授权 • 生产环境开启 TLS 加密 □ Producer 端配置 ✅ acks all或相关参数幂等性自动设置 ✅ enable.idempotence true ✅ retries 设置了合理值 ✅ 有发送失败的回调处理 兜底机制 □ Consumer 端配置 ✅ enable.auto.commit false ✅ 实现了 ConsumerRebalanceListener ✅ 有关闭前 commitSync() ✅ 消费端有幂等去重机制 ✅ session.timeout.ms / max.poll.interval.ms 设置合理 □ 运维准备 ✅ 有 Prometheus Grafana 监控 ✅ 配置了关键告警规则ISR缩减/消费Lag/节点下线 ✅ 滚动重启步骤已文档化并验证 ✅ 有多机房灾备方案对关键业务四、混沌工程——主动炸系统4.1 故障注入矩阵【Kafka混沌工程故障注入矩阵】 ┌────────────────────────────────────────────────┐ │ 故障类型 │ 注入方法 │ 预期行为 │ ├────────────────────────────────────────────────┤ │ 1. 杀 Broker 进程 │ kill -9 pid │ 自动选举 │ │ │ │ 写入恢复 │ ├────────────────────────────────────────────────┤ │ 2. 网络延迟 │ tc qdisc add ... │ 吞吐下降 │ │ │ netem delay 100ms │ 不丢数据 │ ├────────────────────────────────────────────────┤ │ 3. 网络分区 │ iptables -A ... -j │ 脑裂防护 │ │ │ DROP │ 分区不可用 │ ├────────────────────────────────────────────────┤ │ 4. 磁盘满 │ dd if/dev/zero │ 拒绝写入 │ │ │ of/kafka/bigfile │ 已存数据 │ │ │ bs1M count10000 │ 不受影响 │ ├────────────────────────────────────────────────┤ │ 5. 磁盘慢 │ cgroup blkio 限制 │ 写延迟增加 │ │ │ │ 可能踢出ISR│ ├────────────────────────────────────────────────┤ │ 6. CPU 压力 │ stress --cpu 8 │ 吞吐下降 │ │ │ │ 超时增加 │ ├────────────────────────────────────────────────┤ │ 7. 内存压力 │ stress --vm 4 │ GC 增加 │ │ │ │ 页缓存被挤 │ ├────────────────────────────────────────────────┤ │ 8. ZooKeeper 挂 │ kill ZK进程 │ 集群不可用 │ │ │ (KRaft不受影响) │ 但已有数据 │ │ │ │ 不丢 │ └────────────────────────────────────────────────┘4.2 故障注入脚本#!/bin/bash# chaos-test.shKafka混沌测试BROKERlocalhost:9092TOPICchaos-testBROKER_PIDS($(psaux|grepkafka.Kafka|grep-vgrep|awk{print $2}))echo Kafka 混沌测试开始 echo目标Broker PIDs:${BROKER_PIDS[]}# 测试1杀一个Follower Brokerecho--- 测试1杀Follower ---# 先确认哪个是Followerkafka-topics.sh --bootstrap-server$BROKER--describe--topic$TOPIC# 假设Broker3是Follower杀它echo杀掉Broker3# 通过SSH在其他机器执行:# ssh broker3 kill -9 \$(ps aux | grep kafka.Kafka | grep -v grep | awk {print \$2})sleep30echo检查分区状态...kafka-topics.sh --bootstrap-server$BROKER--describe--topic$TOPICecho--- 预期ISR减少写入不受影响 ---# 测试2制造网络延迟echo--- 测试2网络延迟100ms ---# sudo tc qdisc add dev eth0 root netem delay 100mssleep60echo监控吞吐量变化...echo--- 预期吞吐下降但数据不丢 ---# 清理# sudo tc qdisc del dev eth0 root# 测试3磁盘满echo--- 测试3磁盘快满了 ---# 创建一个超大文件占磁盘# dd if/dev/zero of/kafka-data/bigfile bs1M count1000sleep30echo尝试写入...预期拒绝写入而非丢数据# 清理# rm /kafka-data/bigfileecho 混沌测试完成 4.3 测试分析【混沌测试分析表】 测试项 | 预期 | 实际 | 通过 ─────────────────┼──────────────┼──────────────┼────── 杀Follower | 写入不受影响 | 写入正常 | ✅ 杀Leader | 秒级恢复 | 8秒恢复 | ✅ 网络延迟100ms | 吞吐下降50% | 吞吐下降48% | ✅ 磁盘满 | 拒绝写入 | 拒绝写入 | ✅ 断电(硬杀) | 数据不丢 | 丢失0条 | ✅ 连杀2个Broker | 写入拒绝 | 写入拒绝 | ✅ 恢复2个Broker | ISR恢复 | 30秒后恢复 | ✅ 测试结论系统可靠性能达到99.99%数据持久性五、可靠性SLA量化5.1 关键指标【Kafka 可靠性 SLA 指标】 1. 数据持久性Durability ┌────────────────────────────────────────────┐ │ 公式已成功确认消息数 / (已成功确认丢失) │ │ │ │ 目标99.999% (五个9) │ │ 意味着一天写入1亿条最多丢1000条 │ └────────────────────────────────────────────┘ 2. 写入可用性Availability - Write ┌────────────────────────────────────────────┐ │ 公式写入成功时间 / 总时间 │ │ │ │ 目标99.95% │ │ 意味着每月停机不超过21分钟 │ └────────────────────────────────────────────┘ 3. 故障恢复时间MTTR - Mean Time To Recover ┌────────────────────────────────────────────┐ │ 关键指标 │ │ • Leader 选举时间 10秒 │ │ • ISR 恢复时间 5分钟100GB数据量 │ │ • 全量副本同步时间 30分钟 │ └────────────────────────────────────────────┘5.2 监控指标# Prometheus 关键告警规则groups:-name:kafka_reliabilityrules:# 告警1ISR 缩减-alert:KafkaUnderReplicatedPartitionsexpr:kafka_server_replicamanager_underreplicatedpartitions0for:1mlabels:severity:criticalannotations:summary:存在 Under-Replicated 分区description:当前 {{ $value }} 个分区的副本不足数据可靠性降低# 告警2离线分区-alert:KafkaOfflinePartitionsexpr:kafka_controller_kafkacontroller_offlinepartitionscount0for:30slabels:severity:criticalannotations:summary:存在离线分区description:{{ $value }} 个分区处于离线状态数据不可读写# 告警3活跃 Controller 数-alert:KafkaNoActiveControllerexpr:kafka_controller_kafkacontroller_activecontrollercount 0for:1mlabels:severity:criticalannotations:summary:没有活跃的 Controllerdescription:集群没有ControllerLeader选举无法进行# 告警4ISR 扩展速率-alert:KafkaISRShrinkRateexpr:rate(kafka_server_replicamanager_isrshrinks_total[5m])0.1for:5mlabels:severity:warningannotations:summary:ISR 频繁缩减description:ISR 缩减速率: {{ $value }}/秒可能存在网络问题本篇小结可靠性的验证不是一次性的而是一个持续的过程工具测试用VerifiableProducer/Consumer做确定性测试精确衡量丢失率和重复率配置审计逐项检查Broker/Producer/Consumer的配置是否满足可靠性要求混沌工程主动注入故障验证系统在异常下的行为是否符合预期SLA量化用数字衡量可靠性——持久性99.999%、可用性99.95%、故障恢复10秒记住生产环境的可靠性不能用我觉得没问题来衡量必须用测试数据说话。下一篇我们换个角度——从请求处理的底层机制来看一条Produce请求从到达到响应在Broker内部经历了什么。上一篇【第65篇】Kafka故障转移实战——Broker宕机了怎么办下一篇【第67篇】Kafka请求处理机制深度解析——生产请求与获取请求的完整链路
)
