Current approach of saving timer-related data results in data being displayed with minutes delay
Description
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.
Environment
Activity
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:
We dismiss completely the current approach
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..
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..
Problems:
Buffer gets full too fast and drops elements before they are aggregated - we need to ensure that all dropped elements are saved
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)..
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..
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
check how this is linked with other tickets
The preferred way to display monitoring data is Influx. And with this the problem does not appear anymore.
