数据库运维云原生高可用监控【免费下载链接】pigstyEnterprise-Grade OSS PostgreSQL Distribution with HA, PITR, IaC, Monitor, 12 kernel forks and 575 PG extensions. Best-of-breed products integrated as a platform. Self-host Postgres like a Pro!项目地址https://gitcode.com/GitHub_Trending/pi/pigsty点击查看免费下载Pigsty 将 KafkaKRaft 模式4.x的监控建模为一套围绕运维对象而非 Exporter 进程划分的 Grafana 面板体系Overview、Instance、Topic、Consumer 四张面板分别回答集群是否健康、单实例 JVM/请求路径是否饱和、哪个分区过热、哪个消费组在掉队四类问题。本文以 files/grafana/kafka/README.md 为主线结合仓库中的 JMX 指标白名单、VictoriaMetrics 记录/告警规则与 Ansible 部署任务完整讲解这套监控模型的分层设计、指标契约、告警语义与面板约定使读者既能直接上手使用也能理解其为什么这样拆的底层原理。监控模型总览按运维对象而非 Exporter 进程划分Pigsty 用四张仪表盘覆盖 Kafka 的完整运维视图拆分依据是Kafka 的运维对象cluster / instance / topic / consumer group而不是采集进程的数量——这一原则决定了后续所有指标契约与面板结构面板主变量职责Kafka Overviewcls单个 KRaft 集群身份、成员清单、可靠性、负载、告警、活动、Exporter 与日志Kafka Instanceins单个 broker/controller 的 JVM 及其请求路径、KRaft 状态并通过ip关联宿主机资源Kafka Topiccls,topicTopic 与分区拓扑、offset、ISR 健康、写入速率及关联的消费组Kafka Consumercls,group消费组成员、已提交 offset、延迟与进度不做无效的跨 topic offset 运算四张面板在jobkafka下的同一指标空间中工作变量体系cls、ins、topic、group相互打通形成从集群 → 实例 → 主题 → 消费组的逐层下钻链路。值得注意的是Kafka Node 面板被刻意退役。原文档明确指出它重复了现由 Kafka Instance 面板负责的 JVM 与操作系统两个区块通用的主机排查由 Pigsty 既有的Node Instance面板继续承担见 files/grafana/node/node-instance.json。也就是说主机层问题统一收敛到 Node 体系Kafka 面板只保留 Kafka 专属语义避免同一指标在两个面板重复展示、口径漂移。Metric Contractjobkafka下的两类抓取角色这是整个监控模型的基石。Pigsty 在 VictoriaMetrics 的同一jobkafka下同时抓取两类角色它们标签不同、语义不同、权威性不同1. JMX 目标有role标签role取值为broker、controller或combined对应真实 Kafka 进程携带cls、ins、ip、node_id、role五个身份标签其中node_id即 KRaft 的节点 IDkafka_seq这类目标是实例清单instance inventory的权威来源——集群里有哪些进程、各自扮演什么角色完全由它决定。2. kafka_exporter 目标无role标签单个 kafka_exporter 以协议方式查询整个集群暴露 broker、topic、partition、consumer-group 层面的协议状态两个 Exporter 可能上报完全相同的逻辑序列因此业务查询必须先max without (ins, ip, instance)去掉抓取身份再对逻辑对象求和。以实际部署代码为证在 roles/kafka/tasks/monitor.yml 中VictoriaMetrics 的抓取目标文件按实例写入/infra/targets/kafka/{{ kafka_instance }}.ymlJMX 目标携带完整身份标签- labels: { ip: {{ inventory_hostname }} , ins: {{ kafka_instance }} , cls: {{ kafka_cluster }} , role: {{ kafka_role }} , node_id: {{ kafka_seq }} , instance: {{ inventory_hostname }}:{{ kafka_jmx_exporter_port }} } targets: [ {{ inventory_hostname }}:{{ kafka_jmx_exporter_port }} ]而 Exporter 目标只在前两个 broker 节点上追加{% if inventory_hostname in kafka_exporter_hosts_internal %}且刻意不带role标签——这就是两条抓取路径在标签契约上的分界。kafka_exporter_hosts_internal的推导见 roles/kafka/tasks/identity.yml取kafka_broker_nodes中kafka_seq最小的两个节点默认双副本冗余部署任一台挂掉查询面仍然完整。JMX 白名单以可预测的基数换取语义边界JMX 采集由 jmx_exporter 的allow-list控制维护在 roles/kafka/templates/jmx_exporter.yml.j2。该文件明确注释这是刻意的白名单deliberately an allow-list只导出 JVM 基线 有界的 broker、请求、复制与 KRaft controller 指标刻意排除 per-client 与 per-partition 的 MBean——协议级细节交给 kafka_exporter排除它们是为了把基数cardinality限制在可预测范围内。白名单按 MBean 域组织为五个对象域includeObjectNames: - java.lang:* - kafka.server:* - kafka.controller:* - kafka.network:* - kafka.log:*并在rules中映射为结构化指标可归纳为四组Broker 流量仅集群总量kafka_server_broker_messages_in_total、bytes_in/out_total、复制进出字节、produce/fetch 请求及失败计数复制与 broker 健康under_replicated_partitions、under_min_isr_partitions、at_min_isr_partitions、offline_replicas、分区/leader 计数、ISR 收缩/扩张/失败更新、重分配分区、delayed_operation_purgatory_size请求路径与饱和按 API/version 拆分的kafka_network_request_total与kafka_network_request_errors_total、TotalTimeMs 的 50/95/99 分位、请求/响应队列长度、request_handler_idle_ratio、network_processor_idle_ratio、offline_log_directoriesKRaft 与 controllerraft_state/current_leader/current_epoch/high_watermark/log_end_offset、metadata apply lag/error、快照大小与年龄controller 侧则有active_controller_count、fenced_broker_count、offline_partition_count、preferred_replica_imbalance_count、elections_total、unclean_leader_elections_total、事件队列时间分位等。七类运维问题与权威指标对照README 给出了一张运维问题 → 权威指标 → 呈现位置的对照表是排查 Kafka 时的索引地图运维问题权威指标呈现位置 / 规则集群是否可写且已复制controller offline partitions、active controller、under-min-ISR、under-replicated partitionsOverview 可靠性、Instance 复制、critical/warning 告警KRaft 是否健康raft state/epoch/HW/LEO、controller 选举、metadata apply lag/errorsInstance KRaft 区块请求容量在哪里耗尽request handler/network processor idle ratio、队列、API 延迟/错误Instance 请求区块与饱和告警哪个 topic/partition 不健康或过热leader、preferred leader、replicas、ISR、offset 及 offset 速率Topic 分区拓扑与写入速率消费组是否在掉队group members、已提交 offset、partition lag、commit rateConsumer 延迟/进度与持续增长告警存储或宿主机是否饱和offline log directories Node CPU/内存/文件系统/磁盘延迟/利用率/网络Instance Node 区块通用 Node 告警仍为权威采集链路本身是否故障up、jmx_scrape_error、抓取时长/样本数、Exporter 运行时轻量 Exporter 区块注意最后一行的语义采集是否正常本身就是一类一等公民的运维问题面板因此为 Exporter 保留了专门的轻量区块与业务指标分离展示。Recording 与 Alert 规则files/victoria/rules/kafka.yml所有稳定的、可复用的速率与延迟聚合被预计算为记录规则recording rules集中定义在 files/victoria/rules/kafka.yml由 VictoriaMetrics 按kafka-rules、kafka-jmx-rules、kafka-alert三个规则组加载。记录规则Topic / 消费组 / 集群三级的速率与延迟消息速率先按 topic 聚合再向上汇总到集群- record: kafka:topic:msg_rate1m expr: sum by (job, cls, topic) (max without (ins, ip, instance) (clamp_min(rate(kafka_topic_partition_current_offset[1m]), 0))) - record: kafka:topic:msg_rate5m expr: ... # 同上窗口改为 5m - record: kafka:cls:msg_rate1m expr: sum without (topic) (kafka:topic:msg_rate1m) - record: kafka:cls:msg_rate5m expr: sum without (topic) (kafka:topic:msg_rate5m)消费延迟保留consumergroup与topic两个维度partition 是唯一被求和掉的维度并逐级汇总- record: kafka:csg_topic:commit_rate5m # 消费组×topic 的提交速率 - record: kafka:csg_topic:lag # 消费组×topic 的延迟面板的单一事实来源 - record: kafka:csg:lag # sum without (topic) - record: kafka:cls:lag # sum without (consumergroup)README 特别强调了一条求和的铁律offset 在保留topic之前绝不跨 topic 求和。原因在于offset 是某个分区内的位置position不是全局可加的字节数或时间度量把两个不同 topic 的 offset 相加在语义上是无效运算。规则文件里的注释也复述了这一点Partition is the only dimension summed; this prevents invalid cross-topic offsets.JMX 记录规则kafka-jmx-rules组把一组高价值的 JVM/请求/复制指标固化为稳定序列kafka:ins:jvm_heap_used_ratioheap 已用/上限比值、kafka:ins:jvm_cpu_cores、kafka:ins:jvm_gc_time_rate5mkafka:ins:load1 - clamp(min(request_handler_idle_ratio or network_processor_idle_ratio), 0, 1)——即最忙请求路径线程池的饱和率与饱和告警评估的是同一个序列kafka:cls:load为avg by (job, cls)kafka:ins:messages_in_rate5m、bytes_in/out_rate5m、kafka:ins:request_error_rate5m按request、error维度求和排除errorNONEkafka:cls:under_replicated_partitions、kafka:cls:offline_partitions后者用max by (cls)因 controller 计数是全局视角。消费延迟告警必须量大且持续增长KafkaConsumerLagGrowing是这套规则中最值得解读的一条expr: kafka:csg:lag 100000 and on (job, cls, consumergroup) delta(kafka:csg:lag[30m]) 0 for: 30m它同时要求两个条件存在实质积压延迟 10 万条且在 30 分钟窗口内持续增长delta 0并持续 30 分钟才告警。这样的设计避免了消费组正在高速追平一个巨大历史积压时误报——量大但正在被排空的重放场景不会触发告警只有既大又涨才是真正需要人工介入的掉队。更关键的是面板与告警共享同一条序列README 明确指出所有头部的延迟数字Overview、Topic、Consumer 的Total Lag统计与 lag-by-group 面板都直接消费kafka:csg_topic:lag因此运维在面板上看到的数字与告警规则评估的是同一条时间序列不存在面板一个数、告警另一个数的口径分裂。而kafka_consumergroup_lag_sum/kafka_consumergroup_current_offset_sum这两个 Exporter 家族指标被明确弃用——它们在 kafka_exporter 内部独立计算可能与同一次抓取中的逐分区序列不一致。Topic 页的 Worst-partition lag 则用max by (partition)跨所有消费组取最大若在此处保留consumergroup维度会在 join 时产生重复键导致表格中的消费组被静默丢弃。Kafka 专用告警清单kafka-alert规则组覆盖了进程/Exporter 可用性、抓取失败、JVM 死锁/堆、请求与网络饱和、复制/ISR 故障、离线日志目录/分区、controller 基数、fenced broker、不洁 leader 选举与消费延迟全部归类为category: kafka便于在共享的告警面板中按类过滤告警触发条件级别KafkaDownup{jobkafka,role~.} 11mCRITKafkaExporterDownup{jobkafka,role} 11mCRITKafkaJmxScrapeErrorjmx_scrape_error 03mWARNKafkaJvmHeapHighheap 使用率 90%15mWARNKafkaJvmDeadlockjvm_threads_deadlocked 01mCRITKafkaRequestHandlerSaturatedrequest handler idle 10%10mWARNKafkaUnderReplicatedPartitionsunder-replicated 05mWARNKafkaUnderMinISRunder-min-ISR 01mCRITKafkaOfflineLogDirectoryoffline log directories 01mCRITKafkaOfflinePartitionscontroller offline partitions 01mCRITKafkaControllerCountMismatchactive controller 计数 ≠ 11mCRITKafkaFencedBrokersfenced broker 计数 05mWARNKafkaUncleanLeaderElection5m 内不洁选举 0CRITKafkaNetworkProcessorSaturatednetwork processor idle 10%10mWARNKafkaConsumerLagGrowinglag 100k 且 30m 持续增长30mWARN其中KafkaControllerCountMismatch表达了 KRaft 的强一致约束健康集群必须且只能有一个 active controller表达式用or 0 * count兜底避免某个集群完全没有 controller 指标时产生 NaN 而漏报。刻意保留、暂不被面板消费的聚合README 坦诚地列出几个记录聚合——kafka:cls:msg_rate*、kafka:cls:lag、kafka:ins:jvm_gc_time_rate5m、kafka:ins:request_error_rate5m、kafka:cls:under_replicated_partitions、kafka:cls:offline_partitions——目前不被任何面板消费。它们被刻意保留作为告警、容量脚本与 API 消费方稳定可用的查询点而需要自适应$__rate_interval窗口的面板则在面板内联计算同样的表达式。这是记录规则服务于稳定契约、面板服务于交互体验的清晰分工。另一个边界是主机容量告警不做重复实现宿主机的 CPU/内存/磁盘/网络告警已由 Pigsty 的 Node 规则files/victoria/rules/node.yml评估Kafka 面板通过共享的category/cls告警面板直接透出避免同一问题被两套规则同时告警。Dashboard 面板约定设计与实现的一致性契约四张面板遵循一套显式声明的统一约定见 README 的 Dashboard conventions色彩语义Kafka 品牌青绿色#4bb39ce0用于健康/身份色warning/critical 状态沿用 Pigsty 的琥珀/红色约定保证跨面板的告警色一致区块顺序Overview 永远第一Exporter 区块刻意放在倒数第二先看业务再看采集Logs 永远最后变量规则Topic 与 Consumer 页单选集群topic仅在有意义的跨 topic 消费组分析场景才允许多选导航所有页面通过KAFKA下拉导航保留时间范围与变量对应每个 JSON 顶部的title: KAFKA导航栏数据源面板只使用预置的ds-prometheus与ds-vlogs数据源 UID任何面板都不内嵌环境相关的数据源 ID 或凭据——从 kafka-overview.json 等文件中的uid: ds-prometheus引用可以验证这一点这也让面板可以在任意 Pigsty 环境原样导入。Grafana 13 的 join 契约身份/清单/分区拓扑等**连接表joined tables**遵循 Grafana 13 的 join 契约README 给出了完整规范每条 instant 查询都使用format: tablejoin 字段本身就是有意义的标签cls、ins、topic、consumergroup、partition或经label_join生成的key只有 join 字段保留原名——任何跨 frame 冲突的列名会被后缀1、2……因此organize的排除项必须指向带后缀的列名绝不能隐藏 join 字段否则表格会失去行身份row identity出现行列错位。这解释了为什么实例清单、消费组身份等表格在 Grafana 中能稳定合并多路 PromQL 结果join 键是语义标签而非匿名列是表不丢行的前提。兼容性与已知边界克制的不确定性README 用专门一节交代这套模型的适用范围与诚实的能力边界指标面面板只使用已入库的 Kafka 4.x JMX 白名单或 kafka_exporter 协议契约中的指标。controller-only 面板在纯 broker 进程上合法地没有数据MBean 不存在这不是采集故障消费面板在至少一个消费组提交 offset 之前不显示数据——这是数据尚未产生不是 Exporter 失败topic 字节数Kafka 通过当前有界契约不暴露可移植的逐 topic 字节数指标因此 Topic 页用保留 offset 跨度retained offset span作为记录体量指标且明确不将其标注为字节避免伪精确文件系统容量只展示在实例/节点层级因为把任意的log.dirs路径安全地映射到 Node Exporter 的挂载点无法从当前标签可靠推导——宁可不展示也不做不可靠的猜测映射。这些边界共同体现了一个原则监控模型对不知道保持显式而不是用推断值填充。从部署到面板监控目标与 Exporter 的生成链路要真正理解四张面板的数据从哪来需要把 Ansible 侧的两条链路串起来详见 roles/kafka/tasks/monitor.ymlJMX 链路每个 Kafka 实例通过 kafka.env.j2 注入KAFKA_JMX_OPTSjmx_exporter 监听kafka_jmx_exporter_port默认9404见 roles/kafka/defaults/main.yml白名单即前文所述 allow-list协议链路kafka_exporter 的环境由 kafka_exporter.env.j2 渲染参数完整可读KAFKA_EXPORTER_OPTS--kafka.servernode1:9092 --kafka.servernode2:9092 ... --kafka.version4.0.0 --web.listen-address:9308[--sasl.enabled --sasl.username... --sasl.password... --sasl.mechanismscram-sha512 --tls.enabled --tls.ca-file/etc/pki/ca.crt]即逐个注入全部 broker 端点--kafka.server默认端口 9092、显式声明协议版本--kafka.version4.0.0、监听kafka_exporter_port默认9308在kafka_security: scram模式下追加 SASLscram-sha512与 TLS信任系统级 Pigsty CA/etc/pki/ca.crt参数。注意安全模式下monitor.yml对模板渲染启用了no_log凭据不会泄露进 Ansible 日志。目标注册如上文所述monitor.yml在groups[infra]的每台机器上写入实例级 target 文件JMX 目标恒定存在Exporter 目标仅追加到前两个 broker 节点——正是 Metric Contract 中两类角色、两套标签的落地位置。至此闭环完成KRaft 拓扑identity.yml 中的 controller/broker 节点推导→ 实例清单与角色标签 → JMX 协议双路采集 → VictoriaMetrics 记录规则 → 四张 Grafana 面板与告警。从集群视角的 Overview 逐层下钻到实例 JVM、请求路径、KRaft 状态再到 topic 拓扑与消费组延迟每一层都有明确的数据来源、权威指标与告警语义而 Exporter 区块与 Node 面板则分别兜住采集链路故障与宿主机饱和两类横向问题。这套以运维对象为核心、以 metric contract 为边界的建模方式正是 Pigsty Kafka 监控既完整又不越界的关键所在。赞分享数据库运维云原生高可用监控【免费下载链接】pigstyEnterprise-Grade OSS PostgreSQL Distribution with HA, PITR, IaC, Monitor, 12 kernel forks and 575 PG extensions. Best-of-breed products integrated as a platform. Self-host Postgres like a Pro!项目地址https://gitcode.com/GitHub_Trending/pi/pigsty点击查看免费下载相关推荐Parse Server 监控仪表盘搭建Grafana 面板设计与告警Parse Server 监控仪表盘搭建Grafana 面板设计与告警 你是否还在为 Parse Server 的运行状态监控而烦恼当用户量突增导致 API后端认证鉴权StarRocks 告警体系全解PromSQL 监控规则、告警处置与集群恢复实践StarRocks 告警体系全解PromSQL 监控规则、告警处置与集群恢复实践 本指南基于 StarRocks 官方运维文档系统讲解 StarRocks数据库OLAP数据仓库大数据湖仓一体数据分析Kafka-Docker监控告警体系Prometheus与Grafana集成终极指南Kafka Docker监控告警体系Prometheus与Grafana集成终极指南 在当今的微服务架构中Apache Kafka作为分布式流处理平台的核心消息队列后端云原生上一篇Julia HTTP编程最佳实践基于HTTP.jl的代码规范与模式下一篇obsidian-copilot 版本演进全览从 AI 聊天插件到原生多 Agent 平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考