The Data File Format¶
The aggregated test data is saved in a file called
<test_name>-<date>.<title>.flent.gz (the title part is omitted if no title is
specified by the
-t parameter). This file contains the data points
generated during the test, as well as some metadata.
The top-level object keys¶
The file format version as an integer.
An array of the x values for the test data (typically the time values for timeseries data).
A JSON object containing the result data series. The keys are the data series names; the value for each key is an array of y values for that data series. The data array has the same length as the
x_valuesarray, but there may be missing data points (signified by null values).
An object containing various data points about the test run. The metadata values are read in as configuration parameters when the data set is loaded in for further processing. Not all tests use all the parameters, but they are saved anyway.
An array of objects for each data series. Each element of the array contains the raw values as parsed from the test tool corresponding to that data series.
The test name.
List of the server hostnames connected to during the test.
The hostname of the machine that ran the test.
Time step size granularity.
ISO timestamp of the time the test was initiated.
Version of Flent that generated the data file.
IP version used to run test (as specified by command line parameters, or auto-detected from
The kernel name as reported by uname -s.
The kernel release as reported by uname -r.
The sha1sum of certain interesting Linux kernel modules, if available. Can be used to match test data to specific code versions, if the kernel build is instrumented to, e.g., set the build ID to a git revision.
The values of several networking-related sysctls on the host (if available; Linux only).
Interface name, qdisc, offload, driver and BQL configuration of the interface used to reach the test target. This requires that the ip binary is present on Linux, but can be extracted from route on BSD. Qdisc information requires the tc binary to be present, and offload information requires ethtool.
--remote-metadatais used, the extended metadata info is gathered for each of the hostnames specified. This is gathered under the
REMOTE_METADATAkey in the metadata object, keyed by the hostname values passed to
--remote-metadata. Additionally, the
REMOTE_METADATAobject will contain an object called
INGRESS_INFOwhich is a duplicate of
EGRESS_INFO, but with the destination IP exchanged for the source address of the host running flent. The assumption here is that
--remote-metadatais used to capture metadata of a router known to be in the test path, in which case
INGRESS_INFOwill contain information about the reverse path from the router (which is ingress from the point of view of the host running flent). If the host being queried for remote metadata is off the path, the contents of
INGRESS_INFOwill probably be the same as that of
--extended-metadata switch is turned on, the following
additional values are collected and stored (to the extent they are available
from the platform):
IP addresses assigned to the machine running flent.
IP addresses of all detected default gateways on the system, and the interfaces they are reachable through. Only available if the netstat binary is present on the system.