Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature] Add Monitor page to Canopy

未关闭
#13,992 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@pallavithegod 已经在做这个了。

开始于 2026年10月15日。

  • #1414 来自 @pallavithegod —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
技术栈
prometheus

调研方向

首先查看 docs/operation/observability/metrics.md,并列出拟议各部分所需的 BanyanDB HTTP 端点和指标。在 canopy/docs/monitor-design.md 中记录布局和数据获取方式,然后检查现有的 Canopy 侧边栏以及 canopy/e2e/ 下的测试位置。完成标准是形成一份范围明确的设计与实现计划,涵盖 /monitor 路由、加载/错误状态、刷新行为、角色强制执行和测试。

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Java
星标
25k
派生
6.6k
平均合并
12 小时 28 分钟
30 天内合并 PR
31

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/skywalking 的其他 Issue

查看 apache/skywalking 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。