Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use different labels other than job and instance when building the dev dashboards #13174

Closed
arkbriar opened this issue Oct 31, 2023 · 0 comments · Fixed by #13209
Closed

Use different labels other than job and instance when building the dev dashboards #13174

arkbriar opened this issue Oct 31, 2023 · 0 comments · Fixed by #13209

Comments

@arkbriar
Copy link
Contributor

arkbriar commented Oct 31, 2023

Is your feature request related to a problem? Please describe.

According to the Prometheus doc here, job and instance are two labels attached by the collector automatically:

  • job: The configured job name that the target belongs to.
  • instance: The : part of the target's URL that was scraped.

It works good for local dashboards but it doesn't for the Kubernetes'. In Kubernetes, there's only one overall job for all RisingWave processes, no matter the roles. Thus the job loses its meaning of which role or component an instance belongs to. Similarly, the instance can not be treated as a typical identifier of a process although it is a unique identifier at a certain point. The reason is Kubernetes will reclaim and reuse IPs. Pod name is a better one in this case.

Describe the solution you'd like

There are two additional labels that can be used for the same purposes in Kubernetes (at least in the operator deployment):

  • risingwave_component, to replace the job
  • pod, to replace the instance

It would be great if we could build the dashboard for Kubernetes with these two labels instead. It may require parameterization for these two labels and substitution everywhere they occur.

Describe alternatives you've considered

  1. Overwrite and tweak these two labels in Kubernetes. However, though these labels are not widely used, it's not a good solution to tweak the meanings.
  2. Attach the two labels locally. But pod is meaningless outside k8s.

Additional context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant