Hi fellow barometers
I've been looking at the timestamps sent along with the events + stats...
Currently there are 2 scenarios:
1. where the subsystem we are reading from CAN provide us with the time the
sample was collected:
In this case we have the time for the sample/evet and the time collectd
retrieves the sample... so my
thinking is the timestamp for the sample here is the one used as the
timestamp. Collectd can send it's
read timestamp along with the metadata separately. I think this is
important for both stats and events,
but the events has a higher sensitivity to this. What this gives us is the
delay/detection time between
the telemetry agent and the subsystem it's interacting with.
2. where the subsystem we are reading from CANNOT provide us with the time the
sample was collected:
In this case we only have the time for the time collectd retrieves the
sample... so the time stamp sent
with the data is that from collectd (closest approximation we have).
Advantage with this approach - accurate reflection of when an event
occurred/metric was read.
Disadvantage with this approach - a single time definition for timestamp isn't
used for both scenarios.
Alternate approach: always use the collectd time for the timestamp - BUT where
other info is available send it in the metadata.
Advantage with this Alternate approach - inaccurate reflection of when an event
occurred/metric was read.
Disadvantage with this Alternate approach - a single time definition for
timestamp is used for both scenarios.
Thoughts?
BR
Maryam
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
