Current approach of saving timer-related data results in data being displayed with minutes delay


Migrated from NovaTec Jira. Original ticket: INSPECTIT-992

Currently the aggregation of timer data is flawed. Data is displayed quite late, so the user might think the charting does not work. In situations when not so many methods are being charted, it can occur that write to the database is more than few minutes late. This is all because we are keeping data in memory based on the method/time-stamp combination, thus if not so many methods are monitored that our queue does not get filled fast. Meaning data is not dropping from the queue, and this is when we persist it to the database. Other than that we only persist when there is no new entry for one minute (situations when agent is disconnected).

If we are to move to influx this problem would be solved there as well.

Apart from that: The approach is also different from the aggregation of HTTP data.




Stefan Siegl
June 26, 2015, 7:19 AM

2013-08-23T10:27:35.000+0200 by Ivan Senic

Me and just discussed the possible solution for the current situation.. The idea would consist out of several changes:

  1. We dismiss completely the current approach

  2. We have a component that goes over the buffer and aggregates the data that is in the buffer until lets say one minute to present time.. This component knows the ID of the last aggregated data and this can serve as the starting point for next round of aggregation..

  3. When we retrieve the data for the charts we load everything that is in the database and add all data from the buffer that correspond from the latest aggregated ID.. We would need to create new services for this..


  1. Buffer gets full too fast and drops elements before they are aggregated - we need to ensure that all dropped elements are saved

  2. Make sure everything in buffer is aggregated and persisted at the shutdown of the CMR

Additional idea would be to only aggregate and save the dropped data from the buffer, include all buffer in the queries.. This is more easier but requires more time for the CMR shutdown (which I don't think is such a problem)..

Stefan Siegl
June 26, 2015, 7:19 AM

2013-08-30T14:39:58.000+0200 by Ivan Senic

We need more discussion here.. will write his solution with pros and cons, we can then consider everything..

Stefan Siegl
June 26, 2015, 7:19 AM

2013-11-07T11:17:04.000+0100 by Stefan Siegl

Discussion 07.11.2013:

  • Patrice did not have time yet to write pros and cons

  • Not very very high priority so we skip it for now

Stefan Siegl
July 7, 2015, 11:51 AM
  • check how this is linked with other tickets

Patrice Bouillet
May 19, 2017, 11:16 AM

The preferred way to display monitoring data is Influx. And with this the problem does not appear anymore.

Won't Fix


Ivan Senic


Stefan Siegl






Affects versions