[Feature] Hide selected checks from the public status page using a Grafana custom label

Aperta
  • Qualcosa non va?
#26 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
grafana, typescript
Ambito
backend, observability-sre, security

Direzione di ricerca

Traccia il plumbing esistente delle custom label di sm_check_info e i query builder PromQL lato server. Verifica come viene letta la configurazione e come vengono assemblate le query di discovery, uptime, latenza e dettaglio. Valida il nome di hide-label prima dell'interpolazione e verifica che le query generate escludano i check corrispondenti, lasciando visibili i check senza label e quelli con una label diversa, senza esporre la configurazione al browser.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Problem

ProbeView currently discovers and publishes all Grafana Synthetic Monitoring
checks from sm_check_info.

Some checks target private, internal, staging, admin, or otherwise sensitive
URLs. We still want to monitor and alert on them in Grafana, but they should not
appear on the public ProbeView status page, and their data should not be included
in public-facing status queries.

Proposed solution

Add optional server-side configuration to hide checks using a strict Grafana
Synthetic Monitoring custom-label match.

Suggested variables:

SM_HIDE_LABEL=visibility
SM_HIDE_VALUE=private

Behavior:

  • By default, all checks remain visible.
  • When both variables are configured, only checks whose sm_check_info custom
    label exactly matches label_<SM_HIDE_LABEL>="<SM_HIDE_VALUE>" are hidden.
  • Checks without the label remain visible.
  • Checks with the label set to any other value remain visible.
  • Hidden checks should never land in the UI payload.
  • Hidden checks should also be filtered out of PromQL queries, not merely
    removed after fetching results.

Example:

visibility = private

A check with that custom label would continue to exist in Grafana Synthetic
Monitoring and continue to alert there, but ProbeView would exclude it from:

  • overview discovery
  • uptime and latency PromQL queries
  • grouping, search, sort, and aggregate public status rendering
  • per-check detail lookup and history pages

Because Grafana Synthetic Monitoring custom labels are exposed on
sm_check_info with a label_ prefix, the discovery query can filter with a
negative matcher such as:

sm_check_info{label_visibility!="private"}

For uptime and latency metrics, custom labels are not present directly on the
probe metrics, so ProbeView should filter them through a PromQL join against the
visible sm_check_info series. This keeps hidden checks out of public query
results rather than only dropping them in application code.

The feature should remain server-only: no NEXT_PUBLIC_ variables, no hidden
label names or values sent to the browser, and no persistence.

Alternatives considered

Use an allow-list label such as visibility=public.

That is safer for strict opt-in publishing, but it would be more disruptive for
existing installations. The desired behavior here is default-public with
explicit strict opt-out.

Filter hidden checks only after querying all metrics.

This is simpler, but it does not meet the privacy expectation. Hidden checks
should not be included in public-facing query results at all.

Maintain a static list of hidden URLs or check IDs.

This conflicts with ProbeView's dynamic discovery model and would be brittle
when checks are renamed or targets change.

Additional context

ProbeView already reads custom labels from sm_check_info for grouping and
purpose labels, so this feature can reuse the same label plumbing. Grafana
documents that Synthetic Monitoring custom labels are exposed on sm_check_info
using the label_ prefix and that probe metrics need a PromQL join when
filtering or propagating custom labels.

Reference:
https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/

Implementation note: because SM_HIDE_LABEL is interpolated into PromQL label
syntax, ProbeView should validate it as a Prometheus label name before building
queries.

Lingua principale
TypeScript
Stelle
0
Fork
0
Merge medio
1g 16h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeForAfrica/probeview

Tutte le issue di CodeForAfrica/probeview

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.