All the kube_job_* metrics have a job label with the name of the Job, however this label is conflicting with the job label assigned by Prometheus per what is defined in the job_name of the scrape_config
Prometheus keeps the original value of the label job in a new label called exported_job, but this is a bit confusing.
I think it would be better to rename the job label in the kube_job_* metrics to job_name
Does this also happen if honor_labels is set to true? Technically the kube-state-metrics target still has the job label, and the unique combination of labels still uniquely identify the metrics.
Nonetheless I think I agree, there are scenarios where this could become a problem, so maybe using job_name (or maybe kube_job?) is not a bad idea, as long as we do it consistently.
It seems that job label is a special case in Prometheus, so if the source metric has a job label it is renamed to exported_job.
As you said, uniquness of the metrics is prserved, but I would rather we use a different label name and not job.
job_name sounds reasonable to me, but I'm not married to it :)
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
ping @brancz 馃槃
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle stale
I'm not really happy with any of the solutions, I'll have to discuss more with the other prometheus devs to see if they have any better ideas.
As a Prometheus user, for me it makes sense to use "job_name" as the label of source metric and "job" as the label of Prometheus job to do it consistently.
Agreed, let's change the label here to job_name.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
As far as I know this has not been implemented yet, so re-opening this.
Most helpful comment
Agreed, let's change the label here to
job_name.