fix(web-probe): recover monitor dashboard render
This commit is contained in:
Codex
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: unidesk-monitor
|
||||
description: UniDesk monitoring and Web sentinel operations. Use when working on monitor.pikapython.com, HWLAB Web哨兵, web-probe sentinel status/report/dashboard, Prometheus/OTel monitoring, multi-sentinel runtime visibility, or monitoring-related issue triage and rollout evidence.
|
||||
---
|
||||
|
||||
# UniDesk Monitor
|
||||
|
||||
本技能是 UniDesk 监控与 Web 哨兵操作面的入口。它不替代 `$unidesk-webdev`、`$unidesk-cicd`、`$unidesk-ymalops`、`$unidesk-gh` 或 `$unidesk-otel`；遇到对应工作时同时加载那些技能。
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Web 哨兵只 wrap 现有 `web-probe observe start/status/command/collect/analyze`，不得新增第二套 Playwright runner、采样器、报告器或 analyzer。
|
||||
- 哨兵观察对象是 HWLAB Web 用户入口和业务 E2E 链路；不是让一个哨兵观察另一个哨兵。
|
||||
- YAML 是 source of truth。node/lane、sentinel id、Deployment、Service、PVC、route prefix、cadence、Secret sourceRef、dashboard public URL 和 report views 都必须从 YAML/configRef 进入受控 CLI。
|
||||
- 正式读写 GitHub issue/PR 走 `$unidesk-gh`；部署、Argo、git-mirror、PipelineRun、runtime 状态走 `$unidesk-cicd` 和受控 CLI；YAML 正规化走 `$unidesk-ymalops`。
|
||||
- 诊断可用 `curl` 或一次性 `web-probe script` 采证，但重复 dashboard 验证必须沉淀为受控 `web-probe sentinel dashboard verify|screenshot` 或等价入口。
|
||||
|
||||
## Quick Commands
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03
|
||||
bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel <id>
|
||||
bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel <id>
|
||||
bun scripts/cli.ts web-probe sentinel validate --node D601 --lane v03 --sentinel <id>
|
||||
bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel <id>
|
||||
bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel <id>
|
||||
bun scripts/cli.ts web-probe sentinel report --node D601 --lane v03 --sentinel <id> --latest --view summary
|
||||
```
|
||||
|
||||
For long Workbench/user-path evidence, use the normal Web probe surface:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe observe start --node D601 --lane v03 --target-path /workbench
|
||||
bun scripts/cli.ts web-probe observe command <observerId> --type <command>
|
||||
bun scripts/cli.ts web-probe observe collect <observerId> --view <view>
|
||||
bun scripts/cli.ts web-probe observe analyze <observerId>
|
||||
```
|
||||
|
||||
## Triage Shape
|
||||
|
||||
1. Separate shell/API/render: check public HTML/CSS/JS, `/api/overview`, `/api/runs`, then browser console/DOM render evidence.
|
||||
2. Separate runner and web: runner Pod/PVC/API/report health is not the same as monitor-web rendering health.
|
||||
3. Separate service rollout and target validation: Argo/runtime green only proves哨兵自身可用；HWLAB business recovery must come from observe/analyze report.
|
||||
4. Separate single-sentinel and multi-sentinel: root registry shows all sentinels; each runner owns independent Pod/PVC/Service/report. A single monitor-web aggregation layer is a separate responsibility.
|
||||
|
||||
## Architecture Preference
|
||||
|
||||
Prefer Kubernetes-native discovery and isolation before inventing a custom control plane:
|
||||
|
||||
- Labels/selectors identify sentinel runners.
|
||||
- ClusterIP Services expose runner APIs.
|
||||
- EndpointSlice or Service list/watch lets a monitor-web discover runner endpoints.
|
||||
- PVC per runner preserves local report index.
|
||||
- Deployment per runner is appropriate for long-lived observe sessions; CronJob is appropriate only for short stateless periodic probes.
|
||||
- ConfigMap/Secret carry non-secret config and sourceRef-derived runtime material; output remains redacted.
|
||||
- Prometheus/ServiceMonitor may scrape `/metrics` when the namespace already has that stack, but report drill-down should stay on runner HTTP APIs or a declared shared store.
|
||||
|
||||
Read `references/full.md` for the current D601/v03 Web 哨兵 command matrix, dashboard triage checklist, and multi-sentinel target architecture.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "UniDesk Monitor"
|
||||
short_description: "UniDesk monitoring and Web sentinel operations"
|
||||
default_prompt: "Use $unidesk-monitor to inspect HWLAB monitoring and Web sentinel status."
|
||||
@@ -0,0 +1,107 @@
|
||||
# UniDesk Monitor Reference
|
||||
|
||||
## Current Web Sentinel Surface
|
||||
|
||||
Primary registry:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03
|
||||
```
|
||||
|
||||
Known D601/v03 sentinel ids:
|
||||
|
||||
- `workbench-dsflash-go-tool-call-10x`
|
||||
- `workbench-auth-session-switch-2users`
|
||||
|
||||
Per-sentinel drill-down:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
|
||||
bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
|
||||
bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
|
||||
bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
|
||||
```
|
||||
|
||||
Dashboard render and screenshot verification:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
|
||||
bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
|
||||
bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
|
||||
bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
|
||||
```
|
||||
|
||||
Report drill-down:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts web-probe sentinel report --node D601 --lane v03 --sentinel <id> --latest --view summary
|
||||
bun scripts/cli.ts web-probe sentinel report --node D601 --lane v03 --sentinel <id> --latest --view findings
|
||||
bun scripts/cli.ts web-probe sentinel report --node D601 --lane v03 --sentinel <id> --run <runId> --view trace-frame
|
||||
```
|
||||
|
||||
Public dashboard paths:
|
||||
|
||||
- `https://monitor.pikapython.com/`
|
||||
- `https://monitor.pikapython.com/sentinels/workbench-auth-session-switch-2users/`
|
||||
|
||||
Direct API probes for shell/API/render separation:
|
||||
|
||||
```bash
|
||||
curl -sS -D - https://monitor.pikapython.com/ -o /tmp/monitor-root.html
|
||||
curl -sS -D - https://monitor.pikapython.com/api/overview -o /tmp/monitor-overview.json
|
||||
curl -sS -D - https://monitor.pikapython.com/api/runs -o /tmp/monitor-runs.json
|
||||
curl -sS -D - https://monitor.pikapython.com/sentinels/workbench-auth-session-switch-2users/api/overview -o /tmp/monitor-auth-overview.json
|
||||
```
|
||||
|
||||
Use `web-probe script` with explicit `page.goto("https://monitor.pikapython.com/...")` only as one-off evidence until a dedicated dashboard verify/screenshot command exists.
|
||||
|
||||
## YAML Ownership
|
||||
|
||||
Root registry:
|
||||
|
||||
- `config/hwlab-node-lanes.yaml#lanes.v03.targets.D601.observability.webProbe.sentinels`
|
||||
|
||||
Per-sentinel management YAML:
|
||||
|
||||
- `config/hwlab-web-probe-sentinels/d601-v03/workbench-dsflash-go-tool-call-10x.yaml#sentinel`
|
||||
- `config/hwlab-web-probe-sentinels/d601-v03/workbench-auth-session-switch-2users.yaml#sentinel`
|
||||
|
||||
Typical config refs:
|
||||
|
||||
- runtime: Deployment, Service, PVC, state root, SQLite, scheduler interval.
|
||||
- workflow/scenarios: observed route, cadence, command sequence, prompt/report refs.
|
||||
- promptSet: synthetic prompt ids and redaction policy.
|
||||
- reportViews: default and drill-down views.
|
||||
- publicExposure: `monitor.pikapython.com`, FRP, Caddy route prefix.
|
||||
- cicd: source, image, GitOps, Argo and target validation.
|
||||
- secrets: sourceRef and targetKey only; no values in stdout or issue bodies.
|
||||
|
||||
## Dashboard Triage Checklist
|
||||
|
||||
Classify a monitor page issue in this order:
|
||||
|
||||
1. HTML shell loads: root status, asset links, `data-sentinel-id`, `data-base-path`, contract version.
|
||||
2. API returns data: `/api/overview`, `/api/runs`, `/api/findings`, selected `/api/runs/{id}`.
|
||||
3. Browser render executes: page errors, console errors, DOM rows, status summary, findings count.
|
||||
4. Runtime service health: `/api/health`, `/metrics`, scheduler heartbeat, SQLite/PVC write probe.
|
||||
5. Control-plane health: source, registry image, git-mirror, GitOps, Argo, Deployment/Service/PVC.
|
||||
|
||||
Do not treat public root/CSS/JS 200 as dashboard success. Browser console and DOM render evidence are required.
|
||||
|
||||
## Multi-Sentinel Target Architecture
|
||||
|
||||
Current implementation has independent sentinel runner services, but each runner still serves its own dashboard. The target architecture should split:
|
||||
|
||||
- `sentinel-runner`: one Deployment/PVC/Service per sentinel id; owns scheduler, observe wrapper, SQLite/report index, `/api/report`, `/api/overview`, `/metrics`.
|
||||
- `monitor-web`: one Deployment/Service/public route per workspace or node/lane; owns dashboard shell, multi-sentinel registry view, aggregation/proxy APIs and public HTTPS exposure.
|
||||
|
||||
Recommended Kubernetes-native mechanisms:
|
||||
|
||||
- Label all runner Services and Pods with `unidesk.ai/web-probe-sentinel-id`, node, lane, workspace and component.
|
||||
- Let monitor-web discover runners using Kubernetes Services or EndpointSlices with label selectors.
|
||||
- Keep each runner Service `ClusterIP`; expose only monitor-web through declared `publicExposure`.
|
||||
- Use runner Service DNS or Kubernetes discovery for aggregation, not hard-coded route prefixes.
|
||||
- Keep per-runner PVCs for local report history unless a shared store is explicitly specified.
|
||||
- Use CronJob only for short, stateless periodic probes. Keep Deployment for long-lived browser observers, maintenance API and progressive reports.
|
||||
|
||||
This keeps runner isolation while giving users one monitor page for all sentinels in a workspace.
|
||||
Reference in New Issue
Block a user