Understanding Consolidation
K.1 Introduction
Consolidation is discussed in the sections on using consolidation in the Monitoring chapter (sections 10.4.3 and 10.5.2).
However, it may be confusing to have the concept of consolidation discussed in the same place as the use of consolidation. Also, the algebra that appears in that discussion (here) may not appeal to people. There are many who would like an explanation that may be more intuitive, even if it is less rigorous.
Therefore, in this section a more informal and visual approach is taken to explain consolidation.
K.2 What Is Consolidation?
Consolidation is the compression of data, for data values that have been measured over a fixed interval.
The compression is nothing particularly sophisticated. It is carried out by using some simple mathematical functions to the data points: the average, the maximum, or the minimum.
K.3 Raw Data And Consolidation
Suppose raw data is sampled every 2 minutes.
And the raw data values are consolidated every 10 minutes.
A visual representation of the data values available to the system is:
Here, every “|”” indicates a data point, so that the visual shows 5 times as many raw data points as consolidated data values.
In the preceding visual it makes no sense to use consolidated data since the data values for raw data and consolidated data overlap. I.e., the more accurate raw data values exist for the entire period.
As time passes, the intention is to start dropping old raw data, to save space on the disk.
For example, for the first 20 minutes in the following visual, there are no longer raw data values available:
Example
But the consolidated data points for this period are still available to the system.
When the data values are plotted in Base View graphs, periods without raw data values automatically have consolidated data values used.
So a combination of both data sources is used, which can be visually represented with:
Example
That behavior holds true for cmsh too.
The behavior illustrated in the last visual assumes that the cluster has been UP for long enough that raw data is being dropped.
In this case, “long enough” means at least 7 days.
However, because RLE (Run Length Encoding) is used to compress the sampled monitoring data values on disk, this minimal “long enough” time can be (much) longer than 7 days. It depends on how much the measurable that is being sampled is changing as each sample is taken. if it is not changing, then RLE can compress over a longer time period.
For example, if a node has been up and reachable without issues for 1000 days, then the ssh2node health check raw data values would be PASS over that 1000 days. For the period from now to 7 days ago, the raw data values of PASS are kept as they are for now. However, for the period from 7 days ago to 1000 days ago, consolidation on the unchanging raw values means that only two values, namely the PASS value of 1000 days and the PASS value of 7 days ago, need to be retained, in order to have a totally accurate record of what the values were in that period.
On the other hand, the forks metric changes very quickly, and thus can do little RLE compression. That makes it a good choice for demonstrating the kind of output that the preceding visuals imply.
K.4 A Demonstration Of The Output
So, as a demonstration, the last 7 days for forks are now shown, with the data values in the middle elided:
Example
The first part of the output shows samples listed every hour. These are the consolidated data values.
The last part of the output shows samples listed every 2 minutes. These are the raw data value values.
I.e.: consolidated data values are used beyond a certain time in the past.
If the administrator would like to explore this further, then displaying only consolidation values is possible in cmsh by using the --consolidationinterval option of the dumpmonitoringdata command:
Example