Thundra provides best-in-class observability and troubleshoots your applications from the beginning. With a combination of automated instrumentation and the ability to inject manual instrumentation, Thundra provides you with rich observability data to ask questions when you face performance slowdowns or other issues.
When an application is in production, there could be many operations, invocations, or functions, such as calls to databases or third-party APIs, or any other AWS services. If there are any issues, you’ll need to know about them and fix them as soon as possible to keep your application stable. Thundra offers a rich querying and filtering mechanism so you can search and monitor your application data.
Thundra Query Language
When you visit the Thundra console pages with tabular data, you’ll see a query bar at the top of each page. You can write a query in this bar to filter your application’s observability data, produced by Thundra. Thundra’s query language is similar to SQL and easy to understand.
Figure 1: Thundra’s Functions page, filtered with a query
You can be very creative while writing queries, because you can mix and match different filters and statistical operations. Even though filtering options can change for different listings in Thundra, Thundra Query Language has a basic format of
Key = Value. For example, if you want to filter your Lambda functions in the eu-west-1 region, you would write
Region = eu-west-1 on the Functions page.
It is not enough to use exact values for some statistical operations, such as finding unique traces whose trace count is greater than a certain threshold. For these types of filters, you would use aggregations and mathematical operators. For example, you can find unique traces that have erroneous traces with a
COUNT(Error) >= 0 query.
Get Help with Query Helpers
It’s very useful to have a query language that you can extend according to your needs, but if you’re not a technical person, it can be complicated to filter application data. Thundra does not assume that you know SQL-like languages, so it provides Query Helper to make it easy to write queries.
Figure 2: Query Helper filters function data on the Thundra console
When you click on the query bar, Query Helper is automatically displayed.
Filters are organized into separate categories, such as statistical filters or function filters, to guide you in selecting the correct options.
- Classification filters - These filters change according to the screen where you filter the data. You can find function name, resource name, region, or runtime filters under this category. Logical operators such as erroneous, cold-start, or timeout are also included in this section.
- Tag filters - Thundra provides you with custom filters for your applications and invocations. If you want to learn how to use these tags, you can get detailed information from Thundra’s documentation for Java, .NET, Python, Node.js, and Go. Select available filters and search through your functions or invocations by their tag values.
- Resource tag filters - There can be different types of resources in your application. If you want to filter your traces or operations that belong to a specific resource, you can use resource tag filters. For example, you can find business flows that are triggered by an API GW by writing
trigger.type = AWS-APIGateway.
- Statistical filters - Using aggregations under statistical filters, you can filter your observability data with some numerical operations. You can find AVG, COUNT, or P99 type aggregations in statistical filters for duration, erroneous invocations, or traces.
- Sort filters: Thundra offers sort operations according to start time, execution time, or other related parameters.
For some concrete examples, please see below. For each type of observability data, such as functions, operations, or traces, you can find a “Cheat Sheet” in the Query Helper. Open the “Cheat Sheet” and run the queries with one click.
Below are a few real-time examples you can use while querying your application data in Thundra.
Let’s say you need to find erroneous functions in the “user” service in your application. Here is what you should write:
appTags.serviceType = “user” AND COUNT(Erroneous) > 0 ORDER BY COUNT(Erroneous) DESC
When you perform this query, Thundra will list problematic “user” functions. Let’s now dive deeper into the most erroneous one. You can find the latest erroneous invocations for a specific user with the following query:
Tags.user_id = “1” AND Erroneous = true ORDER BY StartTime DESC
You can click on a problematic invocation to see what happened.
If your function can be triggered from different resources and you need to find the invocation with the highest latency for a specific resource trigger, use this query:
tags.trigger.className IN (AWS-S3) AND Duration >= 500 ORDER BY Duration DESC
Thundra provides business flows under unique traces. You can find out if something is going wrong for a flow from the Unique Traces page. Let’s find the erroneous flows that are affected by the latency in an AWS DynamoDB:
resource.AWS-DynamoDB.duration > 1000 AND COUNT(Erroneous) > 0 ORDER BY COUNT(Erroneous) DESC
Select the most erroneous one to display traces of the unique trace.
If you want to look from a more detailed perspective, Operations queries are the best fit. When you need to find slow DynamoDB operations in your application, this query will help you:
Duration > 5000 AND ResourceType = AWS-DynamoDB ORDER BY Duration DESC
Target and Find Meaningful Observability Data
Thanks to the highly extendable and configurable Thundra query language, you can easily find whatever you want within a lot of observability data. Thundra queries provide you with a better understanding of what’s going in your application. With Thundra’s query capability, you can:
- Ask and find your answer in function, invocation, operation, trace, or log data.
- Save your queries for the future or share them with your colleagues.
- Set alerts and be aware of bottlenecks in your application.
You can get started with Thundra for free and have rich observability data for your application, then dig into the data using Thundra queries. Sign up directly from the Thundra console or start your subscription from AWS Marketplace. If you upgrade to a paid plan, the cost will be added to your AWS bill.