Regarding the bug report of volcano-sh kube-state-metrics monitoring project, is it still maintained?

[gsmini]

Description

1. When I deployed the indicator collection according to the official documentation, I found that there was a bug in the collection code. I raised a PR in that repository, but it seems that no one maintains that project anymore, so I came here to ask if the indicator collection project is still maintained?（volcano-sh/kube-state-metrics）：add filtering judgment for the kube_pod_volcano_container_status_runn… kube-state-metrics#3

Steps to reproduce the issue

Describe the results you received and expected

Theoretically, only the indicators of the volcano label pod should be collected. The current bug is that the indicators of the k8s pod are collected, so when configuring the Grafana dashboard based on the indicators, it does not match the volcano task.

What version of Volcano are you using?

volcanosh/vc-webhook-manager:v1.10.0

Any other relevant information

No response

[hwdef]

Yes, it is also maintained.
PTAL @Monokaix @JesseStutler

[gsmini]

Yes, it is also maintained.
Thank you for taking a look at my PR

[Monokaix]

Yes, it is also maintained. PTAL @Monokaix @JesseStutler

Maybe we can find another way to solve the metrics introduced in that repo, it's not a good way to do intrusive modification of kube-state-metrics.

[hwdef]

Yes, it is also maintained. PTAL @Monokaix @JesseStutler

Maybe we can find another way to solve the metrics introduced in that repo, it's not a good way to do intrusive modification of kube-state-metrics.

I agree with this. I have long wanted to replace the current solution, but I have no good ideas. We may need a new exporter component

[Monokaix]

Hi, please use English first, which can allow other users around the world to understand.

[gsmini]

Yes, it is also maintained. PTAL @Monokaix @JesseStutler

Maybe we can find another way to solve the metrics introduced in that repo, it's not a good way to do intrusive modification of kube-state-metrics.

Yes, but I saw that the volcano task indicator implementation of the submission record history is also implemented in an intrusive way based on the original k8s kube-state-metrics. So I also adopted this solution at present. In the long run, it may not be the best solution. I also hope that you can come up with a separate component to facilitate the subsequent grafana dashboard business implementation based on the volcano business implementation of custom indicators.
I hope that day will come as soon as possible, and I wish this project will get better and better.

[gsmini]

Hi, please use English first, which can allow other users around the world to understand.

Sorry, the current text has been changed to English.

[yccharles]

My temp solution is : only keep volcano's metrics when prometheus scrape kube-state-metrics.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/instance: volcano-monitoring
  name: volcano-kube-state-metrics
  namespace: volcano-monitoring
spec:
  endpoints:
    - honorLabels: true
      interval: 30s
      port: http-metrics
      path: /metrics
      scheme: http
      scrapeTimeout: 30s
      metricRelabelings:
        - action: keep
          regex: .*_volcano_.*
          sourceLabels:
            - __name__
        - action: keep
          regex: '.+'
          sourceLabels:
            - queue
  jobLabel: app.kubernetes.io/name
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-state-metrics

or config prometheus.yaml by hand

- job_name: volcano-kube-state-metrics
  honor_labels: true
  honor_timestamps: true
  scrape_interval: 30s
  scrape_timeout: 30s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  metric_relabel_configs:
  - source_labels: [__name__]
    separator: ;
    regex: .*_volcano_.*
    replacement: $1
    action: keep
  - source_labels: [queue]
    separator: ;
    regex: .+
    replacement: $1
    action: keep

[gsmini]

My temp solution is : only keep volcano's metrics when prometheus scrape kube-state-metrics.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/instance: volcano-monitoring
  name: volcano-kube-state-metrics
  namespace: volcano-monitoring
spec:
  endpoints:
    - honorLabels: true
      interval: 30s
      port: http-metrics
      path: /metrics
      scheme: http
      scrapeTimeout: 30s
      metricRelabelings:
        - action: keep
          regex: .*_volcano_.*
          sourceLabels:
            - __name__
        - action: keep
          regex: '.+'
          sourceLabels:
            - queue
  jobLabel: app.kubernetes.io/name
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-state-metrics

or config prometheus.yaml by hand

- job_name: volcano-kube-state-metrics
  honor_labels: true
  honor_timestamps: true
  scrape_interval: 30s
  scrape_timeout: 30s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  metric_relabel_configs:
  - source_labels: [__name__]
    separator: ;
    regex: .*_volcano_.*
    replacement: $1
    action: keep
  - source_labels: [queue]
    separator: ;
    regex: .+
    replacement: $1
    action: keep

Thank you for your solution. The filtering solution after the indicator life cycle should meet the needs, but it does not solve the fundamental problem of https://github.com/volcano-sh
kube-state-metrics indicator monitoring.
It's ok. Let's put this issue aside for now. I guess the maintenance team is too busy to handle it. Let's solve it when they have time. 😁:)