Version: 0.71.0This documentation is for Spitfire 0.71.0.
The System page
The System page (installation admin; Infrastructure → System) shows the health of everything the Towers watch on one screen. The numbers come from the continuous metrics the Towers bring in; installing a Tower, connecting a Collector and turning metrics on are on Tower and continuous metrics. The page refreshes every 30 seconds.
The summary at the top
- Towers connected: Towers that reached the controller in the last 90 seconds / Towers not revoked.
- Servers, Databases, Services: how many sources send metrics.
- Server CPU guard: whether a test's guard can take a server CPU limit (the monitoring events module in the license). See below.
When keeping continuous metrics is off, a warning shows at the top; no new readings come in.
Towers
For each Tower: its zone, status (connected or silent), when it was last seen, how many sources send to it, how many batches wait in its buffer while the controller is out of reach, and its version.
Servers, databases, services
Each source shows its last day in hourly summaries:
| Table | Columns |
|---|---|
| Servers | CPU now, 24-hour average / peak, the hourly average of the last 24 hours (a small chart), memory, Tower, last reading |
| Databases | Connections now / the connection maximum, peak in 24 hours, hourly chart, Tower, last reading |
| Services | Series, Tower, last reading |
The Status column:
- fine: the last reading is under the limits.
- busy: a server's CPU at 85% or more, or a database's connections at 80% of its maximum or more.
- no readings: nothing came from the source for 5 minutes (the Collector may have stopped or cannot reach its Tower).
- no data: the source sends readings, but no CPU or connection metric.
CPU is worked out from the Collector's system.cpu.utilization (the idle share averaged over the
CPUs); the Collector config Spitfire writes turns it on. If you connected your own Collector, turn
on system.cpu.utilization in the cpu metrics of its hostmetrics receiver; otherwise the CPU
column stays empty.
With the guard: a server CPU limit
Write a Server CPU above limit on a test's guard (Thresholds and guard tab → Guard → Custom) and during the run the guard also reads the CPU of the servers on this page: when a server goes over the limit the load steps down, past the stop limit the run stops. Write the servers to read in Servers the CPU limit reads, comma-separated (by their names here); leave it empty to read every server that sends metrics. Details: Guard: server CPU limit.