How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/beclab/olares --skill olares-dashboardBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
dashboard (overview + applications, AI-agent first)
Shared front door: load `../olares-shared/SKILL.md` for suite routing, active-profile selection, platform entry points, and the auth proceed/stop gate. Load its auth reference only when login, profile switching, token storage, or auth recovery is actually needed.
Use olares-cli dashboard <verb> --help for syntax.
When to use
- Read CPU, memory, disk, network, pod, fan, or GPU metrics.
- Rank applications/workloads by resource use.
- Observe dashboard metrics over time or consume their stable JSON envelopes.
Mental model: dashboard answers "what's the resource usage and health". For inventory and lifecycle, route elsewhere. When the metrics reveal a problem (resource pressure, an app that's running but slow/unreachable), hand off to `../olares-doctor/SKILL.md` for root-cause diagnosis.Fast paths
| Task | Read | First command |
|---|---|---|
| See the machine's current load | this file | olares-cli dashboard overview -o json |
| Find which app is using the resources | this file | olares-cli dashboard applications -o json |
| Read one metric and know what it means | overview section meanings | olares-cli dashboard overview memory -o json |
| Decide whether an empty answer is a failure | envelope and empty states | olares-cli dashboard overview gpu -o json, then read meta.empty_reason |
Watching over time is not a fast path — watch, windows, NDJSON is a read of its own, and observing a metric is never the first thing to do with it.
Verb index
| Verb | Purpose | Read when triggered | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
applications (apps) | Workload-grain resource table | Rows are workloads, not apps, so one app can occupy several; joins overview ranking on (app, namespace) | |||||||||
overview | Physical, user, and ranking sections | overview section meanings; envelope and empty states | |||||||||
| `overview cpu | memory | disk | pods | network | fan | gpu | physical | user | ranking` | One section | overview section meanings; envelope and capability gates |
schema | Served JSON schemas | The one place the CLI describes an output shape without being run; read it instead of sampling a live response | |||||||||
| any metric with watch/window intent | Repeated snapshots / historical window | watch, windows, NDJSON |
Envelope and capability semantics
- Pin automation to
kind,raw, andmeta.empty_reason, not table labels. - No hardware, no integration, or a capability gate is usually an
exit 0empty envelope, not a command failure. - Aggregate verbs (
overview,overview disk|fan|gpu) exit non-zero only when every section carriesmeta.error; a partly degraded envelope is stillexit 0real data. The envelope reaches stdout either way, so read the per-section error rather than treating the exit code as the whole story. - A whole-instance outage surfaces as
HTTP 530on every section — the Olares is unreachable, so confirm it is online before diagnosing dashboard itself. - Fan is meaningful only on Olares One. Stop probing after the device gate says it is unavailable.
- A hidden GPU sidebar for a non-admin profile is advisory if data is still returned.
vgpu_unavailableis transient evidence, not proof that the device has no GPU.
Watch and diagnosis
- Watch emits repeated snapshots; JSON mode is NDJSON. Ctrl-C ends observation, not any workload.
- A watch aborts after repeated iteration failures. Separate transient metric collection failure from actual resource pressure.
- Choose either a relative or absolute time window based on the user's question; do not combine them.
- Dashboard locates pressure; it does not explain pod scheduling, crashes, image pulls, or entrance failures. Route those to
olares-doctor.
Safety and escalation
- Dashboard is read-only, but cross-user metrics require platform-admin authority. Do not switch profiles or broaden the target user without approval.
- Do not report an empty integration envelope as "healthy" or "zero usage"; preserve its empty reason.
- Stop and escalate persistent upstream metric errors after a bounded retry, including the affected section and time window.
