Serverless is eating the backend market right now, and for good reason.
Back in the days, before “the cloud” was a thing, getting a server was a chore. Even if you weren’t in charge of buying and setting up the machine, you’d still have to discuss matters with your operations team, which could take days, weeks, or even months.
Then came cloud providers like AWS and changed the process dramatically. All it took were a few clicks in their web console and you had a pre-installed server.
The serverless paradigm tries to take this a step further and eliminate the other necessary tasks, like updating operating systems or scaling up and down with different virtual machines. With Function as a Service (FaaS) solutions like AWS Lambda, you can start small and go as big as you need.
If setting up a whole virtual machine would be too much hassle, you can begin with small tasks. Just write a function for the task, put it on a FaaS platform, and let your cloud provider handle all the hard work of maintaining infrastructure. As you put more workloads into Lambda step-by-step, setting up a virtual machine becomes a thing of the past, and you’re ready to go all-in on a big new project.
How does Thundra fit in here?
Thundra is an observability solution that was built from the ground up for the serverless paradigm. It keeps track of the whole serverless spectrum, from aggregates of distributed systems down to the code that runs in your FaaS environment. Thundra provides one tool for all your serverless monitoring needs, no context switches necessary. Moreover, Thundra is constantly improving its service offerings for security and serverless architectures.
Setting Up Thundra for AWS
Thundra integrates with your AWS account in two ways: You can “connect Thundra” via a CloudFormation (CFN) stack, which gives you basic information about your serverless systems, or you can “instrument Lambda functions” directly, which gives you advanced insights about your architecture.
Connecting Thundra
When you connect Thundra, it deploys a CFN stack to your AWS account that will gather monitoring data via CloudWatch logs and send them to the Thundra API. The onboarding process after the first sign-in will run you through this procedure, but you can also start it manually later.
To connect Thundra, go to https://console.thundra.io/settings/aws and look for “Settings” (shown in Figure 1).
Figure 1: Settings in the Side-bar
In the “AWS” tab on the Settings page, you can click on “Add new account” to run the process again. After that, the CFN stack will send your log data to the Thundra service.
Instrumenting Functions
A Lambda function can be instrumented by adding Thundra instrumentation libraries and Lambda layers to it. The basic instructions for different runtimes can be found here.
For the “Node.js” runtime, you’ll need to install the @thundra/core package via NPM, require it inside the JavaScript file that defines your Lambda function handler, and add the thundra-lambda-node-layer to it.
This will let you do offline debugging of your functions and see the Architecture Overview, and trace event-driven transactions end-to-end.
Using the Thundra Web Console
After you’ve connected Thundra with your serverless application, the Thundra Web Console is the main source of information about the system.
It delivers everything from monitoring and debugging information overviews of the whole distributed system to details about your function code.
Architecture Overview
If you instrumented your Lambda functions, Thundra can automatically generate an architecture overview (AO) for your serverless system. You can find this in the Thundra Console in the side-bar on the left under “Architecture.”
The screenshot in Figure 2 displays the architecture of an example project:
Figure 2: Architecture Overview
The icons represent the different AWS services and the arrows the flow of events between them. The sizes of the arrows and icons can vary with the number of events that happened in the selected time period. Use the “Filters” menu to adjust the information displayed.
In the example system, you can see at first glance that many more users search our blog than write new blog posts because the icons and arrows are much bigger. You can also see the timing information of our Lambda functions and how often they were called and called other services.
End-to-End Tracing and Debugging
The AO shows an aggregation of all call traces in the system, but sometimes it can be useful to look at only one of these traces in detail—for example, when debugging, searching for performance bottlenecks, or checking what services are used by a specific business case. Tracing is a way to monitor how different parts of your application work together. A video explaining the process can be found here.
To look at one trace in detail, click on an arrow that leads to a Lambda function. The selected arrow will be grayed out and a detail view will open on the right.
The screenshot below shows an example selection:
Figure 3: Example Selection
You can find a list of all invocations of our target Lambda function by scrolling down from the detail view on the right. To navigate to the Invocation Detail (ID) page, click on the relevant invocation.
At the top of the ID page, you will see a “Found in 1 Trace” button. This leads to the trace of our invocation, basically a simplified version of the AO. A trace shows the whole lifecycle of a message from one end of your architecture to the other, what services are involved in its processing and how the message is transformed to meet a specific use-case of your system. You can also click on the arrows to get even more details.
If you scroll down on the ID page, you can find the trace chart of the selected invocation, which shows how long the Lambda function ran and how its sub-methods and other services contributed to that runtime.
Offline Debugging
One feature unique to Thundra is offline debugging, which can be found on the ID page. If you click on a “Method,” you see the actual code and can even walk through it line-by-line.
Let’s look at the following screenshot of this offline debugging view:
Figure 4: Offline Debugging View
On the top left is the “Method” that you click to open the debug view.
The debug view shows code highlighting, variable values at every step of the invocation, and debug controls to go back and forth through the code.
You can go through every invocation of your Lambda function step-by-step to compare the differences and find out why some invocations led to errors.
This allows you to see exactly what happened in your system when an error occurred.
Why You Need Thundra
To summarize, Thundra enables you to troubleshoot and debug applications quickly by reducing context switches between different tools. Not only does Thundra display the whole picture; it also allows you to drill down to the state of one variable in one invocation of one of your Lambda functions with just a few clicks. With a few clicks, you can see what services are used in your system, which business cases use them, and how much traffic goes to them, making it much simpler to find performance bottlenecks and errors.
Additional features not discussed here include cost management; automation of continuous configuration, enforcement, and verification of security and compliance controls; using fine-grained cardinality to understand application behavior; and integration of alerts and actions with workflows and systems.
Thundra provides a very generous free plan that can keep your personal projects monitored for free. You can sign up directly from the console or start your subscription over AWS Marketplace so that if you ever switch to a paid plan, the cost will be added on top of your AWS bill.
Top comments (0)