Every enrolled node reports what its host is doing — CPU, memory, disk, network, filesystems — and every ORC8R server reports on itself. This page says what is collected, how long it is kept, and how to read what you see, including the places where the honest answer is "unavailable".
Where to look
A node's Metrics tab shows that host: /nodes/{node}/metrics. It is one host, deliberately — there is no node picker and no comparison against another node, because a chart that quietly mixes two machines is worse than two charts. Below the host charts, an Applications section shows what the programs on that node reported about themselves. Application metrics from agents are not collected yet, so on most nodes that section says so rather than showing a zero.
A pool's Metrics tab is the fleet view: totals across the pool, the spread across its nodes (minimum, p10, median, p90, maximum of the per-node values at each instant — a percentile across machines, never a percentile of percentiles), a table of every node at the instant under the pointer — worst first, each name a link into that node's own Metrics tab — and the applications on them added up. On the node tab, the CPU, disk and network charts draw the peak inside each window as a dashed line above the average, and the readout says both.
A server is a node too. Each one registers a node in the zone's zone pool, so a server's host numbers are on that node's Metrics tab, its orc-server process appears there as an application, and the zone pool's Metrics tab is where you look at all the servers together.
On that server's tab, request latency is a table rather than a chart: one row per route bucket, slowest mean first, with the requests, the errors, the slowest single request and the spread across the latency buckets on each row. The routes past the server's cap are folded into a row called other, which stays last however slow it reads.
The zone's Metrics tab is therefore about the pipeline rather than the measurements: the state of this server's store, how far behind the copies to the other servers are, whether a joining server is still cloning history — plus the retention editor and the Web analytics report.
All of them use the same period row — 1h 24h 7d 30d 1y. Selecting 1h starts live updates automatically, refreshing every 15 seconds while the page is visible and your pointer is not resting on a chart or a table. Every longer window is a fixed window: it stays where you put it until you select a period again. There is no separate Live/Pause button because the period is the control.
A node that has ended never reports again, so the hour before now would be empty for it. Its Metrics tab opens on its Lifetime instead — from its first connection to its end, with a little room either side — and says when it ended. Nothing on an ended node's tab is live, and every period counts back from the node's end rather than from now: 24h is the last day the node was alive. How much detail a short life keeps depends on how long ago it ended: within the minute summaries' lifetime its charts are drawn at one-minute resolution or finer, and after that only hourly summaries are left, so a node that lived for half an hour becomes a point or two per chart.
What is collected
Host-level only, in this release:
| Family | What it carries |
|---|---|
cpu | CPU time by mode (user, system, iowait, steal, idle, irq) and the number of cores |
mem | total, used, available, cached, buffers, swap |
load | 1/5/15-minute load averages and process counts |
psi | Linux pressure-stall information for CPU, memory and I/O |
disk | bytes and operations read and written, per whole block device |
net | bytes, packets, errors and drops, per interface |
fs | size, used, available and inodes, per mount point |
Apps are not measured. A chart never shows "what this app used" — that is a later feature, and inventing it from host numbers would be a guess.
Two arithmetic rules the charts obey, and you should expect from any export you build on them:
- CPU percentages are percentages of all cores. A four-core node pinned flat reads 100%, not 400%. The denominator is stated wherever the number is.
- Only mounts an operator provisioned are listed. Kernel interfaces (proc, sysfs, cgroups, nfsd…) are skipped by type, and the mounts systemd and the kernel make for their own use under
/run,/dev,/sysand/proc— a service's credential tmpfs, a user session's runtime directory — are skipped by path./runitself,/dev/shmand/tmpstay, because they do fill up. A read-only filesystem is skipped on either platform — a squashfs image, a share mountedro, the enrolment seed disk a Windows node boots with — because its usage cannot change, so charting it draws a flat line at whatever it held when it was sealed. - A disk is never added to its partitions. Only whole block devices are collected, precisely so that "all devices" is a sum that means something.
- The App data volume is listed under that name, not under a path. It is the volume holding the applications' state, and the one a restore point captures; the two platforms mount it in two different places — a directory under the agent's data dir on Linux, a folder mount with no drive letter on Windows — so a node's page leads its Filesystems card with it and calls it App data on both. The directories the agent shadows an application's declared exclusions with are not listed: their bytes are already counted on the volume they live on.
Counters (bytes, packets, CPU time) are shown as per-second rates, derived with reset detection: a counter that goes backwards because the machine or the driver restarted produces a marked point, never a negative spike.
Top processes
Alongside the continuous series, the agent scans the process table every ten seconds and keeps a bounded union of the largest CPU, resident-memory and disk-I/O consumers — by default the top five of each ranking, deduplicated to at most fifteen records per scan. Records carry the command, the executable name, the systemd unit where one is readable, the PID and the process start identity, so a recycled PID cannot join two unrelated executions.
This is evidence, not proof. Read it with three limits in mind:
- Absence means "not retained". A process missing from a window may have run and used plenty; it simply did not make that window's list. Each window shows how many processes were scanned and how many were retained.
- Short-lived processes can be missed entirely — a scan every ten seconds cannot see something that starts and exits between two scans.
- Coincidence is not cause. A backup job running while a build slowed down is a lead, not a verdict.
Top-process records have their own short retention, separate from the metric tiers, and they are not claimed to exist for the whole life of the coarse history.
Retention and resolution
History is kept at four resolutions, each summarised from the one before it:
| Tier | Default lifetime |
|---|---|
| Raw samples | 24 hours |
| One-minute summaries | 7 days |
| One-hour summaries | 365 days |
| One-day summaries | 1095 days |
A chart picks the finest tier that covers the window you asked for and still fits its point budget, and it tells you which one it used. Summaries keep the observed minimum and maximum alongside the correctly weighted average, so a spike inside a summarised window is still visible as a band — but when inside that window it happened is gone for good. Detail lost to summarisation cannot be recovered.
Raw retention doubles as the accepted lateness: an observation that arrives later than that is refused outright rather than triggering a rewrite of history, and the interval it belonged to is recorded as a gap.
Change these lifetimes in the zone's Metrics tab, under Retention. Each tier must outlive the one it is summarised from, and the editor refuses a combination that would ask a summary to be built from rows that have already expired. Storage pressure never silently shortens retention: when the store runs out of the room it was given, it refuses new data and says so, leaving acknowledged history alone.
Web analytics
The Web analytics subtab is what the zone's Metrics tab opens on. It counts active subjects per UTC day, in two populations that are reported side by side and are never added together:
- Anonymous visitors — browser profiles that loaded a page of this zone while signed out.
- Signed-in users — canonical ORC users, counted once however many sessions, browsers or servers they used.
Someone who browses signed out and then logs in is honestly in both on that day. Their sum is not a number of people, and the page does not print one.
Each population shows today, the last 7 days and the last 30 days. The weekly and monthly figures are unions of subjects over the trailing window, not sums of the daily counts — a visitor who comes back every day for a week is one weekly visitor, not seven. New means the subject's first day ever; everyone else that day is returning. First days are kept even after the day-by-day memberships behind them have expired, so a visitor who has been away for a year comes back as returning rather than as new.
What it cannot tell you, and says so on the page:
- An anonymous visitor is one browser profile that keeps its cookie. Clearing cookies, private browsing or a second device is another visitor. The identifier is a random value this deployment issues in a first-party cookie; nothing is fingerprinted, and IP addresses are never used as identities.
- A visit to exactly one page is not counted. The first response establishes the cookie and the count starts from the next one, which is the safe direction to err in: a client that does not keep cookies would otherwise look like a new visitor on every request.
- Automated traffic is excluded on a small fixed list of user agents, and a request with no user agent at all is treated as automation. This is best effort. These are observed browsers, not a count of humans.
- Each day states its coverage:
exact,truncatedwhere a server had to stop recording that day, orpartialwhere the retained history does not reach back across the whole trailing window.
Nothing identifying is stored. Before a visitor id or a user id is recorded it is put through a keyed hash under a key that belongs to this zone and never leaves it, and only sixteen bytes of the result are kept — enough to recognise the same subject tomorrow, and nothing that can be turned back into who it was. Every server hashes the same subject to the same value, which is what makes the zone's count a union across servers rather than a sum of per-server counts. Reading the report needs the ReadZone permission; being counted grants no access to the counts.
Under the counts, Recent sign-ins names the last 20 people to sign in and when. Those are users out of the same directory the Users tab lists — not the hashed subjects the counts above are made of, which cannot be turned back into a name.
These memberships are not sampled metrics and do not follow the tiers below: they have their own lifetime, 400 days by default, and the answer names the definition version it was computed under so a later change to the definitions is a new series rather than a silent rewrite.
Signup-to-activation funnels, retention cohorts, feature usage and the cloud-only commercial reports are not part of this release.
Every node is visible from every server
Each server collects itself and hands a copy of every acknowledged batch to every other server, so any node's charts open on whichever server you happened to reach. Reads never ask another server anything — the answer always comes off the disk you are talking to, so one server being down never breaks a page, it only stops that server's own rows getting fresher.
Adding numbers across a fleet only means something for some of them, and the pool tab keeps the two apart. Totals are for counts of events — requests, errors, bytes, latency buckets — which add up because they are counts. Spread is for levels: the median node's memory and the tails tell you something, the sum of every node's CPU percentage tells you nothing. CPU is the one level that does add: the kernel counts CPU time in seconds, one core flat out is one CPU second per second, and the pool's CPU card adds those up and divides by every core in the pool — "3.4 of 24 cores" — so its axis is a share of the fleet's capacity, exactly as a node's card is a share of its cores. Latency across a pool is the sum of the nodes' buckets, which is the whole reason the distribution is stored as buckets rather than as percentiles.
What an acknowledgment means
An acknowledgment means the batch reached the disk of the server that received it. After that, the server copies the batch to every other server in the zone, so any node's charts open on whichever server you reach and a server that is lost forever takes only the batches it had not yet copied. The copies are best effort: a server under pressure sheds its oldest copies into a gap marker rather than fall behind, and the zone's Metrics → Health page shows copy lag per peer. A server that joins with an empty store clones a live peer's store first and serves from its first flush. Anywhere the pages or the API say local_only, this is what they mean: one disk acknowledges, the rest follow.
Unavailable is not zero
Wherever a measurement does not exist, ORC8R shows that it does not exist:
- A family the host cannot collect — pressure-stall information on a kernel without it, swap on a host with none — is reported with the reason, not as a flat line at zero.
- A gap in collection — an agent restart, a network outage, a spool that overflowed — is drawn as a break in the line with the recorded span shaded, not bridged by a straight segment.
- A node that runs inside a server — a core-provider virtual node hosted on one — shares that server's machine, so its Metrics tab says so rather than showing you the server's numbers. A server's own node is the opposite case: it is that machine, and it reports it.
- A family the operating system has no equivalent of is reported as unsupported for as long as that node runs that system. A Windows node has no pressure-stall information and no load averages, so
psisays "not available on this platform" and theloadchart shows the process count with the averages blank; it also reports no swap usage, no per-device busy time and no inode counts, because Windows publishes no honest equivalent of any of the three. - Application metrics from agents are not collected yet, so the Applications section of an ordinary node's tab says exactly that instead of showing a plausible zero.
- A node that reported nothing in a window is left out of a pool's aggregate rather than counted as a zero, and every pooled point says how many nodes were behind it.
If a chart looks empty, read the note under it before concluding the machine was idle.
Reading it from the API
Every surface on these pages is a documented JSON endpoint:
| Endpoint | Purpose |
|---|---|
GET /api/nodes/{node}/metrics/range | one family's series for one node, or several in one round trip (family=cpu,mem,disk) |
GET /api/nodes/{node}/metrics/devices | the devices that node reports |
GET /api/nodes/{node}/metrics/contributors | retained top-process records |
GET /api/pools/{pool}/metrics/range | one family across a pool: mode=totals, mode=distribution or mode=nodes |
Reading a node's metrics needs the node-statistics permission in that node's project, and a pool's needs it in the pool's project alongside permission to read the pool. History survives the node: after a node is deleted, its retained history stays readable to whoever could read it while it existed.