---
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, 定期巡检/周期巡检/哨兵巡检, 新建或调整 Web sentinel YAML, monitor/minitor requests, 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`；遇到对应工作时同时加载那些技能。

当用户提到 Web 哨兵、`web-probe sentinel`、`monitor.pikapython.com`、定期/周期巡检、新建巡检、巡检 dashboard/report/status，或误写为 `minitor` 时，必须加载本技能。

## 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`。
- HWLAB Web 哨兵 cadence 调度必须落在目标 node/lane 的 k3s CronJob/GitOps 中；不要用本机或远端 systemd timer 承载周期巡检。systemd 只可用于明确标注的历史/非 k3s legacy 排查。
- 诊断可用 `curl` 或一次性 `web-probe script` 采证，但重复 dashboard 验证必须沉淀为受控 `web-probe sentinel dashboard verify|screenshot` 或等价入口。
- `web-probe sentinel dashboard screenshot` 必须作为远程浏览器截图入口使用，PNG 默认下载到调用者 `/tmp`；issue/PR 证据引用 `localPath`、`sha256`、HTTP status、DOM 摘要和 overflow 结果。
- monitor-web 的“监测项”默认必须跟随选中 run；曲线点、运行详情和监测项摘要必须区分类型数与样本数，历史聚合只能作为明确标注的历史口径展示。

## 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
bun scripts/cli.ts web-probe sentinel control-plane trigger-current --node D601 --lane v03 --sentinel <id> --confirm
trans D601:k3s kubectl -n <namespace> get cronjob -l app.kubernetes.io/component=cadence-scheduler
trans D601:k3s kubectl -n <namespace> create job --from=cronjob/<quick-verify-cronjob> <manual-job-name>
```

For k3s cadence validation, first use the controlled control-plane status/trigger commands, then inspect the rendered CronJob in the target k3s namespace. Manual `kubectl create job --from=cronjob/...` is validation evidence only; persistent cadence changes must be made through YAML/GitOps and redeployed.

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.
5. Separate timing alerts and blockers: YAML-configured elapsed/timeout warnings are non-blocking unless the turn fails to complete, breaks Code Agent multi-round continuity, loses samples, or makes auth/submit/report unavailable.
6. Separate check type counts and sample counts: `findingCount`/`findingTypeCount` is a type count, while `severityCounts` and finding `count` are sample counts.

## 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.
