riemann/riemann

Inconsistency in time across streams

Closed this issue · 2 comments

deoqc commented

I identified at least 2 different ways of the "current time" as used by the streams functions:

1 - As the (local) max of events time to date (eg. moving-time-window);
2 - As the riemann.time/unix-time(e.g. rate)

Is there an away to use time consistently across these streams functions? Or am I missing something?

My use case

I know that riemann is originally intended for real-time metrics, but I started using it for IoT monitoring for a fleet of devices that don't have guaranteed broadband.

But I can guarantee the order of delivery, and the 1 definition would be a must if used consistently.

sanel commented

Not sure if helps, but for cases like this, I'd update metric :time to (unix-time) as soon as it arrives. Unless there is huge difference between the time when metric is sent from device and when is arrived to Riemann, time difference should not matter.

Again, I'm speaking from my use-case :)

jamtur01 commented

Closing. Please re-open if you have further questions.