3. Kafka成本可观测性体系搭建
成本治理的第一道门槛不是“省钱”，而是“看见钱花在哪里”。Kafka 的成本不像一台虚拟机那样直观：一个 3 节点集群可能承载 200 个 Topic、上千个 Consumer Group，真正消耗资源的往往只是其中少数几个高吞吐 Topic 或某个反复 Rebalance 的消费组。因此，本章要搭建的是一套从指标采集到成本归因、再到看板呈现的可观测性链路，让“哪个团队、哪个 Topic、哪类操作在消耗多少资源”变成可查询、可告警、可追溯的数据。
一、先明确成本可观测性的数据分层
Kafka 的成本可观测性不是单一指标，而是三层数据的叠加：
- 资源层：Broker 的 CPU、网络入/出带宽、磁盘写入与占用、JVM GC 时间。这些决定集群的物理成本基线。
- 流量层：Topic 级别的字节入/出速率、消息速率、分区数、副本数。这是成本归因的核心，因为网络与存储成本几乎正比于流量。
- 行为层：Consumer Group 的 Lag、Rebalance 次数、请求延迟。异常行为会放大资源消耗，例如频繁 Rebalance 导致重复消费与额外网络开销。
三层数据分别来自不同采集通道：Confluent Metrics API 提供托管集群的 Topic 级与 Broker 级指标；Cloud Monitoring 提供底层 VM/磁盘/网络指标；Prometheus 负责抓取自建集群的 JMX Exporter 指标并做长期存储；Grafana 则把三者统一到同一时间轴与同一看板上。下图展示了这条采集与归因链路的结构关系。
二、Confluent Metrics API 的采集要点
Confluent Cloud 的 Metrics API 基于 Prometheus 兼容的查询接口，返回的是时间序列数据。采集时最容易踩的坑是指标基数爆炸：如果对每个 Topic 都拉取全部指标，一个 500 Topic 的集群会产生数十万条时间序列，Prometheus 内存和 Grafana 查询都会变慢。因此实际做法是：
- 只采集成本相关的核心指标：
confluent_kafka_server_received_bytes、confluent_kafka_server_sent_bytes、confluent_kafka_server_retained_bytes、confluent_kafka_server_partition_count。 - 用 Recording Rules 预聚合为 5 分钟速率，降低查询时的计算量。
- 通过
metric_relabel_configs只保留带有team标签的 Topic，丢弃系统内部 Topic（如__consumer_offsets）。
下面是一段可直接参考的 Prometheus 抓取配置片段，用于从 Confluent Metrics API 拉取数据并注入团队标签：
scrape_configs:
- job_name: confluent_metrics
scrape_interval: 30s
metrics_path: /v2/metrics/cloud/export
scheme: https
bearer_token: ${CONFLUENT_API_TOKEN}
static_configs:
- targets: ["api.telemetry.confluent.cloud"]
metric_relabel_configs:
- source_labels: [__name__]
regex: "confluent_kafka_server_(received_bytes|sent_bytes|retained_bytes|partition_count)"
action: keep
- source_labels: [topic]
regex: "__consumer_offsets|_schemas"
action: drop
- source_labels: [topic]
target_label: team
regex: "order-.*"
replacement: "交易团队"
这段配置的关键在于最后一条 relabel：它把 Topic 名称前缀映射为团队标签。实际生产中，更稳妥的方式是维护一张 Topic 到团队的映射表，由 CI 流水线在创建 Topic 时自动写入标签，而不是靠正则硬编码。
三、Cloud Monitoring 补齐底层资源成本
Metrics API 只覆盖 Kafka 逻辑层，磁盘和网络的实际账单来自底层资源。Cloud Monitoring 提供 compute.googleapis.com/instance/disk/read_bytes_count、compute.googleapis.com/instance/network/sent_bytes_count 等指标。把这两层数据对齐到同一时间轴后，就能回答一个关键问题：某个 Topic 的流量增长，是否真的带来了底层网络成本的同步增长？如果流量涨了但底层网络没涨，说明数据可能被压缩或走了内网；如果底层网络涨得比流量快，则可能存在副本同步放大或跨区传输。
四、Grafana 看板的四个核心面板
看板不需要堆满图表，四个面板即可支撑日常成本治理：
| 面板 | 核心查询 | 判断依据 |
|---|---|---|
| 集群成本总览 | sum by (cluster) (topic:bytes_out:rate5m) * 单价 | 日环比涨幅超过 20% 触发关注 |
| Topic 成本排行 | topk(10, sum by (topic) (topic:bytes_out:rate5m)) | 前 10 Topic 占比超过 70% 说明集中度高 |
| 团队分摊 | sum by (team) (topic:bytes_out:rate5m) * 单价 | 与预算对比，超支团队进入治理清单 |
| 异常消费组 | sum by (group) (kafka_consumergroup_lag) > 阈值 | Lag 持续增长且 Rebalance 频繁，需排查 |
其中“Topic 成本排行”是最有行动价值的面板。假设示例数据中，order-events 的 5 分钟出流量速率为 120 MB/s，按网络单价 0.08 元/GB 估算，月成本约为 120 × 1024 × 86400 × 30 / 1024³ × 0.08 ≈ 24.3 万元。这个数字一旦被看见，团队自然会去评估：是否可以通过压缩、降低保留时间或合并小消息来优化。
五、从看板到告警的闭环
看板解决“看见”，告警解决“及时反应”。建议设置三类告警：单 Topic 日成本超过预算 150%、团队月度累计成本达到预算 80%、Consumer Group Lag 连续 15 分钟超过 100 万。告警触发后，附上对应 Topic 的 Grafana 面板链接和最近 24 小时流量曲线，让接收者无需二次查询即可判断是业务增长还是异常。
至此，采集、归因、展示、告警四段链路已经打通。这套体系的价值不在于图表本身，而在于它把“Kafka 花了多少钱”从财务月底的一张账单，变成了每个团队每天都能看到的实时数据，为后续的配额管理、Topic 治理和架构优化提供了可量化的依据。