Radiator Server Documentation — v10.34.2

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 statementWhereDescription
defaults { ... }statisticsFallback history settings for existing and new metrics
counter /pattern/ { ... }statisticsHistory settings for counters whose namespace matches the regex
histogram /pattern/ { ... }statisticsHistory settings for histograms whose namespace matches the regex
samples N;defaults, counter, histogramNumber of local history samples to keep
interval DURATION;defaults, counter, histogramTime 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:

PatternMatches
/handler::/Any namespace that contains handler::
/::errors$/Any namespace that ends with ::errors
/^backend::SQL::.*::latency$/SQL backend latency histograms
/.*::auth.*/iAny 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:

MetricDescription
ProcessCpuMillisCPU time used by the process, in milliseconds. Updated once per minute.
ProcessMemoryBytesProcess memory use (resident set size) in bytes. Updated once per minute.
ProcessCpuPercentMinLowest 5-second CPU sample in each statistics interval, in percent.
ProcessCpuPercentMaxHighest 5-second CPU sample in each statistics interval, in percent.
ProcessMemoryBytesMinLowest 5-second memory sample in each statistics interval, in bytes.
ProcessMemoryBytesMaxHighest 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.