2. Confluent Kafka平台架构与可观测性触点

Confluent Kafka 平台并不是一个单一进程，而是由多个职责不同的组件协同构成的分布式数据平台。要建立可观测性，第一步不是急着采集指标，而是先弄清楚每个组件在数据链路中扮演什么角色、暴露哪些可观测性数据源、以及哪些指标真正反映它的健康状态。本节围绕 Broker、Controller、Connect、Schema Registry、ksqlDB、REST Proxy 六类核心组件展开，梳理它们的可观测性触点。

Broker：数据平面的核心观测对象

Broker 是 Kafka 集群的数据平面主体，负责分区副本的存储、读写与复制。它的可观测性数据源主要有三类：一是 JMX 指标，通过 JMX 端口暴露，是 Broker 最丰富的指标来源；二是 Broker 自身的日志，包括副本同步、Leader 选举、请求处理异常等；三是客户端侧指标，从生产者、消费者视角反向反映 Broker 的服务质量。

Broker 的关键指标可分为四组。吞吐与请求类：BytesInPerSec、BytesOutPerSec、MessagesInPerSec、RequestsPerSec，反映集群负载。延迟类：RequestQueueTimeMs、LocalTimeMs、RemoteTimeMs、ResponseQueueTimeMs、ResponseSendTimeMs，这五个延迟分段能精确定位请求在 Broker 内部哪一段变慢。副本与 ISR 类：UnderReplicatedPartitions、IsrShrinksPerSec、IsrExpandsPerSec、OfflinePartitionsCount，直接反映数据可靠性风险。资源类：JVM 堆使用、GC 暂停时间、文件句柄数、网络连接数。

其中 UnderReplicatedPartitions 是最值得优先告警的指标。它大于 0 意味着某些分区的副本数低于期望值，一旦此时 Leader 宕机就可能丢数据。示例判断逻辑：若该值持续 5 分钟大于 0，且 IsrShrinksPerSec 同步上升，说明有 Broker 落后或网络分区，应优先排查慢副本所在节点。

Controller：集群元数据与选举的观测点

在 KRaft 模式下，Controller 独立于 Broker 承担元数据管理、分区 Leader 选举、集群成员变更等职责。它的可观测性触点包括：Controller 的 JMX 指标、元数据日志（metadata log）的提交延迟、以及 Active Controller 的切换事件。

关键指标有 KafkaController_ActiveControllerCount（整个集群应恒为 1，大于 1 说明脑裂风险）、EventQueueTimeMs、ControllerEventManager 相关队列长度、以及元数据日志的 MetadataLogEndOffset 与 MetadataLogLag。Controller 的观测重点不是吞吐，而是元数据操作的及时性与一致性。若 EventQueueTimeMs 持续升高，说明 Controller 处理事件积压，分区 Leader 切换会变慢，进而影响客户端可用性。

Connect：数据集成链路的观测

Connect 负责在 Kafka 与外部系统之间搬运数据，分为 Source（外部→Kafka）和 Sink（Kafka→外部）两类连接器。它的可观测性数据源包括：Connect Worker 的 JMX 指标、每个 Connector 与 Task 的状态接口（REST API /connectors/{name}/status）、以及 Connect 日志。

关键指标按层级划分。Worker 级：worker-connector-count、worker-task-count、worker-connector-startup-success-total。Connector 级：connector-status（RUNNING/PAUSED/FAILED）、connector-total-task-count。Task 级：task-status、source-record-poll-total、source-record-write-total、sink-record-read-total、sink-record-send-total。此外还有 offset-commit-success-percentage 与 offset-commit-failure-percentage，反映偏移量提交健康度。

Connect 观测的核心是“状态 + 进度”。一个 Connector 显示 RUNNING 并不代表健康，还要看 Task 是否在推进、offset commit 是否成功。示例：若某 Sink Connector 的 sink-record-read-total 持续增长但 sink-record-send-total 停滞，说明数据已从 Kafka 读出但写外部系统失败，应检查下游系统可用性与重试配置。

Schema Registry：Schema 演进的观测

Schema Registry 管理 Avro、Protobuf、JSON Schema 的版本与兼容性。它的可观测性数据源主要是 REST API 与 JMX 指标。关键指标包括：schema-registry-request-count、schema-registry-request-latency、schema-registry-schema-count、以及注册/查询请求的成功与失败计数。

Schema Registry 的观测重点是请求延迟与兼容性拒绝。当生产者注册新 Schema 被拒绝时，会返回 409 冲突，这通常意味着 Schema 演进违反了兼容性策略。可观测性上应关注注册失败率与 _schemas 内部主题的写入延迟，因为 Schema Registry 本身依赖 Kafka 存储 Schema。

ksqlDB：流处理的观测

ksqlDB 提供基于 SQL 的流处理能力。它的可观测性数据源包括 ksqlDB Server 的 JMX 指标、REST API /healthcheck 与 /info、以及查询相关的指标。关键指标有：ksql_query_status、ksql_streaming_query_error、ksql_query_latency、以及持久查询的消费延迟。

ksqlDB 的观测重点是查询状态与处理延迟。持久查询（Persistent Query）一旦进入 ERROR 状态，会停止处理数据，必须通过 SHOW QUERIES 或 REST API 及时发现。此外，ksqlDB 内部使用 Kafka 主题存储状态，因此其消费延迟指标与 Broker 的消费组延迟密切相关。

REST Proxy：对外接口的观测

REST Proxy 为不支持原生 Kafka 协议的客户端提供 HTTP 接口。它的可观测性数据源主要是 JMX 指标与访问日志。关键指标包括：jetty-request-count、request-latency、response-code 分布、以及各 REST 端点的调用量。

REST Proxy 的观测重点是请求延迟与错误码分布。由于它是无状态代理，其健康度直接反映后端 Broker 的可用性。若 response-code 中 5xx 比例上升，应同时检查 Broker 的请求延迟与网络连通性。

组件观测的优先级与联动关系

六类组件的观测并非孤立。Broker 的 UnderReplicatedPartitions 上升，可能源于 Controller 元数据操作积压；Connect 的 offset commit 失败，可能源于 Broker 请求延迟升高；Schema Registry 的注册失败，可能源于 _schemas 主题所在 Broker 的写入延迟。因此，可观测性工程需要建立跨组件的关联视图，而不是各自为政地看单点指标。

一个实用的排查顺序是：先看 Broker 的副本与延迟指标，确认数据平面是否健康；再看 Controller 的 ActiveControllerCount 与事件队列，确认元数据平面是否稳定；然后看 Connect、Schema Registry、ksqlDB 的状态与延迟，确认上层服务是否受影响；最后看 REST Proxy 的错误码分布，确认对外接口是否正常。这个顺序符合“从底层到上层”的依赖关系，能快速缩小故障范围。