When testing at scale, it is inevitable that at some point your load test will encounter error states. It may even be a condition itself that is tested. Therefore, it is essential that we have a capability to capture and analyze error information. In this brief article, we will detail how to intercept and log errors in your k6 load tests.
Intercepting and Logging Errors
Ideally, we would like to save errors to a retrievable log file that can be reviewed after the test completes. In order to do this, we must implement a class that instructs k6 on what to do with error information. Here is the example class provided in the official k6 documentation:
class ErrorHandler { constructor(logErrorDetails) { this.logErrorDetails = logErrorDetails; } logError(isError, res, tags = {}) { if (!isError) return; const traceparentHeader = res.request.headers['Traceparent']; const errorData = Object.assign( { url: res.url, status: res.status, error_code: res.error_code, traceparent: traceparentHeader && traceparentHeader.toString(), }, tags ); this.logErrorDetails(errorData); } }
The next step is to initialize the ErrorHandler
object in our code, which will make invoking on errors more convenient:
const errorHandler = new ErrorHandler((error) => { console.error(error); });
When implementing error handling, the checks module that k6 provides is particularly useful. This allows us to validate a boolean condition and take an action. Here is the basic example provided in the k6 documentation:
import http from 'k6/http'; import { check } from 'k6'; export default function () { let res, checkStatus; res = http.get('https://httpbin.org/status/200'); checkStatus = check(res, { 'status is 200': (res) => res.status === 200 }); errorHandler.logError(!checkStatus, res); res = http.get('https://httpbin.org/status/300'); checkStatus = check(res, { 'status is 200': (res) => res.status === 200 }); errorHandler.logError(!checkStatus, res); }
In the above code, test endpoints are used where the first HTTP request causes a 200
response to be returned, while the second example returns a 300
response. Our check is configured such that an error will be logged whenever either request returns a response code other than 200
.
Reviewing Errors
By default, errors logged in this manner go to the configured output. When running from the command line this is typically the console. When running your test on RedLine13 with output files enabled, errors will appear in the logs.out
file. Here is an example of how the error from a request above would be logged:
time="21:44:08-05:00" level=error msg="{\"url\":\"https://httpbin.org/status/300\",\"status\":300,\"error_code\":0}" source=console
This log entry captures the basic information regarding the unexpected response to our request. By modifying the ErrorHandler
class, it is possible to capture as much detail as desired.
Did you know that RedLine13 offers a full-featured, time-limited free trial? Sign up now, and start testing with k6 in the cloud today.