Logging and Monitoring
The AIO
CLI offers a number of tools you can use to debug your actions while running them on Adobe I/O Runtime.
You can retrieve the latest activations in a namespace by running:
Copied to your clipboardaio rt:activation:list
Having an activation ID, you can retrieve the activation result running:
Copied to your clipboardaio rt:activation:get <activation ID>
If you send data to logs from your actions (using console.log()
in your code), you’ll get this information as part of the activation record, inside the logs
field. The shortcut command to get the logs is:
Copied to your clipboardaio rt:activation:logs <activation ID>//output sample2018-11-14T22:23:00.002Z stdout: 1542234180001: param = John Doe
Retrieving Activations for Blocking Successful Calls
At scale, when you run millions of activations in a day, it may be difficult to extract the activations that failed in order to debug them. To help with this task, the system skips persisting the activation that succeeded.
The exceptions are asynchronous actions that are invoked in a non-blocking fashion. Their results are persisted regardless so that you can extract the response of the action at a later time.
However, during development it is important to have access to all activation results. You can enable this by setting in the request the extra logging header to on
:
Copied to your clipboardX-OW-EXTRA-LOGGING: on
It's not recommended to use the extra logging headers in the production environment as invocation performance can be impacted.
Understanding The Error Codes
When you have action invocations that fail, sometimes the best way to understand the reason behind the failing is to take a look at the error object part of the activation record - running aio rt:activation:get <activationId>
you will get the activation record.
The following are the possible values and the meaning for error
in response.status
:
success
: everything is okay (status is true)action developer error
: A container or action code error occurred, e.g. failed to start action (status is false). This is usually the case if the nodejs action code has a syntax error or missing dependenciesapplication error
: Action ran, but there was an error thrown in the action code (deliberatly or not) that was handled by I/O Runtime (status is false).whisk internal error
: Action did not run, an internal I/O Runtime system error occurred while starting the action, more info inresponse.status.result.error
3rd-Party Tools
I/O Runtime doesn’t offer a configuration to send activations and logs to an external system, something like Splunk, Datadog or New Relic. This is something we are considering to offer in the future.
Although there is no out-of-the-box integration, there are still ways you can push data from I/O Runtime to an external tool in order to monitor and debug your actions.
Epsagon
One tool that made it easy to do this is Epsagon. Epsagon built an integration for OpenWhisk based systems (I/O Runtime is built on top of the open source project OpenWhisk) that makes super easy to see your activations, errors, latency information and logs in their system. Check this guide or this video presentation if you want to find more.
New Relic
Another tool that can be used to monitor your actions is New Relic, which offers a Node.js agent that can be used to monitor your actions. Check this guide to learn more.
For example if you want to send to New Relic the execution time for one action, you could build your action code as follows:
Copied to your clipboardconst newrelic = require('newrelic');function main(params) {const start = Date.now();// your action code hereconst end = Date.now();const durationInMilliseconds = end - start;// send duration to New Relicnewrelic.recordMetric('Custom/RunEndpointDuration', durationInMilliseconds);}
You need to package the new relic agent as part of your action code and deploy the action as .zip file.
Debugging Locally
Check this page if you want to learn how to debug your actions locally.