Scope embedded SILO Console metrics to the current MINIO cluster
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 5.7k
- Forks
- 384
- Avg merge
- 2h 36m
- Merged PRs (30d)
- 2
Description
Parent: #763
Problem
Pigsty deliberately uses one shared job="minio" label for MinIO/SILO metrics. That is convenient for common dashboards, but the embedded Console currently receives only the VictoriaMetrics URL and job ID. With two MINIO clusters in one VictoriaMetrics tenant, an unscoped Console query can mix both clusters and display incorrect totals, health, drive, or traffic values.
Pigsty file-SD targets already carry a cls label, so the missing piece is to pass the current cluster selector into the Console.
Proposed change
For the embedded SILO Console, render the equivalent of:
MINIO_PROMETHEUS_JOB_ID=minio
MINIO_PROMETHEUS_EXTRA_LABELS='cls="<current-minio-cluster>"'
Keep job="minio" as the product-wide metric family selector and use cls as the tenant/cluster boundary. A separately deployed Console should use the equivalent CONSOLE_PROMETHEUS_JOB_ID and CONSOLE_PROMETHEUS_EXTRA_LABELS variables.
The Console must combine the configured selector with every widget query, including V3 queries and fallback/empty-state checks.
Related Console work:
- pgsty/silo-console#7
- pgsty/silo-console#8
Acceptance criteria
- Two SILO clusters publish into the same VictoriaMetrics tenant under
job="minio". - Opening either embedded Console shows only that cluster's series and totals.
- The selector is applied to Info, Usage, Traffic, Resources, and any query-driven health widget.
- Single-cluster behavior is unchanged.
- Cluster names are safely escaped and malformed extra-label configuration fails visibly rather than silently widening the query.
- A PromQL/API test demonstrates that unscoped data contains both clusters while each Console result contains exactly its configured
cls.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the embedded SILO Console configuration and the code that builds VictoriaMetrics/PromQL queries. Trace Info, Usage, Traffic, Resources, health, V3, and fallback queries, then use the PromQL/API test to verify unscoped data includes both clusters while each Console result contains only its configured cls label.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- prometheus
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100