JavaScript logging
JavaScript logging captures log messages generated during the current request. You can deliver the JavaScript logs via Enhanced debug headers or a DataStream 2 stream.
In addition to logging static strings, you can also use variable substitution to include dynamic data in the EdgeWorkers logs.
🚧 When adding JavaScript logging to your EdgeWorkers make sure that sensitive data is not included in the log output.
The following restrictions apply to JavaScript logging headers:
- Logging headers are not cached.
- The logging header includes all messages logged for the specified event handler.
- The maximum log size per event handler is 1024 bytes.
- If the log contents exceed 1024 bytes the results are truncated.
Use enhanced debug headers to view JavaScript logs
For information about how to retrieve logs for the responseProvider event handler see, Enable JavaScript logging for responseProvider.
-
To view the JavaScript logging results you need to set up your property for enhanced debug headers.
-
Import the built-in log module.
- Add the logging messages into the event handlers of your choice. You can add EdgeWorkers log messages to all event handlers.
👍 You can also use format specifiers to add dynamic data to the log messages.
-
Activate your EdgeWorkers code bundle that now includes the built-in log module.
-
To view the log data you can use this curl request that adds the
Pragma: Akamai-X-Ew-Debugand theAkamai-EW-Traceheaders. These headers retrieve the logging information.
This example lists the corresponding logging response header for each event handler. A response header is only returned when logging information is available for the event.
- You can also use the
akamai-x-ew-logheader to specify the log level. The available log levels, in ascending order of severity, aretrace,debug,info,warn, anderror. In the request header below,akamai-x-ew-log-level: error, specifies that error level messages should be included in the logs.
Enable JavaScript logging for responseProvider
JavaScript logging for the responseProvider event handler includes a multi-part response. It consists of the expected response body followed by an additional section that contains the responseProvider debug fields.
With streamed responses, this information is not available until the event handler ends.
📘 For
responseProvideryou need to add the Pragmaakamai-x-ew-debug-rpheader that enables the multi-part response header. If theresponseProviderevent handler is not implemented, a status of UnimplementedEventHandler will appear in the standard trace header.
-
Make sure that you’ve enabled enhanced debug headers and added the built-in log module to your EdgeWorkers function.
-
Here’s a curl request that adds the Pragma
akamai-x-ew-debug-rpmulti-part response header and theAkamai-EW-Traceheader to retrieve the JavaScript logging information:
In the multi-part response output below, the original body is separated from the trailing debug information by the j50cx0rLZHkfMieMHdE7HM randomized boundary string.
- You can also use the
akamai-x-ew-logheader to specify the log level. The available log levels, in ascending order of severity, aretrace,debug,info,warn, anderror. In the request header below,akamai-x-ew-log-level: error, specifies that error level messages should be included in the logs.
Use DataStream 2 to deliver the JavaScript logs
For complete instructions that include how to set up a DataStream 2 stream and a log destination, refer to the Use DataStream 2 to deliver JavaScript logs tutorial.
- Import the log built-in module in the
main.jsfile. The log built-in module logs messages generated during the current request.
- Add the logging parameter to the
bundle.jsonfile. You can set the JavaScript logging level in the code bundle. By default, EdgeWorkers logs are set to ERROR.
Use theds2idyou created to stream the logs. For more information see, Use DataStream 2 to deliver JavaScript logs.
You can also use EdgeWorkers CLI to change the log level.
Add dynamic data to log messages
You can also add dynamic data to your logging output. For example, you can include information such as JavaScript variables or information about the specific request.
📘 Make sure that you do not include sensitive information in the log messages.
When adding data to your JavaScript log use variable substitution instead of manual string concatenation or string templates. Variable substitution is recommended for performance reasons.
-
JavaScript logging supports the WhatWG open specifications to enable variable substitution.
You can use these format specifiers when using variable substitution to add data.
- This example imports the built-in log module and includes information about the host, method, and path used during the EdgeWorkers
onClientRequestevent handler.
- This curl request that passes the Pragma
akamai-x-ew-debugand theAkamai-EW-Tracetoken to the web site https://www.example.com.
This example shows that the log provides information about the host, method, and path used during the EdgeWorkers onClientRequest event handler.
JavaScript logging for subWorkers
Each EdgeWorkers event can generate a 1 KB log. This means that a single subWorker invocation can potentially generate a 4 KB log. This makes logging the largest contributor to the subWorkers debugging response headers.
If your log response headers are hitting these limits, making it difficult to debug a particular subWorker, you can specify the akamai-x-ew-subworkers-log request header. The value of this header should be a comma separated list of the EdgeWorker IDs you want to include in the logs. Any EdgeWorkers not on this list will not produce log headers for the request.
This request specifies a single EdgeWorker ID to log akamai-x-ew-subworkers-log: 809212161.
This request specifies multiple EdgeWorker IDs to log akamai-x-ew-subworkers-log: 809212161,29671799.