Hi Ken,
apologies for reviving this old thread but I noticed something that
might perhaps still be improved, at least in a theory..
On 2015-10-15 09:22, Marko Myllynen wrote:
> On 2015-10-15 09:15, Ken McDonell wrote:
>> Some review eyes here would be appreciated.
>>
>> Ken McDonell (9):
>> libpcp: extend __pmAF* family with __pmAFsetup
>> pmlogger: change semantics for first logging operation
>> qa: many changes for pmlogger "log early" semantic change
Let us consider the following archive created with the latest PCP code:
$ pmdumplog -a ...
...
Temporal Index
Log Vol end(meta) end(log)
10:05:09.228 0 132 132
10:05:09.248 0 351 268
10:05:15.248 0 503 484
[136 bytes]
10:05:09.228 2.3.3 (pmcd.pmlogger.host): inst [17779 or "17779"] value
"localhost"
2.3.0 (pmcd.pmlogger.port): inst [17779 or "17779"] value 4331
2.3.2 (pmcd.pmlogger.archive): inst [17779 or "17779"]
value "/tmp/8LdWEN.localhost"
[72 bytes]
10:05:09.248 60.2.2 (kernel.all.runnable): value 1
60.0.4 (disk.dev.read): inst [0 or "sda"] value 59546
[72 bytes]
10:05:11.248 60.2.2 (kernel.all.runnable): value 2
60.0.4 (disk.dev.read): inst [0 or "sda"] value 59546
[72 bytes]
10:05:13.248 60.2.2 (kernel.all.runnable): value 1
60.0.4 (disk.dev.read): inst [0 or "sda"] value 59546
[72 bytes]
10:05:15.248 60.2.2 (kernel.all.runnable): value 1
60.0.4 (disk.dev.read): inst [0 or "sda"] value 59546
$
Clients which fetch and report the metrics for the first time will see
the pmcd.* related metrics at 09.228 but not the user recorded metrics
as they start a bit later at 09.248. So a client is slightly "off-sync"
e.g. with pmval -a ... -r the reported values are one value "behind"
what a user might expect.
This caught my attention when I was testing pmrep archive handling with
tiny archives with 1s interval, do you think this kind of tweaking would
be possible and worthwhile?
Thanks,
--
Marko Myllynen
|