Instead of just a send_count, keep one such count for the counter
updates, and a separate one for the stat item updates.
Print those numbers in the test output.
An upcoming patch will tweak stat_item reporting so that only an
actually changed value results in sending a new stat value. This patch
allows illustrating that change clearly.
Related: SYS#5542
Change-Id: I2da003ee6ec15f1c3959efe69e01b4ee24af82bb
Background:
* Individual values can be added to osmo_stat_item.values at any time.
* Stats are reported at a fixed interval (see vty 'stats interval'),
e.g. every 10 seconds.
* In order to report a new stat value, we use the maximum of all
osmo_stat_item.values added since the last report.
* By default, we do not send new stat values if they did not change
(see vty 'config-stats' -> 'flush-period' default of 0).
Fix the following bug:
* If 'flush-period' is 0, and no new osmo_stat_item.values are coming
in, the last value that gets reported is not necessarily the last
entry in osmo_stat_item.values.
* For attached reporters (statsd), it could then be that the given stat
stays at the wrong value for a long stretch of time (think of several
hours/days/forever).
Explanation of how the test shows that it is fixed:
* stats get reported (value is irrelevant)
* osmo_stat_item gets a new value: 20
* osmo_stat_item gets a new value: 10
* stats get reported (value: 20, the maximum of both new values)
* osmo_stat_item gets no new values
* stats get reported (value: 10, this is new because of the bug fix,
the real last value in osmo_stat_item, different from the 20 sent
earlier, without the fix it would not send anything here and the last
sent value would be 20)
* osmo_stat_item gets no new values
* stats get reported (nothing gets sent, since the real last value was
already sent and 'flush-period' is 0)
Fixes: OS#5215
Change-Id: Ibeefd0e3d1dbe4be454ff05a21df4848b2abfabe
Extend the test to illustrate the bug described in the related issue,
which will be fixed with the next patch.
Related: OS#5215
Change-Id: I1d26867ac1b837bea6a9754a3203e53c147e7a5f
This reverts commit d290439b4a, which
caused "stats values skipped" messages to appear even if they were not
skipped. Revert for now, replace with a proper version in the future.
Related: SYS#4877
Change-Id: Ib43bd53188a4d31d771feb921ea14abe1a3ec877
Let the user know when the stats were not consumed fast enough for the
given FIFO length.
Related: SYS#4877
Change-Id: If0e8ab55103007693101538fb6ea310075217774
Move test output from stdout to stderr and enable logging to stderr.
This is in preparation for the next patch, which will add a new log
message when osmo_stat_item_get_next() skips a value.
Related: SYS#4877
Change-Id: Ie0eaec2f93ac6859397a6bfca45039fdcc27cb9e
Neels Hofmeyr
Oliver Smith