Thundra APM
Search
⌃K

Others

This page is deprecated. You can check the active version from here.

Thundra Debug Client

Thundra provides plugins for VSCode(Nodejs, Python) and Intellij Idea (Java). The Thundra Debug Client can be used for other development environments by supporting remote debugging and acting as a proxy between the local environment and the Thundra Debug Broker.
In the information below, you can learn how to use the Thundra client to debug your Lambda functions on other IDEs. Following the Installation section, see the examples shown for Eclipse and WebStorm to understand how to use Thundra Debugger Client.

Installation of Thundra Debug Client

To install globally run:
$ sudo pip install thundra-debug-client
or to install for current user:
$ pip install thundra-debug-client --user

Synopsis

thundradebug [--help] [-h HOST] [-p PORT] [-a AUTH] [-f FILE]
[-r PROFILE] [-v] [-sp KEY=VALUE [KEY=VALUE ...]]

Description

Options
Description
-h, --host
Debug broker host
-p, --port
Debug broker port
-a, --auth
Authentication token
-f, --file
Configuration file path
-r, --profile
Configuration profile name
-sp
KEY=VALUE [KEY=VALUE ...] Session port mappings in -sp <port>=<session-name> format
example: -sp 12358=default
For each session name, a different port number should be provided.
In order to match the two ends of an online debugging session (your Lambda function invocation and your local IDE), Thundra uses session names. When you enable online debugging in your Lambda function, the session name is set to the predefined value: "default". If you want to use another session name, you can specify it using the thundra_agent_lambda_debugger_session_name environment variable.

Configuration File Format

Configuration parameters to thundra debug cli can be provided by either configuration files or cli arguments. Default configuration is stored under .thundra/debug-client.json in the user home directory. Another configuration file path can be given to cli by -f or --file arguments. The configuration file format is as follows:
{
"profiles": {
"default": {
"debugger": {
"authToken": <set-your-thundra-auth-token>,
"sessionName": "default",
"brokerHost": "debug.thundra.io",
"brokerPort": 443,
"sessions" : {
"default" : 12358
}
}
}
}
}

Eclipse

  • Select Remote Java Application and add a new configuration.
  • Select “Project” and enter a port number to which the Thundra Debug Client will listen. Then click Apply.
When starting the Thundra Debug Client, the port number configured here should also be given as either a command line argument or in the configuration file. For example, if you want to map the session name lab to the port 1111, the client should be started as:
thundradebug -sp 1111=lab
  • Start the Thundra Debug Client provided with the required parameters (authorization token and port-to-session name mapping if you are not using default mapping 12358=default).
Example:
$ thundradebug --auth <your-auth-token> -sp 1111=lab 12358=default
  • Click Debug on the configuration tab.
  • Set a debug point on your AWS Lambda function.
  • Now invoke your AWS Lambda function to hit on the debugging point.
  • The session ends when your AWS Lambda function times out. You can change the timeout value of your function to perform longer debugging sessions.

WebStorm

  • Select “Run - Edit Configurations” on WebStorm.
  • Add a new configuration to “Attach to Node.js/Chrome”.
  • Enter a port number to which the Thundra Debug Client will listen.
  • Select “Chrome or Node.js > 6.3 started with --inspect” to attach to the configuration. Then click “OK”.
When starting the Thundra Debug Client, the port number configured here should also be given as either a command line argument or in the configuration file. For example, if you want to map the session name lab to the port 1111, the client should be started as:
thundradebug -sp 1111=lab
  • Start thundra debug client provided with required parameters (auth token and port to session name mapping if not using default mapping 12358=default) .
Example:
$ thundradebug --auth <your-auth-token> -sp 1111=lab 12358=default
  • Set a debug point on your AWS Lambda function.
  • Select the run profile created for Thundra from the Run Configurations drop-down menu.
  • Click on the “Debug” button to start a debugging session with the selected profile.
  • Now invoke your AWS Lambda function to hit on the debugging point.
  • The session ends when your AWS Lambda function times out. You can change the timeout value of your function to perform longer debugging sessions.