I have a question about how collectd uses the timestamp when it collects and records values.
I captured some output from the write_http plugin, filtered to show two sequential runs of the memory plugin. PUTVAL ubuntu.example/memory/memory-used interval=30 1330142682:70070272.000000 PUTVAL ubuntu.example/memory/memory-buffered interval=30 1330142683:55861248.000000 PUTVAL ubuntu.example/memory/memory-cached interval=30 1330142683:191954944.000000 PUTVAL ubuntu.example/memory/memory-free interval=30 1330142683:67403776.000000 PUTVAL ubuntu.example/memory/memory-used interval=30 1330142712:70057984.000000 PUTVAL ubuntu.example/memory/memory-buffered interval=30 1330142712:55881728.000000 PUTVAL ubuntu.example/memory/memory-cached interval=30 1330142712:191954944.000000 PUTVAL ubuntu.example/memory/memory-free interval=30 1330142712:67395584.000000 In the first block, the first timestamp ends in -682, while the others end in -683. In the second block, the timestamps are all the same, -712. Why aren't the all always the same over a single run of the plugin? I would expect the calls to memory_submit(), and consequently plugin_dispatch_values(), to happen within microseconds of each other, making those timestamps crossing from one second to the next extremely unlikely. However, when running with an interval of 30 seconds, it happens 4-5 times over the course of an hour, around 3% of the time. I checked, and those Additionally, it happens on my Ubuntu testing VM (collected 4.10), but not when I run collectd (5.0.2) on my OSX host. I should investigate it on a non-VM ubuntu box and/or compile 5.0.2 for Ubuntu 10.04, to isolate if its the OS, virtualization, or the collectd version, but I was hoping the list could also provide some enlightenment. Thanks for your time, Paul Sadauskas _______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
