When you look at the serverless world, you will see a lot of benefits such as reduced labor cost, reduced risk, reduced resource cost, and increased flexibility of scaling. These benefits don’t come free though, we must accept some of the cons too, for example debugging, cold starts, or vendor lock-in, etc…
We should be aware of this is a new era of infrastructure and it’s slowly maturing. Let’s think about developing a project. When you start coding, I guess that the most important part will be about debugging it. For this reason, we should be feeling free to debug it :) But debugging serverless is very difficult as it is with any distributed application.
Nevertheless, how hard the thorny problems are, there is a solution for them. I had seen the Thundra on a tweet and it looked like a very cool solution for remote debugging even for the serverless world. Today I will try to demonstrate how you can use it easily. This demonstration will be part of the online debugging side.
Firstly you should register to https://www.thundra.io, afterwards, you will be getting a token for debugging. You can also take the token using the Settings page. It will look as below picture.
You have to install a debugger plugin called Debugger for AWS Lambda. I am using IntelliJ but there is one more plugin option for VSCode.
As I mentioned before, you should take a token. This token will be able to ensure connecting to Thundra Broker Host in order to start the debug process remotely. Let’s see it.
After all these configurations are done, we should get to the AWS Lambda Console. We should add some configurations to the console too.
The first one is about custom runtime. The AWS gives us a chance for custom runtime. We can add it as a layer.
The version ARN is supported by Thundra Team. I didn’t deep dive into custom runtime but It maybe adding some environment variables onto custom runtime to open remote debugging or being used JDI over JPDA.
To use online debugging feature, you need to use Thundra layer version
42or higher and change runtime to
We added custom runtime, now we’re adding token using environment variables on the AWS Lambda Console.
The last part of the configuration is about changing the custom runtime. You can change it using the AWS Lambda Console.
Finally, you can start debugging on the IntelliJ with the pre-configured plugin and push the button called Test on the AWS Lambda Console.
When you face performance issues, you can follow the below information. You should select the region that is close to your application that will improve your performance.
Thundra provides a broker host on Oregon by default. Moreover, we support different broker hosts listed below. You can select and set to
thundra_agent_lambda_debugger_broker_hostenvironment variable to reduce latency during debugging session.
debug.thundra.io (us-west-2 — Oregon)
debug-us-east-1.thundra.io (us-east-1 — N. Virginia)
debug-eu-west-2.thundra.io (eu-west-2 — London)
debug-ap-northeast-1.thundra.io (ap-northeast-1 — Tokyo)
2. The debugging process immediately disconnects
The latency can cause this problem. So you should increase the timeout value of your lambda function. You can do it over the AWS Lambda Console.
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
Some useful documentation;
Make sure to increase your function's timeout value when you enable the online debugging for longer debug sessions…