what will happend when sending different values with same timestamp or within defined interval to Graphite
Graphite will align timestamp based on the retention defined in storage-schemas.conf, whenever you send a metric to Graphite, Graphite will align timestamp like this:
timestamp - (timestamp % interval)
so for example, let's say you have 1 minute interval (time per point), or 60 seconds for one of your metrics, then you send:
my.useful.metric 2022 1414516239
Graphite will save (timestamp aligned):
my.useful.metric 2022 1414516200
because 1414516239 - 1414516239 % 60 = 1414516200
and if you send multiple values with same timestamp, or you send multiple values then all of them are within defined interval ----- that is: (timestamp - (timestamp % interval)) has same value. the last one wins. Graphite will only save last value (with exceptions, see detail in last part of this post).
So back to previous example, if you send in below order (doesn't matter when you actually send them, with exceptions):
my.useful.metric 322 1414516229
my.useful.metric 522 1414516249
my.useful.metric 26 1414516214
my.useful.metric 222 1414516255
my.useful.metric 3256 1414516234
after alignment, all timestamps are now 1414516200, you actually only get:
my.useful.metric 3256 1414516200
More details regarding the whole process and explanation of exception:
when you send data to Graphite --- carbon cache daemon, actually, will cache all the data as long as the format is correct (metric_name value timestamp), the timestamp alignment won't happen at this stage.
The cabon cache daemon has a separate thread to flush all data to disk and empty cache as fast as possible, unless you defined throttling by setting MAX_UPDATES_PER_SECOND and/or MAX_CREATES_PER_MINUTE. The thread will go to sleep for one second once all data in cache are written to disk. Before data was written to disk, the library (Whisper) will first reverse the data in cache (so last data point became first, first data point became last), then align timestamp as stated before, then update file (update many data points in one update). So here's exception with regard to which value Graphite will actually save mentioned above: if you send data to Graphite faster enough, that your previous data hasn't been flushed yet, then those data will be merged in cache with previous values, when data as flushed to disk next time the first value in the cache wins. if you query after data was flushed to disk, you will only see first data point, but if you query before data flush, you will still get last data point (see below for detail).
When try to load/query data using web UI or API interface , Graphite will check data both in data file and in carbon cache, then merge them (data in Cache take priority), then align timestamp and send result back to you, it will also keep a cached version of the data you just queried, the cache look up key is the whole query string. Next time if you query the same data using same query string, it will return from cache if the data is still available unless you put "noCache" in query parameter, which will force Graphite to read from data file and carbon cache again.
timestamp - (timestamp % interval)
so for example, let's say you have 1 minute interval (time per point), or 60 seconds for one of your metrics, then you send:
my.useful.metric 2022 1414516239
Graphite will save (timestamp aligned):
my.useful.metric 2022 1414516200
because 1414516239 - 1414516239 % 60 = 1414516200
and if you send multiple values with same timestamp, or you send multiple values then all of them are within defined interval ----- that is: (timestamp - (timestamp % interval)) has same value. the last one wins. Graphite will only save last value (with exceptions, see detail in last part of this post).
So back to previous example, if you send in below order (doesn't matter when you actually send them, with exceptions):
my.useful.metric 322 1414516229
my.useful.metric 522 1414516249
my.useful.metric 26 1414516214
my.useful.metric 222 1414516255
my.useful.metric 3256 1414516234
after alignment, all timestamps are now 1414516200, you actually only get:
my.useful.metric 3256 1414516200
More details regarding the whole process and explanation of exception:
when you send data to Graphite --- carbon cache daemon, actually, will cache all the data as long as the format is correct (metric_name value timestamp), the timestamp alignment won't happen at this stage.
The cabon cache daemon has a separate thread to flush all data to disk and empty cache as fast as possible, unless you defined throttling by setting MAX_UPDATES_PER_SECOND and/or MAX_CREATES_PER_MINUTE. The thread will go to sleep for one second once all data in cache are written to disk. Before data was written to disk, the library (Whisper) will first reverse the data in cache (so last data point became first, first data point became last), then align timestamp as stated before, then update file (update many data points in one update). So here's exception with regard to which value Graphite will actually save mentioned above: if you send data to Graphite faster enough, that your previous data hasn't been flushed yet, then those data will be merged in cache with previous values, when data as flushed to disk next time the first value in the cache wins. if you query after data was flushed to disk, you will only see first data point, but if you query before data flush, you will still get last data point (see below for detail).
When try to load/query data using web UI or API interface , Graphite will check data both in data file and in carbon cache, then merge them (data in Cache take priority), then align timestamp and send result back to you, it will also keep a cached version of the data you just queried, the cache look up key is the whole query string. Next time if you query the same data using same query string, it will return from cache if the data is still available unless you put "noCache" in query parameter, which will force Graphite to read from data file and carbon cache again.
Comments
Post a Comment