pool.xrm data consolidation correction

jjsk1 · June 2017

Pavel

I was troubleshooting some data discrepancy with our previous monitoring tool and found that currently the pool.xrm output on the days when conf_proc_units changes midday RRD picks the max(conf_proc_units) + max(bor_proc_units) to calculate the size of the pool. that results in a wrong pool size derived from the archive records and consequently incorrect max value shows up on the chart

Do you think this can be fixed by setting RRA function on bor_proc_units to MIN?

example data:

497460800 6.5615229857e+10 2.6419582188e+10 1.0100000000e+02 2.7000000000e+01
497460860 6.5482107614e+10 2.7467522426e+10 1.0100000000e+02 2.7000000000e+01
497460920 6.5862848800e+10 2.8409021163e+10 1.0151666667e+02 2.6483333333e+01
497460980 6.6262902417e+10 2.8605609362e+10 1.0200000000e+02 2.6000000000e+01

the pull size is reported as 129 in the RRA 24hr archive for this day (102+27), but it's actually 128

hopefully it's an easy fix

Pavel · June 2017

Hi,

ok, it took me a while to understand it

problem is that you change conf_proc_units "regulary" on the midnight, right?
Then it mosty works fine except yearly graph which uses daily MAX data.

I am not sure if your solution will work generally better than the actual one, or if there is generally a solution for such behaviour.

We cannot change RRA type from MAX to MIN for already created files. It is not about graphing, it is about saving data.

jjsk1 · June 2017

thanks. I'm not sure why this happens but sometimes the hmc reports new numbers in conf_proc_units for several readings, even when we have not changed any profiles or configuration. The lines above returned to 101 and 27 after a few minutes.

when this happens it throws off data in the rrd database. it's not a big deal, I think we can manually correct for this.

pool.xrm data consolidation correction

Comments

Howdy, Stranger!

Categories

In this Discussion