Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature] Add Monitor page to Canopy

Aperta
  • Qualcosa non va?
#13,992 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@pallavithegod ci sta già lavorando.

Dal 15/10/2026.

  • #1414 di @pallavithegod — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
prometheus
Ambito
backend, documentation, frontend, observability, testing

Direzione di ricerca

Inizia esaminando docs/operation/observability/metrics.md ed elencando gli endpoint HTTP e le metriche di BanyanDB per le sezioni proposte. Documenta il layout e l’approccio al recupero dei dati in canopy/docs/monitor-design.md, quindi esamina la sidebar Canopy esistente e le posizioni dei test sotto canopy/e2e/. Il lavoro è completato quando è disponibile un piano circoscritto di progettazione e implementazione che copra la route /monitor, gli stati di caricamento/errore, il comportamento di aggiornamento, l’applicazione dei ruoli e i test.

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

Descrizione

database feature

Summary

Introduce a Monitor page in the Canopy web console that surfaces BanyanDB cluster/runtime health, key metrics, and node status — giving operators a single place to observe the state of the database from the UI.

Motivation

Today Canopy focuses on schema CRUD and ad-hoc query (Groups, Streams, Measures, Traces, IndexRules, Properties, TopN pipelines). There is no dedicated surface for runtime/cluster observability. Operators currently have to rely on:

  • raw BanyanDB HTTP endpoints,
  • external Prometheus/Grafana dashboards,
  • log scraping.

A first-class Monitor page in Canopy lowers the operational bar and complements the existing schema/query UI.

Goals

  • A new top-level Monitor entry in the Canopy sidebar.
  • Pulls data from BanyanDB's existing observability surface (HTTP API + Prometheus metrics where applicable).
  • Renders key health signals and recent trends.
  • Role-gated: available to admin (and possibly readonly).

Scope (suggested sections — refine during design)

  1. Cluster overview — node list, liveness, role (liaison/data), version, uptime.
  2. Shard / group status — per-group shard health, replica state, hot-node distribution (reuses concepts from existing BYDB-Replica work).
  3. Storage metrics — disk usage per node/path, segment counts, sidx/inverted-index sizes, write amplification (sourced from docs/operation/observability/metrics.md).
  4. Query metrics — QPS, p50/p95/p99 latencies, error rate, slow-query top-N (mirrors the existing banyandb_* metrics).
  5. Recent events / alerts — last N warnings/errors from BanyanDB (if surfaced via API) and any active TopN pipeline anomalies.
  6. Trace pipeline status — if Trace Pipeline (per #13634) is enabled, surface its stage/throughput.

Tasks

  1. Research — enumerate the BanyanDB HTTP endpoints and metrics that can power each Monitor section; identify gaps that require new backend API.
  2. Design doc — proposed layout under canopy/docs/monitor-design.md; data-fetching strategy (BFF proxy + caching vs. direct from SPA); refresh interval; empty/error/loading states.
  3. PoC — implement the page shell with Cluster overview + Storage metrics end-to-end (server proxy + web page) using existing BanyanDB endpoints; stub the other sections behind a feature flag.
  4. Tests — Vitest tests for new BFF proxy routes; component tests for the page; e2e smoke under canopy/e2e/.
  5. Docs — update canopy/README.md (sidebar change) and add canopy/docs/monitor-design.md.

Acceptance Criteria

  • New /monitor route accessible from the sidebar.
  • Cluster overview + storage metrics render real data from a running BanyanDB.
  • Loading / empty / error states handled.
  • Bounded refresh interval (default 10s, configurable).
  • Role enforcement: admin only by default (configurable to allow readonly).
  • Unit + e2e tests pass.
  • Docs updated.

Out of Scope

  • Custom alerting rules / notification channels.
  • Long-term metrics storage (rely on Prometheus).
  • Replacing the existing SkyWalking OAP observability dashboards — this page is a lightweight in-product view, not a Grafana replacement.
Lingua principale
Java
Stelle
25k
Fork
6.6k
Merge medio
12h 28m
PR unite (30g)
31

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 apache/skywalking

Tutte le issue di apache/skywalking

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.