Hello, everyone!

We are working hard to provide you with better observability for your applications. Thank you for your support and trust in our expertise so far. Today, we’re taking another step to improve your experience with Thundra. This new update enables Thundra to detect and warn you about issues in your Lambda functions without any configuration needing to be made by you! For this feature, we added a new item on our left-hand menu called "Error Inspector." Let's take a closer look at the newest update!

When you start a workday, the first thing you most likely do is check your application's status. The "Error Inspector" page gives you insight into the issues in your Lambda functions with just a quick glance.

We can constantly check your Lambda functions for any errors without any overhead. There is only one thing you need to do: Integrate with Thundra via CloudWatch integration or manual intrumentation. After that, we will handle everything! You can learn how you can integrate with Thundra to your account using the information we provide in our docs.

When an error occurs, it will be automatically listed on the Error Inspector page. By clicking on an error to expand its details, you can have more insight to understand what happened. When you select an error, a histogram is created that displays the frequency of the error within a time range. Below the histogram is a list displaying the last five invocations that occurred, and to the right is an error stack trace for the latest invocation.

If you want to be notified when this error occurs again, you can easily enable notifications for channels such as Slack, email, Opsgenie, and more. Should you set up a notification but don’t want to receive notifications for a while, you can also disable the notifications option. This will mute your notifications until you decide to enable them again.

Some issues are not as important as others. In these instances, you may want to discard them for a while or permanently, which makes resolving these issues a good idea. A resolved error is displayed as grayed-out on your errors list. If you have set a notification for a resolved error before, you will receive a notification when it occurs again.

Get started and check out the Error Inspector feature today! If you have any questions or would like to provide feedback, use the chat bubble to connect with us.

Hello, everyone!

Today we're very excited to share a brand new feature of Thundra! As you may know, Thundra helps you monitor your applications using traces, metrics, and logs. With today's update, we’re extending our monitoring features with the new APIs menu. 

APIs are usually the most significant part of an application, as they’re the bridge between users and our backend application. To keep your application stable, you need to be aware of metrics such as health, latency, and throughput on your APIs. It is now as easy as winking to monitor your AWS AppSync with Thundra. 

There is only one requirement to start monitoring your APIs: Thundra's CloudFormation Integration. If you start your Thundra journey after reading this post, all you’ll need to do is select the "Monitor AppSync APIs" option at the last step of onboarding. 

If you already have an account on Thundra, monitoring APIs is disabled by default. To activate this feature, go to the AWS Tab on the Settings page, click on the AWS account that you want to configure, and then select the APIs that you want to monitor. You can get more detailed information in our docs.

On the APIs page, you’ll find a list of your AppSync APIs that gives insight into their situation, including throughput, errors, and latency. Moreover, when you click on an API in the list, you can see which endpoints the API has and the requests that endpoints received. Don't forget to check metrics to find even more information about your API's state, including status and duration.

Please don't hesitate to provide feedback on what you think about this new feature. You can reach us by clicking on the bubble at the bottom right of the page!

Hey everyone,

We have some news about the latest improvements in Thundra! As you may know, you can integrate Thundra to your AWS account using an AWS CloudFormation stack that we provide to you. This stack actually sets up subscribers to the log groups of your functions to gather insights about those functions. Our easy-to-install CloudFormation stack has been helping our users monitor, debug, and secure their AWS Lambda functions with just one easy step. However, we realized that there can be redundant functions that aren’t really important to monitor, functions with data that you don’t want to share, or some functions that you created only for testing purposes. Today, we are happy to announce that you can select which functions Thundra will subscribe to during the onboarding process, and then at a later time on the Settings page.

While onboarding, and after the AWS CloudFormation stack is created, you can see all of your functions on your AWS account. This is when you can select functions that you want to monitor with Thundra. Note that Thundra will start polling logs only after you specifically select the functions. So what happens when you create a new function? You can make sure that Thundra will also subscribe to new functions by checking the "Autosubscribe to new functions" box at the bottom of the page. (See the image below.) Similarly, you can uncheck that box if you want Thundra to monitor only the functions you specified. 

If you already have an account on Thundra, you can go to the AWS tab on the Settings page to connect your Thundra account to your AWS account. You will follow the same steps we described while connecting your accounts on the Settings page.

After you connect your account and subscribe to AWS functions, you can see them on the Functions page. If you forget to subscribe to some functions, don't worry! You can always go to the AWS tab, select the AWS account, and manage your functions from there. On the AWS Account Details page, you are able to:

• Subscribe/Unsubscribe AWS Lambda functions,
• Enable/Disable auto subscription, and
• Give alias to the AWS account on Thundra.

Please let us know what you think and give us feedback using the chat bubble at the bottom right of this page!

Hi everyone, 

I hope each and every user of us are healthy and safe in these unprecedented times. While we are working from home, we continue delivering new improvements for Thundra. 

We're so happy that some of you are already using the function and invocation tags extensively to enrich Thundra observability data with your business context. (See this blog for reference). In order to make the usability of tags in Thundra even easier, we've added a new navigation improvement. From now on, you can search the invocations and functions by clicking on a tag when you see it in function or invocation details.

In the invocation below the tag named "http_status" is set to 202. 

Clicking on this tag will filter all the functions of "blog-site-dev-postBlogPost". In this way, you can filter out all the other occurrences of the same business logic automatically. 

To learn how to use tagging, please consult to the documentation for Node.js, Python, Java, Golang, and .NET.

Happy observability to you all!
Stay safe and healthy!

Hi everyone, 

I hope each and every user of us are healthy and safe in these unprecedented times. While we are working from home, we continue delivering new improvements for Thundra. 

As you know, we are listing all logs of all functions under the Logs section that can be reachable on the left panel.  Previously, search capabilities on this page were limited and you couldn't save the searches that you made even if you run a search once. In order to resolve these issues, we've improved our Logs page by adding a query bar powered by our query language and added the ability to save the queries.  

Now, you can run extensive queries on your logs and you can even make a free text search on the logs of your functions. Then, you can save this search to revisit fast when you need it again. 

Happy observability to you all!
Stay safe and healthy!

Hi everyone, 

I hope each and every user of us are healthy and safe in these unprecedented times. While we are working from home, we continue delivering new improvements for Thundra. 

As you may notice, you're capable of using a comprehensive query language in order to filter and sort your observability data on Thundra. However, this query language lacked an important feature and some of you have asked about adding it. We heard you and added this feature today. Now, you can add negations to your queries from Thundra console and query helper while filtering and sorting invocations, functions, operations, traces, and logs. 

For example, you can type the below query to filter out the Java functions while you're searching for functions. 

Runtime NOT java ORDER BY LastInvocationTime DESC

Same can be achieved in the query helper as below: 

Note that you can now set up new alerts by using this new addition to our query language. 

Happy observability to you all!
Stay safe and healthy!

Hey everyone!

We have some news for you. As you may know, you can invite as many colleagues as you want to your Thundra account and gather your own team. While gathering up your team, members can have permitted capabilities based on the role they are assigned. Three different types of roles were already provided on Thundra to monitor, secure, and debug your applications.

However, some of our customers asked for the ability to invite a non-technical person to Thundra whose sole role involves payments and invoicing.

Today, we happily announce a new role for your team members who are responsible for finances: the Billing Admin Role. Team members who have this role can manage payment and plan information on the billing page, and won't be able to see any other technical information on Thundra. They will also be able to receive invoices for payments.

Please don't hesitate to provide feedback and feature requests to support@thundra.io or to our Slack channel.

As you may know, we are already have the capability of listing all the traces that your modern architectures generate. You may ask what I mean by trace. Trace is the chain of several applications(AWS Lambda or container app) that achieve a job which generally maps to a business flow in an event-driven architecture. It's advised to use such event-driven architectures so that a single error don't cause the whole system collapse. I know we have many customers already adopting event-driven architectures but it's better to give an example about it once again.

In the above figure, you see a distributed business flow in which a particular business objective is completed. Let’s walk over those operations one by one: 

1.  The blog application should immediately display a message explaining that the post is saved and will be reviewed by editors. 
2.  The new blog post is ingested into an SQS queue. 
3.  A worker Lambda consumes from SQS and publishes a message to SNS to notify the editors. 
4.  The same Lambda saves the blog post so that it can be used for review by editors.
5.  From the DynamoDB record, another Lambda gets triggered and writes the content to an Elasticsearch table with necessary indexes so that it can be searchable among millions of blog posts.

This flow occurs every time when a new blog post is submitted. We were listing all of these occurences as a separate instance and you were not able to keep the track of your KPIs about this particular business flow. Until today!

Today, we are introducing Unique Traces proudly to address this problem. Now, we automatically discover and list all the unique flows that your application is performing and see the most important KPIs about these such as the average or 90th percentile duration, number of errors and so on.

You can reach out to this new menu via this link. When you want to see the individual traces of the unique business flows, just click on those to filter that.

Please let us know what you think and provide feedback using the chat bubble on the bottom-right of the screen.

As you may know, we make an effort to provide you a better observability and security solutions with every step we take everyday. Today we're excited to announce our new offline debugging solution for your Lambda functions. You've already a chance to dive into your function code line-by-line on Thundra but with a new Offline Debugging update, we bring a cool IDE-like view for more debugging experience.

Methods with offline debugging configuration have an IDE view with function code under trace chart span like image above.

Using previous and next buttons on offline debug IDE, you can traverse function code and watch how the values of local variables change. Furthermore, like any other debugging tool, you can jump into the child method or resource within your function code by using Jump In action. In contrast, Jump Out will help you to return where you left off before Jump In.

Functions without offline debugging configuration also have input and return parameters in a simple IDE view. However, with a little generic configuration, you can step into Offline Debugging capability as explained here.

Offline debugging is now available for Java, Python and Node.js runtimes. In order to use our Offline Debugging feature, you'll need to update your Thundra libraries to the newer versions as follow:

• Node.js: 2.8.0, layer 36 or higher
• Python: 2.4.4, layer 19 or higher.
• Java: 2.4.9, layer 39 or higher.

As you may know, the Architecture page offers a visualized representation of your serverless architecture. Today, we are excited to announce that you can discover throughputs and errors of the resources in your serverless architecture at a glance with the latest update of Thundra's Architecture view page.

When you take a look at your serverless architecture in Thundra, you can quickly see that the nodes (resources) are in different sizes. This visualization helps you differentiate the nodes by throughput. For example, if a Lambda node has bigger size than the other ones, it means that Lambda function has been invoked more than the others.

Some nodes in a serverless architecture may be framed with colors in Thundra's Architecture view page. This is intended to help you identify the erroneous resources effortlessly. The color of the frames of nodes fades to red from yellow in accordance with its error count increment.

In addition to the color-coded visualization, the edges between the resources have been updated as well. Until now, the edges only expressed the health of the interaction between resources with its color-coded design. With this feauture update, the edges also highlight the number of interaction between the resources by its thickness. Now, you can easily see the most interacted resources when you have a look at your architecture. For instance, if your Lambda function interacts with a DynamoDB table more than an S3 bucket, the edge between the DynamoDB table and the Lambda function is thicker than the other edges.

This new feature update enables you to stay on top of your serverless system by depicturing how it works, where are the bottlenecks, and how resources interact with each other in your serverless stack at a glance.

Happy observability!