拓冰网站定制 
kube-state-metrics 中 Job 监控指标详解从 kube_job_info 到失败原因与挂起状态的完整指南【免费下载链接】kube-state-metricsAdd-on agent to generate and expose cluster-level metrics.项目地址: https://gitcode.com/GitHub_Trending/ku/kube-state-metrics本文基于 kube-state-metrics 仓库中 docs/metrics/workload/job-metrics.md 的指标定义系统讲解 Jobbatch/v1.Job相关的 17 个 Prometheus 指标包括指标含义、标签结构、稳定级别STABLE/EXPERIMENTAL并深入 internal/store/job.go 源码解析每个指标的取值逻辑——特别是kube_job_status_failed的失败原因展开机制、kube_job_complete/kube_job_failed的 condition 标签语义以及如何通过--metric-labels-allowlist与--metric-annotations-allowlist控制标签/注解指标。读完后你可以准确编写针对 Job 成功率、运行时长、挂起/就绪状态的 PromQL并理解指标背后的实现边界。kube-state-metrics 如何生成 Job 指标kube-state-metrics 是一个附加组件add-on agent负责发现集群中的 Kubernetes 对象并生成集群级指标。对于 Job其生成路径在 internal/store/builder.go 中注册internal/store/builder.go 中的buildJobStores()调用jobMetricFamilies(b.allowAnnotationsList[jobs], b.allowLabelsList[jobs])说明 Job 指标受按资源维度配置的注解/标签 allowlist 控制资源名使用复数形式jobs数据源由 internal/store/job.go 的createJobListWatch提供它通过kubeClient.BatchV1().Jobs(ns).List/Watch并支持fieldSelector过滤因此可以通过--namespace或资源选择器限制被监控的 Job 范围所有指标均为 Gauge 类型通过 internal/store/job.go 的wrapJobFunc统一为每个指标值注入默认标签namespace与job_name见源码中descJobLabelsDefaultLabels []string{namespace, job_name}。每个指标的稳定性STABLE 或 EXPERIMENTAL即 ALPHA在 internal/store/job.go 中通过generator.NewFamilyGeneratorWithStability的第四个参数显式声明测试用例 internal/store/job_test.go 中期望输出的# HELP前缀如[STABLE] Unix creation timestamp也印证了这一点。完整指标清单以下表格完整继承自 docs/metrics/workload/job-metrics.md并补充了源码中的指标描述help 文本Metric nameMetric typeDescriptionLabels/tagsStatuskube_job_annotationsGaugeKubernetes annotations converted to Prometheus labels受 --metric-annotations-allowlist 控制job_name、namespace、annotation_JOB_ANNOTATIONEXPERIMENTALkube_job_infoGaugeInformation about jobjob_name、namespaceSTABLEkube_job_labelsGaugeKubernetes labels converted to Prometheus labels受 --metric-labels-allowlist 控制job_name、namespace、label_JOB_LABELSTABLEkube_job_ownerGaugeInformation about the Jobs ownerjob_name、namespace、owner_kind、owner_name、owner_is_controllerSTABLEkube_job_spec_parallelismGauge该 Job 在任意时刻最多应运行的 Pod 数spec.parallelismjob_name、namespaceSTABLEkube_job_spec_completionsGauge该 Job 期望成功完成的 Pod 数spec.completionsjob_name、namespaceSTABLEkube_job_spec_active_deadline_secondsGauge相对 startTime 的 Job 最长活跃秒数超时后系统尝试终止它job_name、namespaceSTABLEkube_job_status_activeGauge正在运行的 Pod 数status.activejob_name、namespaceSTABLEkube_job_status_succeededGauge达到 Succeeded 阶段的 Pod 数status.succeededjob_name、namespaceSTABLEkube_job_status_failedGauge达到 Failed 阶段的 Pod 数并附带失败原因job_name、namespace、reasonSTABLEkube_job_status_start_timeGaugeJob 被 Job Manager 确认的起始时间Unix 时间戳job_name、namespaceSTABLEkube_job_status_completion_timeGaugeJob 完成时间Unix 时间戳job_name、namespaceSTABLEkube_job_completeGaugeJob 是否完成执行job_name、namespace、conditiontrue|false|unknownSTABLEkube_job_failedGaugeJob 是否执行失败job_name、namespace、conditiontrue|false|unknownSTABLEkube_job_createdGaugeUnix creation timestampjob_name、namespaceSTABLEkube_job_status_suspendedGauge是否处于挂起状态job_name、namespaceEXPERIMENTALkube_job_status_readyGauge属于该 Job 的就绪readyPod 数量job_name、namespaceEXPERIMENTALSpec 类指标只在字段存在时输出Spec 类指标的取值逻辑体现了 kube-state-metrics 的一个重要约定Kubernetes 中为指针类型的可选字段若未设置则不输出该指标样本。kube_job_spec_parallelism读取j.Spec.Parallelism代码中判断if j.Spec.Parallelism ! nil才追加样本internal/store/job.gokube_job_spec_completions、kube_job_spec_active_deadline_seconds同理internal/store/job.go。测试用例 internal/store/job_test.go 中的SuccessfulJob2NoActiveDeadlineSeconds就验证了这一点该 Job 未设置activeDeadlineSeconds期望输出中没有任何kube_job_spec_active_deadline_seconds样本。因此在编写 PromQL 时不应假设 spec 类指标一定存在。类似地kube_job_status_start_time与kube_job_status_completion_time也仅在status.startTime/status.completionTime非 nil 时输出 Unix 时间戳kube_job_created则读取metadata.creationTimestamp零值时间不输出。Status 类指标与 condition 标签的语义状态类指标直接映射JobStatus字段kube_job_status_active、kube_job_status_succeeded输出status.active/status.succeeded的整数值。而kube_job_complete与kube_job_failed来自status.conditions源码遍历j.Status.Conditions只处理Type JobComplete或JobFailed的条件调用addConditionMetrics(c.Status)生成三行样本标签condition取值分别为true、false、unknowninternal/store/job.go测试输出清晰展示了这一形态internal/store/job_test.gokube_job_complete{conditionfalse,job_nameSuccessfulJob1,namespacens1} 0 kube_job_complete{conditiontrue,job_nameSuccessfulJob1,namespacens1} 1 kube_job_complete{conditionunknown,job_nameSuccessfulJob1,namespacens1} 0如果 Job 尚无对应 condition则该指标族完全没有样本。因此判断“Job 成功完成”应写kube_job_complete{conditiontrue} 1而不是简单判断kube_job_complete 1。kube_job_status_failed 的失败原因展开机制这是 Job 指标中最有实战价值、也最容易误解的一个指标。其逻辑internal/store/job.go分为三种情况status.failed 0只输出一条无reason标签、值为 0 的样本kube_job_status_failed{job_nameRunningJob1,namespacens1} 0status.failed 0且存在JobFailedcondition 且原因已知对源码中定义的三种已知原因BackoffLimitExceeded、DeadlineExceeded、Evicted变量jobFailureReasonsinternal/store/job.go各输出一条样本值为 0/1 布尔表示该 condition 的Reason是否匹配kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonBackoffLimitExceeded} 1 kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonDeadlineExceeded} 0 kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonEvicted} 0status.failed 0但原因不在已知列表中输出一条reason的样本值直接为status.failed的计数internal/store/job_test.go 中的FailedJobWithNoConditions用例即验证了reason形态。注意这里存在两种量纲的样本带原因标签时是“原因命中与否”的布尔值reason时是“失败 Pod 数量”。因此聚合失败量时应区分场景例如# 因退避超限而失败的 Job kube_job_status_failed{reasonBackoffLimitExceeded} 1 # 无已知原因的失败 Pod 总数 sum(kube_job_status_failed{reason})EXPERIMENTAL 指标kube_job_status_suspended 与 kube_job_status_ready文档中标记为 EXPERIMENTAL 的两个指标在源码中对应basemetrics.ALPHA稳定性kube_job_status_suspended遍历status.conditions找Type JobSuspended的条件值为status True的布尔值internal/store/job.go。测试中挂起的 Job 输出kube_job_status_suspended{...} 1恢复后输出0internal/store/job_test.gokube_job_status_ready读取status.ready指针字段nil 时取 0internal/store/job.go。注意JobStatus.Ready是较新 Kubernetes 版本引入的字段低版本集群上该字段通常恒为 nil指标恒为 0——从源码结构看这是字段缺失而非“没有就绪 Pod”使用该指标前应确认集群版本支持。仓库 data.yaml 中记录当前开发分支v2.20.0/main对应的 Kubernetes 版本为 1.36可视为指标定义所针对的 API 基线。EXPERIMENTAL 指标可能随版本调整或删除生产告警建议优先基于 STABLE 指标构建。kube_job_owner识别由 CronJob 派生的 Jobkube_job_owner基于metadata.ownerReferences生成internal/store/job.go存在多个 owner 时每个 owner 输出一条样本标签为owner_kind、owner_name、owner_is_controller后者取owner.Controller布尔值未设置时记为false无 owner 时输出一条所有标签值为空的样本值为 1。测试用例internal/store/job_test.go展示了 CronJob 场景的典型输出kube_job_owner{job_nameRunningJob1,namespacens1,owner_is_controllertrue,owner_kindCronJob,owner_namecronjob-name} 1这使得“统计某 CronJob 最近一次派生 Job 的状态”成为可能kube_job_status_succeeded * on(namespace) group_left(owner_name) (kube_job_owner{owner_kindCronJob, owner_is_controllertrue} 1)用 allowlist 控制 kube_job_labels 与 kube_job_annotationskube_job_labels与kube_job_annotations是“Kubernetes 元数据转 Prometheus 标签”的通用机制二者默认不输出任何样本源码在生成函数开头即判断if len(allowLabelsList) 0 { return metric.Family{} }internal/store/job.go。需要通过 CLI 参数开启且资源名使用复数jobs参数定义见 docs/developer/cli-arguments.md# 将 Job 的 app 与 env 标签透出为 Prometheus 标签 --metric-labels-allowlistjobs[app,env] # 将指定注解透出 --metric-annotations-allowlistjobs[kubernetes.io/team]参数要点摘自 CLI 帮助文本格式为资源名[key1,key2,...]多个资源用逗号分隔例如jobs[app],pods[app]...某个资源可以单独用*放行所有 key如jobs[*]但帮助文本明确提示这样做有严重的性能影响全通配*作为 key 时只对列表第一个条目生效出现在其他位置会被忽略。allowlist 的解析实现位于 pkg/allowdenylist 与 pkg/allow构建时按资源名从b.allowLabelsList[jobs]取出解析结果传入jobMetricFamiliesinternal/store/builder.go。端到端示例从测试期望输出理解真实指标形态单元测试 internal/store/job_test.go 用真实对象构造并断言全部指标输出是最可靠的“文档 源码一致性”证据。以RunningJob1运行中、由 CronJob 拥有、deadline 900s、并行度 1、期望完成 1为例期望输出为kube_job_owner{job_nameRunningJob1,namespacens1,owner_is_controllertrue,owner_kindCronJob,owner_namecronjob-name} 1 kube_job_created{job_nameRunningJob1,namespacens1} 1.5e09 kube_job_info{job_nameRunningJob1,namespacens1} 1 kube_job_spec_active_deadline_seconds{job_nameRunningJob1,namespacens1} 900 kube_job_spec_completions{job_nameRunningJob1,namespacens1} 1 kube_job_spec_parallelism{job_nameRunningJob1,namespacens1} 1 kube_job_status_active{job_nameRunningJob1,namespacens1} 1 kube_job_status_failed{job_nameRunningJob1,namespacens1} 0 kube_job_status_ready{job_nameRunningJob1,namespacens1} 0 kube_job_status_start_time{job_nameRunningJob1,namespacens1} 1.495800007e09 kube_job_status_succeeded{job_nameRunningJob1,namespacens1} 0注意细节运行中的 Job 没有kube_job_complete/kube_job_failed/kube_job_status_completion_time样本因为对应 condition 和字段尚未产生也没有kube_job_annotations/kube_job_labels样本测试以 nil allowlist 运行。常用 PromQL 场景基于上述指标语义以下查询可直接用于 Job 运维监控前提kube-state-metrics 已启用jobs资源监控# Job 实际运行时长秒完成时间 - 起始时间 kube_job_status_completion_time - kube_job_status_start_time # 集群中“运行超时风险”的 Job活跃时长已接近 deadline (time() - kube_job_status_start_time) / kube_job_spec_active_deadline_seconds # 并行度利用率活跃 Pod / 期望并行度 kube_job_status_active / kube_job_spec_parallelism # 期望完成进度 kube_job_status_succeeded / kube_job_spec_completions # 以 kube_job_info 为基数关联其他指标kube_job_info 恒为 1适合做 join 锚点 count by (namespace) (kube_job_info)小结与参考路径指标定义文档本文主体docs/metrics/workload/job-metrics.md指标实现取值逻辑、默认标签、失败原因列表internal/store/job.go单元测试期望输出形态internal/store/job_test.go资源注册与 allowlist 注入internal/store/builder.goCLI 参数说明allowlist 格式与通配符规则docs/developer/cli-arguments.md理解这 17 个指标时核心把握三点可选字段未设置则样本缺失condition 类指标固定输出 true/false/unknown 三行失败原因指标在“无已知原因”时量纲会从布尔切换为失败 Pod 计数。这三点正是编写可靠 Job 监控与告警的前提。【免费下载链接】kube-state-metricsAdd-on agent to generate and expose cluster-level metrics.项目地址: https://gitcode.com/GitHub_Trending/ku/kube-state-metrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kube-state-metrics 中 Job 监控指标详解：从 kube_job_info 到失败原因与挂起状态的完整指南
kube-state-metrics 中 Job 监控指标详解从 kube_job_info 到失败原因与挂起状态的完整指南【免费下载链接】kube-state-metricsAdd-on agent to generate and expose cluster-level metrics.项目地址: https://gitcode.com/GitHub_Trending/ku/kube-state-metrics本文基于 kube-state-metrics 仓库中 docs/metrics/workload/job-metrics.md 的指标定义系统讲解 Jobbatch/v1.Job相关的 17 个 Prometheus 指标包括指标含义、标签结构、稳定级别STABLE/EXPERIMENTAL并深入 internal/store/job.go 源码解析每个指标的取值逻辑——特别是kube_job_status_failed的失败原因展开机制、kube_job_complete/kube_job_failed的 condition 标签语义以及如何通过--metric-labels-allowlist与--metric-annotations-allowlist控制标签/注解指标。读完后你可以准确编写针对 Job 成功率、运行时长、挂起/就绪状态的 PromQL并理解指标背后的实现边界。kube-state-metrics 如何生成 Job 指标kube-state-metrics 是一个附加组件add-on agent负责发现集群中的 Kubernetes 对象并生成集群级指标。对于 Job其生成路径在 internal/store/builder.go 中注册internal/store/builder.go 中的buildJobStores()调用jobMetricFamilies(b.allowAnnotationsList[jobs], b.allowLabelsList[jobs])说明 Job 指标受按资源维度配置的注解/标签 allowlist 控制资源名使用复数形式jobs数据源由 internal/store/job.go 的createJobListWatch提供它通过kubeClient.BatchV1().Jobs(ns).List/Watch并支持fieldSelector过滤因此可以通过--namespace或资源选择器限制被监控的 Job 范围所有指标均为 Gauge 类型通过 internal/store/job.go 的wrapJobFunc统一为每个指标值注入默认标签namespace与job_name见源码中descJobLabelsDefaultLabels []string{namespace, job_name}。每个指标的稳定性STABLE 或 EXPERIMENTAL即 ALPHA在 internal/store/job.go 中通过generator.NewFamilyGeneratorWithStability的第四个参数显式声明测试用例 internal/store/job_test.go 中期望输出的# HELP前缀如[STABLE] Unix creation timestamp也印证了这一点。完整指标清单以下表格完整继承自 docs/metrics/workload/job-metrics.md并补充了源码中的指标描述help 文本Metric nameMetric typeDescriptionLabels/tagsStatuskube_job_annotationsGaugeKubernetes annotations converted to Prometheus labels受 --metric-annotations-allowlist 控制job_name、namespace、annotation_JOB_ANNOTATIONEXPERIMENTALkube_job_infoGaugeInformation about jobjob_name、namespaceSTABLEkube_job_labelsGaugeKubernetes labels converted to Prometheus labels受 --metric-labels-allowlist 控制job_name、namespace、label_JOB_LABELSTABLEkube_job_ownerGaugeInformation about the Jobs ownerjob_name、namespace、owner_kind、owner_name、owner_is_controllerSTABLEkube_job_spec_parallelismGauge该 Job 在任意时刻最多应运行的 Pod 数spec.parallelismjob_name、namespaceSTABLEkube_job_spec_completionsGauge该 Job 期望成功完成的 Pod 数spec.completionsjob_name、namespaceSTABLEkube_job_spec_active_deadline_secondsGauge相对 startTime 的 Job 最长活跃秒数超时后系统尝试终止它job_name、namespaceSTABLEkube_job_status_activeGauge正在运行的 Pod 数status.activejob_name、namespaceSTABLEkube_job_status_succeededGauge达到 Succeeded 阶段的 Pod 数status.succeededjob_name、namespaceSTABLEkube_job_status_failedGauge达到 Failed 阶段的 Pod 数并附带失败原因job_name、namespace、reasonSTABLEkube_job_status_start_timeGaugeJob 被 Job Manager 确认的起始时间Unix 时间戳job_name、namespaceSTABLEkube_job_status_completion_timeGaugeJob 完成时间Unix 时间戳job_name、namespaceSTABLEkube_job_completeGaugeJob 是否完成执行job_name、namespace、conditiontrue|false|unknownSTABLEkube_job_failedGaugeJob 是否执行失败job_name、namespace、conditiontrue|false|unknownSTABLEkube_job_createdGaugeUnix creation timestampjob_name、namespaceSTABLEkube_job_status_suspendedGauge是否处于挂起状态job_name、namespaceEXPERIMENTALkube_job_status_readyGauge属于该 Job 的就绪readyPod 数量job_name、namespaceEXPERIMENTALSpec 类指标只在字段存在时输出Spec 类指标的取值逻辑体现了 kube-state-metrics 的一个重要约定Kubernetes 中为指针类型的可选字段若未设置则不输出该指标样本。kube_job_spec_parallelism读取j.Spec.Parallelism代码中判断if j.Spec.Parallelism ! nil才追加样本internal/store/job.gokube_job_spec_completions、kube_job_spec_active_deadline_seconds同理internal/store/job.go。测试用例 internal/store/job_test.go 中的SuccessfulJob2NoActiveDeadlineSeconds就验证了这一点该 Job 未设置activeDeadlineSeconds期望输出中没有任何kube_job_spec_active_deadline_seconds样本。因此在编写 PromQL 时不应假设 spec 类指标一定存在。类似地kube_job_status_start_time与kube_job_status_completion_time也仅在status.startTime/status.completionTime非 nil 时输出 Unix 时间戳kube_job_created则读取metadata.creationTimestamp零值时间不输出。Status 类指标与 condition 标签的语义状态类指标直接映射JobStatus字段kube_job_status_active、kube_job_status_succeeded输出status.active/status.succeeded的整数值。而kube_job_complete与kube_job_failed来自status.conditions源码遍历j.Status.Conditions只处理Type JobComplete或JobFailed的条件调用addConditionMetrics(c.Status)生成三行样本标签condition取值分别为true、false、unknowninternal/store/job.go测试输出清晰展示了这一形态internal/store/job_test.gokube_job_complete{conditionfalse,job_nameSuccessfulJob1,namespacens1} 0 kube_job_complete{conditiontrue,job_nameSuccessfulJob1,namespacens1} 1 kube_job_complete{conditionunknown,job_nameSuccessfulJob1,namespacens1} 0如果 Job 尚无对应 condition则该指标族完全没有样本。因此判断“Job 成功完成”应写kube_job_complete{conditiontrue} 1而不是简单判断kube_job_complete 1。kube_job_status_failed 的失败原因展开机制这是 Job 指标中最有实战价值、也最容易误解的一个指标。其逻辑internal/store/job.go分为三种情况status.failed 0只输出一条无reason标签、值为 0 的样本kube_job_status_failed{job_nameRunningJob1,namespacens1} 0status.failed 0且存在JobFailedcondition 且原因已知对源码中定义的三种已知原因BackoffLimitExceeded、DeadlineExceeded、Evicted变量jobFailureReasonsinternal/store/job.go各输出一条样本值为 0/1 布尔表示该 condition 的Reason是否匹配kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonBackoffLimitExceeded} 1 kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonDeadlineExceeded} 0 kube_job_status_failed{job_nameFailedJob1,namespacens1,reasonEvicted} 0status.failed 0但原因不在已知列表中输出一条reason的样本值直接为status.failed的计数internal/store/job_test.go 中的FailedJobWithNoConditions用例即验证了reason形态。注意这里存在两种量纲的样本带原因标签时是“原因命中与否”的布尔值reason时是“失败 Pod 数量”。因此聚合失败量时应区分场景例如# 因退避超限而失败的 Job kube_job_status_failed{reasonBackoffLimitExceeded} 1 # 无已知原因的失败 Pod 总数 sum(kube_job_status_failed{reason})EXPERIMENTAL 指标kube_job_status_suspended 与 kube_job_status_ready文档中标记为 EXPERIMENTAL 的两个指标在源码中对应basemetrics.ALPHA稳定性kube_job_status_suspended遍历status.conditions找Type JobSuspended的条件值为status True的布尔值internal/store/job.go。测试中挂起的 Job 输出kube_job_status_suspended{...} 1恢复后输出0internal/store/job_test.gokube_job_status_ready读取status.ready指针字段nil 时取 0internal/store/job.go。注意JobStatus.Ready是较新 Kubernetes 版本引入的字段低版本集群上该字段通常恒为 nil指标恒为 0——从源码结构看这是字段缺失而非“没有就绪 Pod”使用该指标前应确认集群版本支持。仓库 data.yaml 中记录当前开发分支v2.20.0/main对应的 Kubernetes 版本为 1.36可视为指标定义所针对的 API 基线。EXPERIMENTAL 指标可能随版本调整或删除生产告警建议优先基于 STABLE 指标构建。kube_job_owner识别由 CronJob 派生的 Jobkube_job_owner基于metadata.ownerReferences生成internal/store/job.go存在多个 owner 时每个 owner 输出一条样本标签为owner_kind、owner_name、owner_is_controller后者取owner.Controller布尔值未设置时记为false无 owner 时输出一条所有标签值为空的样本值为 1。测试用例internal/store/job_test.go展示了 CronJob 场景的典型输出kube_job_owner{job_nameRunningJob1,namespacens1,owner_is_controllertrue,owner_kindCronJob,owner_namecronjob-name} 1这使得“统计某 CronJob 最近一次派生 Job 的状态”成为可能kube_job_status_succeeded * on(namespace) group_left(owner_name) (kube_job_owner{owner_kindCronJob, owner_is_controllertrue} 1)用 allowlist 控制 kube_job_labels 与 kube_job_annotationskube_job_labels与kube_job_annotations是“Kubernetes 元数据转 Prometheus 标签”的通用机制二者默认不输出任何样本源码在生成函数开头即判断if len(allowLabelsList) 0 { return metric.Family{} }internal/store/job.go。需要通过 CLI 参数开启且资源名使用复数jobs参数定义见 docs/developer/cli-arguments.md# 将 Job 的 app 与 env 标签透出为 Prometheus 标签 --metric-labels-allowlistjobs[app,env] # 将指定注解透出 --metric-annotations-allowlistjobs[kubernetes.io/team]参数要点摘自 CLI 帮助文本格式为资源名[key1,key2,...]多个资源用逗号分隔例如jobs[app],pods[app]...某个资源可以单独用*放行所有 key如jobs[*]但帮助文本明确提示这样做有严重的性能影响全通配*作为 key 时只对列表第一个条目生效出现在其他位置会被忽略。allowlist 的解析实现位于 pkg/allowdenylist 与 pkg/allow构建时按资源名从b.allowLabelsList[jobs]取出解析结果传入jobMetricFamiliesinternal/store/builder.go。端到端示例从测试期望输出理解真实指标形态单元测试 internal/store/job_test.go 用真实对象构造并断言全部指标输出是最可靠的“文档 源码一致性”证据。以RunningJob1运行中、由 CronJob 拥有、deadline 900s、并行度 1、期望完成 1为例期望输出为kube_job_owner{job_nameRunningJob1,namespacens1,owner_is_controllertrue,owner_kindCronJob,owner_namecronjob-name} 1 kube_job_created{job_nameRunningJob1,namespacens1} 1.5e09 kube_job_info{job_nameRunningJob1,namespacens1} 1 kube_job_spec_active_deadline_seconds{job_nameRunningJob1,namespacens1} 900 kube_job_spec_completions{job_nameRunningJob1,namespacens1} 1 kube_job_spec_parallelism{job_nameRunningJob1,namespacens1} 1 kube_job_status_active{job_nameRunningJob1,namespacens1} 1 kube_job_status_failed{job_nameRunningJob1,namespacens1} 0 kube_job_status_ready{job_nameRunningJob1,namespacens1} 0 kube_job_status_start_time{job_nameRunningJob1,namespacens1} 1.495800007e09 kube_job_status_succeeded{job_nameRunningJob1,namespacens1} 0注意细节运行中的 Job 没有kube_job_complete/kube_job_failed/kube_job_status_completion_time样本因为对应 condition 和字段尚未产生也没有kube_job_annotations/kube_job_labels样本测试以 nil allowlist 运行。常用 PromQL 场景基于上述指标语义以下查询可直接用于 Job 运维监控前提kube-state-metrics 已启用jobs资源监控# Job 实际运行时长秒完成时间 - 起始时间 kube_job_status_completion_time - kube_job_status_start_time # 集群中“运行超时风险”的 Job活跃时长已接近 deadline (time() - kube_job_status_start_time) / kube_job_spec_active_deadline_seconds # 并行度利用率活跃 Pod / 期望并行度 kube_job_status_active / kube_job_spec_parallelism # 期望完成进度 kube_job_status_succeeded / kube_job_spec_completions # 以 kube_job_info 为基数关联其他指标kube_job_info 恒为 1适合做 join 锚点 count by (namespace) (kube_job_info)小结与参考路径指标定义文档本文主体docs/metrics/workload/job-metrics.md指标实现取值逻辑、默认标签、失败原因列表internal/store/job.go单元测试期望输出形态internal/store/job_test.go资源注册与 allowlist 注入internal/store/builder.goCLI 参数说明allowlist 格式与通配符规则docs/developer/cli-arguments.md理解这 17 个指标时核心把握三点可选字段未设置则样本缺失condition 类指标固定输出 true/false/unknown 三行失败原因指标在“无已知原因”时量纲会从布尔切换为失败 Pod 计数。这三点正是编写可靠 Job 监控与告警的前提。【免费下载链接】kube-state-metricsAdd-on agent to generate and expose cluster-level metrics.项目地址: https://gitcode.com/GitHub_Trending/ku/kube-state-metrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考