Skip to content
How to buy Partners Support Start evaluation
NETAVO·BNG
Docs Start evaluation
Skip to content

Subscriber throughput history#

The appliance keeps the last 24 hours of download and upload rate for every subscriber. It is what the graph on a session's page and the sparkline beside each row of the session list are drawn from, in the web UI and in the mobile app.

It exists for the support call: "it was slow last night", "it keeps dropping". The live chart on a session answers what a subscriber is doing now; this answers what they were doing — and whether they were connected at all — over the last day.

What is recorded#

Once a minute the appliance reads each session's traffic counters and records the average rate over that minute, in each direction.

Period Resolution What a point is
The last 2 hours 1 minute the average rate over that minute
The rest of the 24 hours 5 minutes the average of the bucket's minutes, and the highest of them (the peak)

Rates are stored rounded (to within a twentieth of a percent). This is an operational view, not usage data: nothing here is used for accounting, billing or quota, and accounting is unaffected by it.

It follows the subscriber, not the session#

A subscriber who reconnects gets a new session; their history carries on. It is kept under the subscriber's identity, shown as Subscriber key on the session page — the first of these that applies:

Key Used when
svc:<id> your AAA server returned a service id for the subscriber
user:<username> there is a username (compared without regard to case)
cid:<hex> an IPoE subscriber with no username, identified by the DHCP Option-82 circuit-id
port:<port>:<s-vlan>:<vlan> nothing else identifies them: the access circuit itself

Two sessions with the same key at the same time — a subscriber with two lines under one service id — are added together.

Reading the graph#

A gap means no data; zero means idle. Where the line is broken the subscriber was not connected, or the appliance was not sampling (it was restarting). Where the line runs along the bottom the subscriber was connected and passing nothing. They are deliberately different.

Expect a gap of a minute or two in these cases, none of which is a fault:

  • when a session first comes up, and after a reconnect — the first reading only establishes a starting point;
  • across a restart of the control plane, for as long as it was down plus up to two minutes;
  • across a restart of the data plane that did not preserve its counters.

The appliance never shows a rate it cannot stand behind: a counter that went backwards, or a reading it cannot pair with the one before, produces a gap rather than a spike.

The session list's sparkline is the last two hours in two-minute steps, as two lines in the colours of the graph on the session's page: download and upload. Both are drawn against one scale — that row's larger peak — so the upload line is as small against the download line as the traffic was, and a row shows the shape of its subscriber's last two hours, not how rows compare. Hover over it for the two peaks.

Where it is kept#

On the appliance's disk, in /var/lib/netavo-bng/subscriber-history.db, so the history survives a restart, an upgrade and a reboot. It is written in batches every five minutes rather than continuously, to spare flash storage: about 10 KB a day per subscriber. A restart or upgrade writes what is outstanding first and loses nothing; a power loss loses at most the last five minutes.

Points older than 24 hours are removed as they age out, and a subscriber not seen for 24 hours is forgotten. The number of subscribers kept is capped (by default at the size of the session table plus a quarter); beyond it, the subscribers seen least recently are dropped first.

If the disk fills or the file is damaged the appliance carries on: the history stays available from memory, a warning is logged, and writing resumes by itself when it can. A damaged file is set aside as subscriber-history.db.corrupt and a new one started. The file can be deleted at any time; the history simply starts again.

Turning it off, and tuning it#

set subscriber-history enabled false

The graph and the sparkline column disappear and nothing is sampled or written. The settings are under subscriber-history and take effect when the control plane restarts.

From the API#

Both are readable by the read-only role and work through the fleet proxy for another appliance.

Limits#

  • 24 hours, on the appliance. For longer history, or history that survives the loss of the appliance, graph the SNMP or Prometheus counters in your monitoring system.
  • One-minute resolution at best. For what a subscriber is doing this second, use the live chart on the session page.
  • The history belongs to the appliance that carried the traffic. A subscriber who reconnects to a different appliance starts a new history there; the old one stays where it was until it ages out.
  • A key built from the access circuit (port:…) is the circuit's history, whoever is on it.