One of collectl's main features is its ability to generate output in a ready-to-plot format and write that data to one or more files which are compatible with what gnuplot expects and there are actually 2 main types of files that it generates. The first, which has an extension of tab, represents a table of all the summary data. What makes this file unique is that all data elements are in a fixed set of columns - some columns may get added over time, but for all intents and purposes, the set of data for say CPUs do not change regardless of how many CPUs are in the system. The second type of files deal with detail data, the amount of which changes with the number of instances so a 4 CPU system will have 1/2 the data an 8 CPU system has. There is one file for each type of detail data and like raw files you tell collectl where to put the plot files with -f.
Plot files can be generated in 2 ways and each has its own advantages as well as disadvantages.
At first glance, it sounds like you'd always want to generate plot files directly since you avoid the need for the conversion step, but you should also realize a few things about this methodology:
By default, the name of the plot file contains only the date and a test is made to see if a file with that name already exists. If not, it is created in append mode. This means that multiple raw data files for the same host on the same date will result in a single set of data. However, if that file already exists, collectl will NOT process any data, and request you specify -oc to tell it to perform the first open in create mode so that subsequent files can be appended. If you specify -oa all files will be appended to the original one which may not be what you want. Collectl cannot read your mind so to be safe, be explicit. If you want to generate a unique set of data files for each raw file use -ou which causes the time to be included in file names, resulting in a unique output file name for each raw file.
This certainly maximizes your flexibility for all the reasons listed earlier. However, this now puts the responsibility of managing your data more squarely on your shoulders. Some of the questions you need to answer include:
TIP - If you rsync raw files to another server and then process them using a wildcard in your playback command, you will probably end up processing some of today's files too! If you then later copy over the rest of today's file(s) you will need to recreate today's plot file since collectl will not overwrite an exiting file by default. But if you specify the -oc switch with a wild card you will end up recreating all the plot files which will result in a lot more processing than you were planning on. Collectl supports a special syntax that allows you to playback just the files from yesterday by replacing that string with yesterday's date as in the following:
collectl -p "YESTERDAY*" etc...noting that all uppercase characters are required and you can include other characters in the string such as a host name if need be.
TIP - If you want to create multiple sets of plot files from the same raw file, you can always include a unique qualifier along with the directory name with the -f switch to give each set a different prefix.
Whether you choose to create plot files on-the-fly or manually (by playing back existing files), if you've not instructed collectl to do anything with unique file, it will simply append new data onto an existing file. One the other hand if you explicitly ask for unique files, whenever a new raw is processed or a new instance of collect is run, a new plot file will be created that includes a corresponding timestamp.
The obvious question then becomes, why would you ever choose to create unique files when they're such a pain to plot? and there are actually several good reasons you might choose to do so:
collectl -scd -P -f/tmp collectl -scdm -P -f/tmpor perhaps you even generated raw files first and later play them back, converting them to plottable files. In either case you now want to plot the data. Since it's all in the same file, the headers that are initially written will only tell you there is cpu and disk data in the file! Collectl will have written a second set of headers in the file at the time the second instance was run, but do you really want to have to make a pass through the whole file every time you want to generate a plot looking for additional data? Furthermore, there will be less columns of data in the first part of the file that the latter, a condition that will probably cause most plotting packages to blow up, so you really need unique files.
Another situation that can cause this is when dealing with detail data for dynamic subsystems such as Lustre and disks. Dynamic change detection for Lustre has always been a part collectl but support for dynamic disk configuration changes has been added to collectl V3.3.4. When a configuration change is detected, it forces collectl to create a new file, whether generating data in raw or plot format. Furthermore, if you later try to combine disk data from multiple raw files into a single plot file that has disk configuration change data in it, collectl won't let you unless you specific -ou forcing the generation of unique files. Lustre changes can be combined into a single plot file by adding in any missing columns and 0-filling them.
|If you are generating non-unique plot files on-the-fly and a configuration change occurs, that new data will simply be appended to the single file. There is nothing collectl can do about this, because it wants to keep all files in a consistent name format and will not switch to unique name formatting without explicitly being told to do so.|
Configuration changes do not happen often and this is only an issue when generating plot files in real-time. Furthermore, since this only effects detail, because the summary data will always accurately reflect the sum of the instance data, this typically will not effect anyone but is being stated for completeness.
If after all this you choose to generate real-time, non-unique detailed plot files and find yourself in a situation where you should have, you can always write a script to split the plot files back into individual ones since there is sufficient data in the internal headers to do so. If you have multiple unique files and find single files easier to deal with, you can also choose to write a post-processing script that merges these into a single file with zero-filled columns where there is missing data.
|updated June 9, 2017|