First, heads to all our beta customers. In order to see data in the Thundra Web Console and take advantage of our GA features, you need to update your existing agents. Currently, all beta agents send data to “beta.thundra.io”. However, this platform will be discontinued by November 1st. We recommend that you immediately update your agents to the latest versions, which will allow you to receive data in console.thundra.io.
Thundra started its journey almost one year ago as an insider tool for OpsGenie. Our engineers added Thundra artifacts to their project to understand what was happening with their Java functions in the AWS Lambda environment. Throughout its evolution from a single library to a complete product, we gathered tons of customer feedback and used that feedback to tailor our product. Finally, we are proud to release Thundra as a generally available and officially supported product, with support for AWS Lambda functions written in Node.js, Python, Java, and Golang.
With this new GA release, we focused on greatly expanding our support for applications written in Node.js. You can now dig inside your Node.js invocations and pinpoint the latencies or potential errors. This allows you to easily optimize your functions and ultimately pay less for your AWS bill. Importantly, you can use observability to anticipate critical issues and fix them before they put your system health at risk.
Here is a summary of the new capabilities we’re including with the GA release:
Detailed tracing for Node.js applications. Understand the request-to-response path of your Node.js invocations in detail with support for end-to-end tracing, including interactions with external services.
Add monitoring without touching your Node.js code. Add detailed observability to your Node.js applications without needing any code changes via automated instrumentation.
Reduce data volumes with data sampling. Configure Thundra to collect data only periodically or when there’s an anomaly through data sampling
Keep your private data private with the ability to mask sensitive data
OpenTracing compatibility for Java, Node.js and Python agents are now available. This allows you to use the common standard for tracing AWS Lambda applications with Thundra.
Automated instrumentation with Python is also now available. You don’t need to pollute the business logic with monitoring. Just add annotations to the functions and start tracing your function.
Let’s dig into a more detailed explanation of each one.
ZERO CODE CHANGE MONITORING WITH NODE.JS (AUTOMATED INSTRUMENTATION)
Best things first! From now on, you don’t need to change any code in your business logic to add observability to your Node.js functions. Just configure Thundra outside and apart from your business logic and it will collect traces, metrics, and logs from your functions. After that, Thundra will aggregate the data together into a single view for your analysis within the Thundra Web Console or in one of our integrations (like Splunk), allowing you to easily understand what’s happening under the hood. All you need to do is to install Thundra libraries and wrap your functions with Thundra. Then, you can configure Thundra for tracing using one of those approaches:
Configuration with environment variables, where you simply add tracing to your system without needing to re-deploy your function. Just set `thundra_agent_lambda_trace_instrument_traceableConfig` to a trace configuration and you will see the resulting data in the Thundra Web Console or in your integration platform. Check out our documentation for more information.
Declarative configuration, where you define your trace configuration as a JSON object. You then pass this object to the Thundra wrapper. Check our docs for more information.
Programmatic configuration, where you define your trace configuration as a variable at the top of your code before your business logic and push the necessary tracing settings to this variable. Again, just pass this variable to the Thundra wrapper. Instructions on this approach can be found here.
Automated instrumentation is cool only if it’s used to collect helpful data, such as traces. Traces can be used to understand how an invocation is executed throughout your AWS Lambda environment - and beyond! A big contribution to errors and performance issues in serverless isn’t typically due to your function’s code but often caused by the resources that your functions are interacting with. Because of this, it is critical to understand how your AWS Lambda functions interact with other system resources such as AWS DynamoDB, other relational database tables, HTTP endpoints, or SQS queues.
With our GA release, you can now collect detailed tracing information for your Node.js serverless applications, such as:
Method arguments and return values, allowing you to debug what is happening with your variables in the function.
Relational database queries, allowing you to understand if there is a bottleneck in your database design or if there is an inefficient query slowing down your function. You can read more about how to identify and solve these types of issues with our blog about how you can identify the tricky “n+1 problem” (inefficient query) with Thundra. Queries to DynamoDB tables so that you can figure out if your function hits the read/write limit of Dynamo with queries.
HTTP requests to endpoints so that you can understand which URLs are responsible for the slowdown or even failure of your function.
Communication with SQS queues and SNS topics, allowing you to trace read/write operations and durations to understand if your functions get stuck while interacting with these resources.
Redis operations, allowing you to figure out if there is a stale data because of an unsuccessful cache invalidation.
With these additional comprehensive tracing capabilities, you might be worried about having to handle larger volumes of Thundra data. If high data volumes are a concern, we are happy to offer you a way to reduce data volumes while still being able to effectively monitor and observe your serverless application performance via our data sampling capabilities for Node.js and Java applications. You can configure your sampling to collect trace and metrics data, for example, every 10 minutes or every 1000th invocations. You can adjust the frequency according to your need. Moreover, you can also configure the sampler to send the trace and metric data only if there is an error in the function.
We understand that you might want to keep your sensitive data private. With our GA release, you can now mask the request and response your Java or Node.js function generates before sending monitoring data to us.
AUTOMATED INSTRUMENTATION WITH PYTHON
Python is the runtime we always love. That’s why we are also giving great importance to improve our Python agent. Now, we are supporting the automated instrumentation of Python with Thundra. Thanks to this, you can start instrumenting your Python functions of AWS Lambda with no code change. Just add the Thundra’s `Traceable`annotation with the necessary tracing configurations. You can trace the request and response and the errors occurred in function with no code change. Please visit our documentation for more information.
OPEN TRACING COMPATIBILITY
I want to share is big news for both us and the larger serverless community. As of GA, all Thundra agents are OpenTracing compatible. We place great importance on community-driven core concepts of instrumentation and believe in supporting this standard. With new OpenTracing compatibility, You can now start and close your spans, tag them with as many tags you want and add custom values to the span.
We are excited to help the serverless community with more and more capabilities day by day. We will continue to come up with great features in the future. If you haven’t already, please play with our totally open to all, interactive environment to see what types of insight you can gain from serverless observability. And, try out Thundra with your own applications using our free 14-day trial.
If you want to socialize with Thundra team, join our community Slack.