Skip to content
OpenRelay is in early access, and the /v1 API is stable. New capabilities ship in the changelog.
CLICommands

orl vms metrics get

GPU utilization, memory, power and temperature for a pod (unavailable on a VM's passthrough GPUs), part of the orl CLI for OpenRelay GPU VMs, pods, batches…

orl vms metrics get <id>

Returns utilization, memory, power and temperature time series for each of a pod's GPUs over the selected range, sampled on the host that runs the pod. The telemetry is host-side (nvidia-smi on NVIDIA hosts, amd-smi on AMD), sampled on the node that runs the pod and returned as one continuous time grid. Every series and every GPU in a response shares that grid: the value at index i of any values array was measured at start plus i times stepSeconds, and a null means the node reported no sample at that point. The window ends now and covers only the periods this pod actually held the GPUs it is reported against, so a card that ran another customer's pod earlier never contributes a sample here. A GPU attached to a VM is passed through to the guest, so the host cannot read it. That case answers 200 with an accelerator status of unavailable and an empty gpus list rather than an error, and so do a pod that has not started yet, a pod that was not running in the selected range, and a metrics store that cannot be reached: the accelerator object is the answer, and the client renders its detail sentence. A host that stopped reporting while the pod is still running answers degraded with the history up to the last sample still attached. This operation is exposed as an agent tool by default, in the same class as a pod's burn rate: "how busy were my GPUs" is a read-only question about a resource the caller already owns.

Flags

FlagTypeRequired
--range1h, 6h, 24h, 7dnoLength of the window ending now. A longer range is returned at a coarser step, so the number of points stays bounded.

This wraps the getVmMetrics API operation.

On this page