mcpField
O
olares-dashboard

olares-dashboard

github.com/beclabCloud & DevOps5.3k200 installsUpdated today
Repository

About olares-dashboard

olares-dashboard is a skill for reading Olares resource and workload metrics with `olares-cli dashboard`. It provides structured JSON output and time-based observation, while directing root-cause diagnosis to the separate `olares-doctor` skill.

Key features

  1. 01Read CPU, memory, disk, and network metrics
  2. 02Inspect pod, fan, and GPU data
  3. 03Rank applications by resource use
  4. 04Watch metrics over time
  5. 05Read served JSON schemas and empty-state reasons
  6. 06Route problems to root-cause diagnosis

Use cases

  1. 01Check current machine resource load
  2. 02Find workloads using the most resources
  3. 03Observe a metric across a time window
  4. 04Determine whether missing metrics reflect a capability limit

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/beclab/olares --skill olares-dashboard

After installing, type/olares-dashboardin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
olares-dashboard-envelope.md
olares-dashboard-overview.md
olares-dashboard-watch.md

Details

From the project README

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

TaskReadFirst command
See the machine's current loadthis fileolares-cli dashboard overview -o json
Find which app is using the resourcesthis fileolares-cli dashboard applications -o json
Read one metric and know what it meansoverview section meaningsolares-cli dashboard overview memory -o json
Decide whether an empty answer is a failureenvelope and empty statesolares-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

VerbPurposeRead when triggered
applications (apps)Workload-grain resource tableRows are workloads, not apps, so one app can occupy several; joins overview ranking on (app, namespace)
overviewPhysical, user, and ranking sectionsoverview section meanings; envelope and empty states
`overview cpumemorydisk
schemaServed JSON schemasThe one place the CLI describes an output shape without being run; read it instead of sampling a live response
any metric with watch/window intentRepeated snapshots / historical windowwatch, windows, NDJSON

Envelope and capability semantics

  • Pin automation to kind, raw, and meta.empty_reason, not table labels.
  • No hardware, no integration, or a capability gate is usually an exit 0 empty envelope, not a command failure.
  • Aggregate verbs (overview, overview disk|fan|gpu) exit non-zero only when every section carries meta.error; a partly degraded envelope is still exit 0 real 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 530 on 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_unavailable is 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.

Comments

Markdown supported