statistics tools for OpenBSC

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Dec 22 20:10:57 UTC 2009


Hi all!

I've just added some code to OpenBSC which keeps counters for various events,
such as the number of channel requests, how often we were out of channels,
the number of delivered/submitted sms, paging statistics, etc.

Those counters are available through the VTY for evaluation at runtime.

There is now a "Counters" table in our database schema.  It stores those
counters in a generic way.  The counters are stored to the database every
minute.  Each counter is identified by a string like "net.sms.delivered"

The counters increment all the time, until OpenBSC terminates, when they will
re-start from zero.  I did not want to make the counters persistent (i.e.  load
them from the database) as it would cofuse users of the VTY.

What's still missing now is some kind of script that uses those counters to
generate something like nice charts.  Given the way how the counters are stored
in the database, it should be relatively easy to write a fairly generic tool
that does not need any modification even if we add new counters.

What I'm thinking is something like specifying the specific counters one is
interested in at the command line, maybe also providing a start and end time.

The graphs should then generally show the increments of the counters between
two counter stores in the database.  So if e.g. one minute ago the number of 
delivered SMS was '10', and now it is '15, then the actual value plotted
in the graph should only be '5'.

The only "difficulty" is to handle restarts of OpenBSC... but that's quite
easy.  All counters are monotonically incrementing, i.e. whenever you see a
smaller counter, you can safely assume that openbsc was restarted and that we
simply continue with the next diff, ignoring the negative one.

If anyone is interested in working in such a tool (preferrably in python or
perl, using their respective sqlite3 bindings), it would be greatly
appreciated.

However, please do coordinate on this mailing list... your time is too
precious to be wasted by code duplication.

Thanks in advance,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list