All sections / {current.section.title} / {current.chapter.title} / {current.topic.title} / {current.title} / {current.title} / {current.title} / {current.title}

Retrieve Logs


Logs can be retrieved for a test session by using the following command:

resolvertest log KEY

Where KEY identifies the test key for the test to generate logs for. By default with no additional flags this will generate logs for the last 5 minutes in JSONL format and print the logs directly to stdout.

Any of the following optional flags can be passed to control the log behaviour and output further.

–maxAge AGE_MINUTES - The maximum age in minutes for the returned logs (defaults to 5). This will return all logs from the supplied offset in minutes in the past up to the latest log entry.

–fromDate DATETIME - An explicit start date for the returned logs. This overrides the –age flag value and sets an explicit start time.

–toDate DATETIME - An explicit end date for the returned logs. This overrides the default behaviour of reading all logs up to the latest log entry.

–fromId ID - An explicit start sequential id for the returned logs. This overrides the –age flag value.

–toId ID - An explicit end sequential id for the returned logs. This overrides the default behaviour of reading all logs up to the latest log entry

–format FORMAT - One of JSONL, JSON or CSV to control which format the logs are returned in (defaults to JSONL)

–file FILEPATH - If supplied, the logs are written to a file identified by the file path rather than straight to stdout.  

–resultLimit LIMIT - The maximum number of log entries to be returned (defaults to 10,000).


Whilst the specific format of a given test session will vary depending on the test being performed, there is a common set of fields which would be emitted for each log entry as follows:

id: A guaranteed sequential unique id within the given test session for the log entry

Datetime: The date/time of the log entry 

For tests incorporating DNS lookups we would expect further standard fields for each resolution involved in the test as follows:

firstDNSResolutionTime: The time that the first DNS resolution occurred in the test

firstDNSResolvedHostname: The hostname resolved by the first DNS resolution involved in the test

firstDNSClientIPAddress: The client IP address / prefix according to the defined policy in place

firstDNSResolvedQuery: The full query resolved by the first DNS resolution involved in the test

firstDNSResolvedAnswer: The full answer to the query resolved by the first DNS resolution involved in the test

For tests incorporating Web server requests we would expect further standard fields for each resolution involved in the test as follows:

firstWebServerRequestTime: The time that the first web server request was received

firstWebServerRequestHostname: The hostname resolved by the first web server request

firstWebServerClientIPAddress: The client IP address / prefix according to the defined policy in place for the first web server request

firstWebServerResponseCode: The HTTP response code returned for the first web server request

With additional field sets named second*, third* etc if more than one request is involved in the specific test.

In addition to these standard fields we would expect tests to define specific custom fields e.g. a normalised Result field to indicate success/failure etc.



Top