Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

Internal system management of reports disk quota in Flowmon

 

Information

 

Summary:

This article explains how the reports disk management works with regards to the user defined quotas

Environment:

Product: Flowmon

Version: Any

Platform: Any

Question/Problem Description:

We would like to ask about data retention periods for reports.

Am I correct in understanding that we set a value on the Quota manager>Reports and when the current size reaches the set value, the oldest data is deleted from the report?

Also, how can I check how long data is retained for a report?
When we display the report, we sometimes see " No data available for the selected interval." in the top chapter, am I correct in assuming that the data has already been deleted?

Is there any way to check the storage period of report data like the flow data?

Steps to Reproduce:  
Error Message:  
Defect Number:  
Enhancement Number:  
Cause:  
Resolution:

Similarly to the monitoring data available in Flowmon monitoring center, when the reports quota limit is reached, the system starts to remove the oldest data. If the the selected time range is outside of available data, it will display the "No data available for the selected interval" message (in the Flowmon monitoring center this range is highlighted by greyed-out area). However the reports disk management is more complicated compared to profile quotas. 
 
The reports quota is divided between each chapter. The are two kinds of granularities - one day granularity and one hour granularity - for each chapter. And if the quota limit is reached (sum of all chapters), then the system will delete the oldest data for one hour granularity. 
 
There is also the rule that the data for the last 7 days should never be deleted. Once the quota is reached, the system will try to equalize the chapters - for example if one is 10 days old and the other one is 60 days old, it will try to delete the oldest one hour granularity gradually so both chapters become the same length over time.
 
If even then the quota is still not satisfied, the system will then start to delete the one day granularity statistics in the same way, but here the last 30 days for the one day granularity should be always kept.
 
This is a simplified explanation as there are more nuances. It is also worth mentioning that it is hard to guess the real disk requirments by each chapter as it is highly variable and it depends on the settings of each chapter and the traffic data in each environment. So our suggestion is to just let the user test different setting and increase or decrease the quota as needed.

Workaround:  
Notes:  

Was this article helpful?
0 out of 0 found this helpful

Comments