Strimzi Kafka Operator MetricsST 系统测试套件验证 Operator 与被控组件的 Prometheus 指标暴露【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operatorMetricsST 是 Strimzi 系统测试systemtest框架中专门用于验证“Operator 与被控组件operands暴露的 Prometheus 指标”的测试套件源码位于 MetricsST.java。它在真实 Kubernetes 集群上部署 Cluster Operator、User Operator 以及多个带指标配置的 Kafka 集群通过 scraper Pod 抓取/metrics端点并断言关键指标如strimzi_reconciliations_*、kafka_server_*、kafka_broker_info等的存在性与取值。读完本文你将理解 Strimzi 各组件的指标暴露链路JMX Prometheus Exporter、Kafka Exporter、strimzi-metrics-reporter、该套件的完整前置/后置流程、8 个测试用例的验证点以及如何对照仓库内示例 YAML 在自己的环境中完成同类验证。测试套件定位与标签体系MetricsST 类上标注了SANITY、REGRESSION、METRICS、CRUISE_CONTROL四个 JUnit Tag说明它既是回归基线的一部分也可按标签筛选执行。套件级文档由SuiteDoc注解描述MetricsST.java仓库中 labels/metrics.md 给出了该标签的官方说明这些测试确保 Strimzi 组件包括 Kafka、Kafka Connect、Kafka Bridge、Kafka MirrorMaker2 与 Cluster Operator暴露的所有指标符合预期的行为与格式它们验证数据正确性、确认指标在各种配置下均能暴露并保证与外部监控系统的集成。该标签下与 MetricsST 直接关联的测试共 10 个本套件全部用例此外还关联了 StrimziMetricsReporterST、JmxST、MultipleClusterOperatorsST 等套件中的用例。每个用例的TestDoc注解同时携带KAFKAMETRICS标签并按组件附加CONNECT、BRIDGE、MIRROR_MAKER2、CRUISE_CONTROL等标签用于 CI 中按功能域分批运行。测试环境与前置准备Before steps文档定义的 8 步前置操作对应源码setupEnvironment()MetricsST.java具体如下| Step | 文档描述 | 源码实现细节 | | - | - | - | | 1 | 创建命名空间 {namespaceFirst} 与 {namespaceSecond} | 固定为metrics-test-0与metrics-test-1由NamespaceUtils.createNamespacesAndPrepare创建 | | 2 | 部署 Cluster Operator |SetupClusterOperator.getInstance().withDefaultConfiguration().install()以默认配置安装 | | 3 | 部署带指标与 CruiseControl 的 Kafka {kafkaClusterFirstName} | 集群metrics-cluster-0通过 KafkaNodePool 创建 3 个 broker 节点池 3 个 controller 节点池KRaft 分离模式并启用 Entity OperatorTopic/User Operator 的 reconciliation interval 均设为 30000ms指标配置由KafkaTemplates.kafkaMetricsConfigMap与cruiseControlMetricsConfigMap提供 | | 4 | 部署带指标的 Kafka {kafkaClusterSecondName} | 集群metrics-cluster-11 broker 1 controller 的 NodePool仅配置指标 | | 5 | 在两个命名空间部署 scraper Pod | 共 4 个 scraper PodCO_NAMESPACE、TEST_SUITE_NAMESPACE及两个测试命名空间各一个用于抓取 Strimzi Pod 的指标 | | 6 | 创建 KafkaUser 与 KafkaTopic | 2 个 TLS 用户3 个 topic其中topicName、kafkaExporterTopicName为 7 分区/2 副本bridgeTopicName为默认规格 | | 7 | 配置 NetworkPolicy 放行 Operator Pod 与 KafkaExporter 访问 |NetworkPolicyUtils.allowNetworkPolicySettingsForClusterOperator(CO_NAMESPACE)| | 8 | 创建 Cluster Operator、Kafka、KafkaExporter 的 collector 并收集指标 | 构建 3 个BaseMetricsCollectorkafkaCollector、kafkaExporterCollector、clusterOperatorCollector调用collectMetricsFromPods(METRICS_COLLECT_TIMEOUT)完成首轮抓取 |几个值得注意的环境细节前置约束assumeFalse(Environment.isNamespaceRbacScope())——指标测试不适配 namespace RBAC 作用域该环境下直接跳过BeforeAll第一行。指标稳定等待收集前会LockSupport.parkNanos休眠SAFETY_RECONCILIATION_INTERVAL即“reconciliation interval 10s”等待 Operator 与 operand 的指标值稳定避免抓到瞬时抖动。指标采集基础类BaseMetricsCollector继承自 kubetest4j 的MetricsCollectorBaseMetricsCollector.java除抓取 operand 指标外还提供getJvmThreadsLiveThreads()、getSystemCpuUsage()、getJvmGcPauseSecondsMax()等 JVM/系统指标方法主要服务于性能测试MetricsST 主要使用其collectMetricsFromPods与waitForSpecificMetricAndCollect能力。断言工具所有断言集中在MetricsUtilsMetricsUtils.java常用方法包括assertMetricValue、assertMetricValueNotNull、assertMetricResources、assertCoMetricResources针对 CO 的资源维度指标、assertMetricValueNullOrZero以及getExporterRunScript读取 KafkaExporter Pod 内的启动脚本。后置清理只有一步清理本测试类创建的全部资源“Common cleaning of all resources created by this test class”。用例一testKafkaMetrics —— Kafka Broker 自身指标文档步骤检查从 Kafka Pod 收集的指标中特定指标可用且取值符合预期。源码只做了三条断言MetricsST.java| 指标 | 断言 | 含义 | | - | - | - | |kafka_server_replicamanager_leadercount| 值 3.0assertMetricValueCount | 3 个 broker 各有一个样本leader 数合计 3与metrics-cluster-0的 3 broker 规模吻合 | |kafka_server_replicamanager_partitioncount| 值 2 | 已创建多个 topic7 分区 x 3 个 topic分区总数必然 2 | |kafka_server_replicamanager_underreplicatedpartitions| 值 0.0 | 集群健康无欠复制分区 |这些指标来自 Kafka 的 JMXkafka.serverMBean经 JMX Prometheus Exporter 按kafka.servertype(.), name(.)...规则改写为 Prometheus 名称——仓库示例 kafka-metrics.yaml 中的 ConfigMap 就是这套规则的完整参考lowercaseOutputName: truekafka.server的 listener 级指标、Percent类指标、PerSec计数器以及 KRaft 相关的raft-metrics/raft-channel-metrics/broker-metadata-metrics都有专门 patterntype: COUNTER/GAUGE/UNTYPED。kafka_server_replicamanager_*这类“无附加标签的 Value 指标”恰好命中通配规则kafka.(\w)type(.), name(.)Value。用例二testClusterOperatorMetrics —— Operator 自身指标文档步骤(1) 检查 CO Pod 中 Kafka reconciliation 相关指标(2) 检查收集到的指标包含 Kafka 资源数据(3) 检查不含 KafkaRebalance 资源数据。源码断言MetricsST.javareconciliation 基础指标以Kafka.RESOURCE_KIND为过滤条件strimzi_reconciliations_periodical_totalstrimzi_reconciliations_duration_seconds_bucketstrimzi_reconciliations_successful_total资源维度指标assertCoMetricResources验证两个命名空间中各自有 1 个Kafka资源被 CO 跟踪而assertCoMetricResourcesNullOrZero验证KafkaRebalance资源维度指标不存在或为 0本套件从未创建过 KafkaRebalance 资源。StrimziPodSet 维度每个 Kafka 集群拆分为 broker/controller 两个 NodePool因此metrics-test-1命名空间中StrimziPodSet资源计数期望为2.0同时断言strimzi_reconciliations_duration_seconds_bucket、strimzi_reconciliations_already_enqueued_total、strimzi_reconciliations_successful_total、strimzi_reconciliations_total在 PodSet kind 下均存在。这说明 CO 的指标体系包含两类一是“reconciliation 事件”指标次数、耗时直方图、入队次数等带 kind/namespace/name 标签二是“受管资源存在性”指标。测试通过“有/无 KafkaRebalance 数据”的正反向断言验证指标与集群中实际资源状态一致。用例三testUserOperatorMetrics —— User Operator 指标文档步骤从 User Operator Pod 收集指标检查关于 KafkaUser 的特定指标可用。实现上复用 kafka collector 的 builder替换组件为UserOperatorMetricsComponent后收集MetricsST.java。断言点strimzi_reconciliations_successful_total、strimzi_reconciliations_duration_seconds_bucket、strimzi_reconciliations_periodical_total、strimzi_reconciliations_total在KafkaUserkind 下均非空assertMetricResources(namespaceFirst, KafkaUser, 2.0)与前置步骤创建的 2 个 TLS KafkaUser 一一对应。注意前置配置中 Entity Operator 的 Topic/User Operator reconciliation interval 被显式设为 30 秒这正是这些*_total/periodical_*指标能在测试窗口内产生非零值的原因。用例四testKafkaExporterMetrics —— Kafka Exporter 基础指标文档步骤(1) 创建 Kafka producer/consumer 并交换消息(2) 检查kafka_consumergroup_current_offset指标(3) 对每个 broker Pod 检查kafka_broker_info。实现细节MetricsST.java用KafkaProducerConsumerBuilder在metrics-test-0命名空间创建 producer 与 consumer Job对kafkaExporterTopicName发送 5000 条消息bootstrap 地址为metrics-cluster-0-kafka-bootstrapplain 监听并用ClientUtils.waitForClientsSuccess等待双方 Job 成功断言kafka_consumergroup_current_offset{.*}非空——消息交换后消费组有真实位点KafkaExporter 才能导出该指标遍历 broker Pod用动态正则kafka_broker_info\{addresspod.metrics-cluster-0-kafka-brokers.metrics-test-0.svc.*逐个 broker 校验kafka_broker_info的address标签值应包含各 broker 的内部服务地址验证 exporter 正确连接了每个 broker。该用例标记为IsolatedTest串行执行因为它依赖“先产生消费数据、再抓指标”的时序。用例五testKafkaExporterDifferentSetting —— 修改 Exporter 配置的滚动更新文档步骤与源码对应MetricsST.java| Step | 文档描述 | 源码实现 | | - | - | - | | 1 | 读取 KafkaExporter 的 run.sh 并检查默认配置 |getExporterRunScript拉取 exporter Pod 内的启动脚本断言包含--group.filter.*与--topic.filter.*默认匹配所有组与 topic | | 2 | 检查指标包含__consumer_offsets的信息 |assertMetricValueNotNullkafka_topic_partitions\{topic__consumer_offsets\}非空 | | 3 | 修改 Kafka CR 中 KafkaExporter 配置group 正则改为my-group.*、topic 正则改为随机topicName等待滚动更新 |KafkaUtils.replace修改spec.kafkaExporter.groupRegex/topicRegexDeploymentUtils.waitTillDepHasRolled等待 exporter Deployment 滚动 1 次 | | 4 | 再次检查 run.sh | 断言脚本包含--group.filtermy-group.*与--topic.filtertopicName| | 5 | 检查指标不再包含__consumer_offsets|assertMetricValueNullOrZero| | 6 | 还原配置并等待滚动更新 | 将两个正则改回.*再次waitTillDepHasRolled|这个用例的价值在于完整覆盖了“Kafka CR → Operator 生成 exporter 启动参数 → Deployment 滚动更新 → 指标面变化”的闭环证明spec.kafkaExporter的groupRegex/topicRegex是实时生效的配置而非一次性模板。对应地仓库示例 kafka-metrics.yaml 中默认写法即为kafkaExporter: topicRegex: .* groupRegex: .*用例六testKafkaMetricsSettings —— metricsConfig 外部 ConfigMap 的透传文档步骤(1) 创建外部指标配置 ConfigMap(2) 在 Kafka CR 中引用它并等待 Pod 稳定CO 不应触发滚动更新(3) 检查每个 Pod 的 metrics ConfigMap 包含外部数据(4) 修改外部 ConfigMap(5) 再次等待稳定(6) 再次检查透传结果。源码实现MetricsST.java验证的是 JMX Prometheus Exporter 配置的valueFrom.configMapKeyRef机制// 外部 ConfigMapexternal-metrics-cm键为 metrics-config.yml // 内容lowercaseOutputName: true ConfigMapKeySelector cmks new ConfigMapKeySelectorBuilder() .withName(external-metrics-cm) .withKey(TestConstants.METRICS_CONFIG_YAML_NAME) .build(); JmxPrometheusExporterMetrics jmxPrometheusExporterMetrics new JmxPrometheusExporterMetricsBuilder() .withNewValueFrom() .withConfigMapKeyRef(cmks) .endValueFrom() .build();随后k.getSpec().getKafka().setMetricsConfig(jmxPrometheusExporterMetrics)写入metrics-cluster-1的 CR。断言逻辑是StUtils.getKafkaConfigurationConfigMaps列出该集群所有 Kafka 配置 ConfigMap逐一校验其中JSON 形式的指标配置键等于{lowercaseOutputName:true}——即 Operator 把外部 YAML 配置转换后写入了每个 broker/controller Pod 的 metrics ConfigMap。更新外部 ConfigMap 为lowercaseOutputName: false后CO 会感知变更并重新生成各 Pod 的 ConfigMap但PodUtils.verifyThatRunningPodsAreStable同时断言60 秒内没有滚动更新指标配置变更走 ConfigMap 热更新路径不重启 Pod。这一机制与用户侧配置完全一致。生产环境通常这样写 Kafka CR见 kafka-metrics.yamlspec: kafka: metricsConfig: type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: kafka-metrics key: kafka-metrics-config.ymlexamples/metrics/目录还配套了 kafka-connect-metrics.yaml、kafka-bridge-metrics.yaml、kafka-cruise-control-metrics.yaml、kafka-mirror-maker-2-metrics.yaml 以及 Prometheus/Grafana 的安装与仪表盘文件覆盖本套件验证的所有组件。用例七testKafkaConnectAndConnectorMetrics —— Connect 与 Connector 指标文档步骤与源码对应MetricsST.java部署 KafkaConnectKafkaConnectTemplates.kafkaConnectWithMetricsAndFileSinkPlugin创建带指标配置与 FileSink 插件的 Connect并通过注解strimzi.io/use-connector-resources: true启用 KafkaConnector CR 方式管理连接器同时用connectMetricsConfigMap提供指标规则参考 kafka-connect-metrics.yaml 中kafka_connect_worker_*、kafka_connect_node_*等 pattern。创建 KafkaConnectorKafkaConnectorTemplates.kafkaConnector创建连接器并等待 Ready。抓取 Connect Pod 指标断言以下指标存在且值 0kafka_connect_node_request_total{clientid.*}kafka_connect_node_response_total{clientid.*.*}kafka_connect_network_io_total{clientid.*.*}抓取 CO 指标并做资源维度断言metrics-test-0中有 1 个KafkaConnect、1 个KafkaConnectorassertCoMetricResources而metrics-test-1中二者必须为空或 0assertCoMetricResourcesNullOrZero——这是命名空间隔离性的验证额外断言StrimziPodSet资源指标metrics-test-0中 1.0两个 NodePoolmetrics-test-1中 0.0。用例同时携带CONNECT与CONNECT_COMPONENTS标签属于“组件级指标”验证不仅 Connect 自身暴露 JMX 指标CO 也要以资源维度暴露其存在性。用例八testMirrorMaker2Metrics —— MM2 与 CO 指标文档步骤部署 KafkaMirrorMaker2 → 收集 MM2 Pod 指标 → 校验特定指标 → 收集 CO 指标 → 校验 CO 中包含该 MM2 的数据。源码MetricsST.java用mirrorMaker2MetricsConfigMapkafkaMirrorMaker2WithMetrics在metrics-test-0部署名为mm2-cluster的 MM2源集群为metrics-cluster-0、目标集群为metrics-cluster-1operand 指标断言kafka_connect_worker_connector_count恰好等于 2.0MM2 内置的 MirrorCheckpointConnector 与 MirrorSourceConnector 等 connector 总数kafka_connect_worker_task_count 1CO 指标断言metrics-test-0中有 1 个KafkaMirrorMaker2资源metrics-test-1中为空/0且 PodSet 指标 1。用例九testKafkaBridgeMetrics —— Bridge 指标含客户端压测文档步骤部署 KafkaBridge → 接入 producer/consumer 客户端持续收发 → 收集 Bridge 指标 → 校验特定指标 → 收集 CO 指标 → 校验 CO 数据。源码MetricsST.java细节KafkaBridgeTemplates.kafkaBridgeWithMetrics部署名为my-bridge的 Bridge指向metrics-cluster-0的 plain bootstrap由于环境默认启用 NetworkPolicy 拒绝策略需两条放行allowNetworkPolicySettingsForBridgeScraperscraper → bridge与allowNetworkPoliciesForBridgeClientsHTTP 客户端 → bridgeHttpProducerConsumerBuilder通过 Bridge 的 HTTP 接口默认 8080 端口TestConstants.HTTP_BRIDGE_DEFAULT_PORT对bridgeTopicName持续生产/消费注释特别说明不能等 producer/consumer Job 结束否则strimzi_bridge_kafka_producer_count之类的活跃连接指标会归零operand 指标断言strimzi_bridge_kafka_producer_count与strimzi_bridge_kafka_consumer_connection_count非空且收集结果包含strimzi_bridge_http_server指标组——这些是 Strimzi 为 Bridge 定制的strimzi_bridge_*指标验证了 kafka-bridge-metrics.yaml 示例所配置的 exporter 规则CO 指标断言metrics-test-0中有 1 个KafkaBridgemetrics-test-1为空/0。用例十testCruiseControlMetrics —— CruiseControl HTTP 指标端点文档步骤检查 CruiseControl Pod 收集到的特定指标可用。源码MetricsST.java走的是与 JMX exporter 不同的路径CruiseControlUtils.callApiWithAdminCredentials以管理员凭据通过 HTTP GET 请求 CruiseControl 的metrics 专用端口上的/metrics端点拿到 Prometheus 文本格式后用正则^([^#].*)\s([^\s]*)$多行解析出所有非注释行断言至少解析出 1 个指标组groupCount 0每一行的指标名与指标值均非空。这是一种“格式完整性”验证只要端点返回的是合法的两列key value结构且非空即视为 CruiseControl 指标暴露正常。CruiseControl 的指标配置模板见 kafka-cruise-control-metrics.yaml。断言工具与指标采集架构小结MetricsST 的全部断言委托给 MetricsUtils.java可归纳为三层值断言assertMetricValue精确值、assertMetricValueHigherThanOrEqualTo下限、assertMetricValueCount样本数与值和、assertMetricCountHigherThan样本数存在性断言assertMetricValueNotNull非空、assertMetricValueNullOrZero为空或 0用于“修改配置后指标应消失”的反向验证CO 资源维度断言assertCoMetricResources/assertCoMetricResourcesNullOrZero/assertCoMetricResourceNotNull内部通过getResourceMetricPattern(namespace, kind)构造带namespace、kind标签的正则——这是“Operator 是否正确跟踪命名空间内资源”这一类可观测性验证的统一手段。采集侧则形成统一架构Scraper Pod同命名空间内→ 目标组件的指标端点 → BaseMetricsCollector 缓存到内存结构 → 正则断言。组件端点类型包括 JMX Prometheus ExporterKafka/Connect/MM2/Bridge、Kafka Exporter 独立 Deployment、Operator 的 strimzi-metrics-reporter 以及 CruiseControl 的 HTTP/metrics端口。在自己的环境复现从示例 YAML 入手仓库examples/metrics/提供了与本套件一一对应的生产级配置样例建议按以下顺序核对| 组件 | 示例文件 | 关键配置 | | - | - | - | | Kafka KafkaExporter | kafka-metrics.yaml |spec.kafka.metricsConfigjmxPrometheusExporter configMapKeyRef、spec.kafkaExporter.topicRegex/groupRegex| | KafkaConnect | kafka-connect-metrics.yaml |spec.metricsConfig规则覆盖kafka_connect_worker_*、kafka_connect_node_*、kafka_connect_connector_task_status| | KafkaBridge | kafka-bridge-metrics.yaml | Bridge 指标规则产出strimzi_bridge_*指标 | | CruiseControl | kafka-cruise-control-metrics.yaml | 启用 HTTP/metrics端口 | | MirrorMaker2 | kafka-mirror-maker-2-metrics.yaml | MM2 的 JMX exporter 规则 |复现 MetricsST 的核心验证只需三步应用上述 Kafka 示例含 NodePool 与metricsConfig等待strimzi-controller/strimzi-pod-set相关 Pod 就绪在集群内启动一个临时 Pod等价于 suite 中的 scrapercurl kafka-pod:metrics-port/metrics确认存在kafka_server_replicamanager_leadercount、kafka_server_replicamanager_partitioncountKafkaExporter 端点确认kafka_broker_info、kafka_consumergroup_current_offset需先有消费组活动从 Operator Pod 的 metrics 端点确认strimzi_reconciliations_successful_total等资源维度指标包含你的集群名并验证不存在任何你未创建过的资源 kind如 KafkaRebalance。适用前提与限制本套件依赖真实 Kubernetes 集群与make systemtest等系统测试工具链见 Makefile 与 development-docs/TESTING.md不在 namespace RBAC 作用域模式下运行指标取值断言如 leadercount3与套件固定的集群规模3 broker 3 controller绑定若自行缩扩容需同步调整期望值KafkaExport 的kafka_broker_info地址格式断言依赖 Strimzi 的内部 Headless Service 命名pod.cluster-kafka-brokers.ns.svc自定义 Pod/Service 模板时需重新推导CO 资源维度指标只反映 Operator 当前跟踪的资源集合assertCoMetricResourcesNullOrZero类反向断言成立的前提是测试窗口内未创建对应 kind 的资源。参考路径索引套件源码与文档MetricsST.java、MetricsST.md标签说明labels/metrics.md采集与断言基础设施BaseMetricsCollector.java、MetricsUtils.java指标配置示例examples/metrics/含 Prometheus 安装、Grafana 仪表盘、strimzi-metrics-reporter 配置【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考