statistics
statistics
Radiator keeps runtime counters, gauges, and histograms in memory while it runs. Radiator UI uses the local history to show traffic, errors, backend behavior, and latency.
For real-time production monitoring and long-term retention, see the Prometheus and OpenMetrics scraping article.
Default local history
Without a statistics block, new counters, gauges, and histograms keep
2016 local history samples. This is 7 days at 5-minute intervals.
Most installations should use the defaults.
The example below sets one day of local history at 1-minute intervals.
statistics {
defaults {
samples 1440;
interval 60s;
}
}
Namespaces
Counters and histograms use the same namespaces as log entries. A namespace is a path such as:
server::radius-udp::AUTH_SERVER::policy::RADIUS::handler::PAP_HANDLER
backend::SQL::USERS_DB
custom::app::requests
See Namespaces for the full namespace hierarchy and for examples from logging and counters.
Configuration
You usually do not need a statistics block.
Add one only when the local Radiator UI history needs a different window for a clear operational reason. The block changes only local history.
The statistics block can contain:
| Block or statement | Where | Description |
|---|---|---|
defaults { ... } | statistics | Fallback history settings for existing and new metrics |
counter /pattern/ { ... } | statistics | History settings for counters whose namespace matches the regex |
histogram /pattern/ { ... } | statistics | History settings for histograms whose namespace matches the regex |
samples N; | defaults, counter, histogram | Number of local history samples to keep |
interval DURATION; | defaults, counter, histogram | Time between local history samples |
interval accepts duration units such as ms, s, m, h, d, and
w. See Duration Units for the full
syntax.
Example
statistics {
# Keep the built-in local history for most metrics.
defaults {
samples 2016;
interval 5m;
}
# Keep a shorter local chart for high-volume custom counters.
counter /^custom::loadtest::/ {
samples 288;
interval 5m;
}
# Keep a higher-resolution local chart while investigating SQL latency.
histogram /^backend::SQL::.*::latency$/ {
samples 720;
interval 30s;
}
}
Pattern matching
Patterns use Rust regex syntax and are written as /pattern/ or
/pattern/flags. Supported flags are i, m, and s.
Without ^ and $, a regex can match anywhere in the namespace path.
Use anchors when the rule should match a specific path shape.
Examples:
| Pattern | Matches |
|---|---|
/handler::/ | Any namespace that contains handler:: |
/::errors$/ | Any namespace that ends with ::errors |
/^backend::SQL::.*::latency$/ | SQL backend latency histograms |
/.*::auth.*/i | Any namespace that contains auth, case-insensitive |
Counters and histograms are created automatically when Radiator uses them. Use regex rules only when you want to change local history settings.
Regex rules are checked in the order they appear in the file. Put specific regex rules before broad regex rules.
Process CPU and memory
Radiator records process CPU and memory metrics in the system::os
namespace:
| Metric | Description |
|---|---|
ProcessCpuMillis | CPU time used by the process, in milliseconds. Updated once per minute. |
ProcessMemoryBytes | Process memory use (resident set size) in bytes. Updated once per minute. |
ProcessCpuPercentMin | Lowest 5-second CPU sample in each statistics interval, in percent. |
ProcessCpuPercentMax | Highest 5-second CPU sample in each statistics interval, in percent. |
ProcessMemoryBytesMin | Lowest 5-second memory sample in each statistics interval, in bytes. |
ProcessMemoryBytesMax | Highest 5-second memory sample in each statistics interval, in bytes. |
Radiator samples process CPU and memory every 5 seconds. Each CPU sample is
the CPU utilization since the previous sample, where 100% equals one fully
used CPU core. The minimum and maximum metrics keep the lowest and highest
sample of each statistics interval, so short spikes and dips are kept
although ProcessCpuMillis and ProcessMemoryBytes change only once per
minute. Their current value is the latest sample.
When Radiator UI requests fewer history points than are stored, each returned point of a minimum or maximum metric is the lowest or highest value of the intervals that the point covers. Spikes and dips therefore remain visible in the 24-hour and 7-day views. Each returned point of a histogram, such as pipeline latency, keeps the highest value of each percentile in the same way.
The System card in Radiator UI uses these metrics as follows:
- The CPU reading is the latest 5-second sample.
- Peak is the highest 5-second sample in the selected time range.
- Average is the average of the per-interval CPU and memory values.
- The CPU and memory charts show a shaded band with dashed edges between each interval's lowest and highest sample around the average line.
The counter details charts for ProcessCpuMillis and ProcessMemoryBytes
show the same band. Their tooltips show the minimum, average, and maximum.
Management API history
Radiator UI reads local history through the statistics API. These endpoints are useful for the UI and for short troubleshooting scripts:
GET /api/v1/statistics/counter/time-series/{namespace}
GET /api/v1/statistics/counters/time-series/{namespace}
GET /api/v1/statistics/histogram/time-series/{namespace}
The namespace is written as path components in these URLs. For example,
server::radius-udp::AUTH_SERVER becomes
server/radius-udp/AUTH_SERVER.