Repository navigation
Please expose more UE stats! #1883
Description
Enhancement Proposal
Hi, ok I'm back for asking for more stats to make Ella even more awesome. :)
The recent update with datarate per gNb and DNN are great. But while I doing the customer debug on implementation I imagine I need to poll those every 1-3 sec to prove the QOS and slices are working fine and then I can leave it running every 30 sec. .
The current 24h totals are updated only every 30 sec, so there is no workaround here.
Maciej
Activity
gruyaume commentedon Nov 4, 2026
Hello Maciej,
Thanks for reaching out again.
Yes, we could make that configurable, but I'd warn against aggressive usage updates because it dramatically increases DB writes and can slow down the system
We could also have counter-type stats available in the subscribers API that would give us live values when called. We'll investigate the idea.
gruyaume commentedon Nov 4, 2026
We added per-UE traffic counter in the subscriber API in #1884 , can you please validate whether that satisfies your need?
xsherlockpl commentedon Nov 5, 2026
I tested that and it does work fine with 6 simulated UE's and 5sec interval. I would probably scale down to 15sec for a production system. A thing to think about is to make bulk endpoint that would just output all UE's at once.
Do you hold this data in the DB? I would not expect Core to hold that fine granularity data, What I experiment with is an NMS server that that has purpose built TimescaleDB (or Influx) to hold the metrics.
gruyaume commentedon Nov 5, 2026
No, counters aren't stored. Only the daily usage totals are written to the DB (every 30s). Right, a time series DB is where metrics belong. We generally use and document Mimir, but Timescale DB or Influx will work fine too.
Maybe, it would have to be done very thoughtfully. We're in the process of adding support for 100k subscribers and at the scale, such a bulk endpoint could prove a problem.