Hey everyone,

Thank you for trusting with our observability skill set till now! Today, we are expanding our offering with new security insights and actions. We are at the same time expanding our offering for containers and VMs (only for Java. We will explain this one separately).

We are replacing the existing “Architecture” view under function detail with this update. In this view, you’ll be able to see the security violations if any and set up a new security configuration. 

When you want to configure the security functions, you have two options that are namely whitelisting or blacklisting. As the names suggest, whitelisting allows access to specific set of resources and prevents any other stuff while blacklisting prevents access to specific set of resources and allows any other stuff. Whitelisting is best for retaining the existing architecture while blacklisting is best for restricting access to potentially malicious endpoints. 

When you decide to go with whitelisting, we are coming up with a list that includes existing resources automatically whitelisted. In this way, you don’t need to input all your existing resources manually. You can add new resources that you can potentially reach in the future. In the following image, we are whitelisting all the existing resources and also adding any type of S3 operation, and READ operations from SNS to the whitelisted resources. This way guarantees that our function won’t be able to reach any other resources but only the listed ones. 

When you’re done defining your policy, you can add the action that Thundra wants to take when any violation occurs. You can either let any violation occur and get notified about it or you can be more restrictive and block them in the first place. Note that if you change your logic in the function and forget to remove your security policy in Thundra, you can face problems because Thundra will block your new business logic. So, be careful using the blocking actions. If you are using our AWS integration, you can pass the security policy to your function with no code change but with a single click. In this way, we will update your function configuration with an environment variable. If you are not using the AWS integration or you want to apply this security settings , you can still secure your function by simply downloading the Base64 format and assigning the file content to the environment variable called thundra_agent_lambda_trace_span_listenerConfig.

In case of any violations, you’ll receive an email to your account about it. In order to change your notification preferences about security alert policies, you can find the related policy in your alert policies page, and add new notification preferences.

In order to use our security features, you'll need to update your Thundra libraries to the newer versions as follow:

• Node.js 2.7.0, layer 30 or higher
• Python : 2.4.1, layer: 16 or higher.
• Java: 2.4.6, layer 37 or higher.
• .NET: 1.6.0, layer: 3 or higher.

Please ask any questions and provide any feedback using the chat bubble. Happy serverless-ing!

Today, we are very happy to come up with a dynamic dashboard with active anomaly detection on the most used metrics. This is the first update of many that we will deliver in the following days.

Our dashboard aims to make the macro metrics clear while making the tiny details accessible. Using that; you can switch between projects and see the high level metrics at top-left. Just next to it, you can see the alerts and insights (this is also new coming with this update). Insights can show you discrepancies in your serverless architecture even if you didn't set up an alert for that.

At the second row of the dashboard, there's the "Function List" that can show most unhealthy or most costly functions sorted. We want you to check if there's something unexpected in your system. When you click on one of the function there, the charts just right of the functions' list will be updated.

Oh.. yes charts! These charts are first successful result of our work for weeks. You can catch if there's any anomaly in your invocation count, error count and average duration metrics for all functions in a project and for a particular function.

In serverless, it’s normal to see ups and downs because it’s mostly used for unexpected load, right? But even the most unusual graphs have a trendline if you look close/far enough. We are providing a trendline analysis for the metrics of your functions to detect the points that will go outside of the general trendline.  We are basically making a trend analysis in the data by using several parameters. We are using two variables in our calculations of the trend that are namely “period” and “rollup”. “Period” is basically the recurring pattern of your data. For example; the invocation count of your function can go very low on weekdays but can go crazy high for weekends in a normal recurring condition. In this case, it’s advised that you use the period as “week”. “Roll-up” is the period of data to make our aggregations. When you select 5 minutes as a roll-up interval, we’ll aggregate the metrics in 5 minutes into a single metric and consider (or not consider) it as an anomaly.

You can try this new feature from here and provide your feedback from the chat buble at bottom-right of the screen.

You can now create incidents from your Thundra alerts on ServiceNow.

In order to use this new feature, please follow following steps:

1. Create an integration user with restricted permissions on your ServiceNow account to later use for webhook authentication.

Login to your ServiceNow instance. Navigate to Organization -> Users using search bar.

Click on New to create a new user for this integration.

Enter User ID, First name and Password fields. Select Active, Web service access only and Internal Integration User checkboxes if available and submit.

Click Edit on Roles tab and add roles itil and rest_service . Click Save.

2. After setup of integration user on Servicenow, go to ServiceNow Settings at thundra console. Enter instance id of your ServiceNow instance. Instance id should include only subdomain. For example, instance id for this https://dev12345.service-now.com/ should be dev12345. Enter username and password that you used for ServiceNow user created for this integration.

3. Press Save and you're done!

Now, you can set up ServiceNow as another notification channel for your current alert policies and for the new policies that you'll create.

Please let us know what you think about this integration and about your new feature requests using the chat buble bottom-right.

Today, we are coming up with an important update for our customers! Recently, we came up with an important update to plug Thundra to your AWS account. When you do this operation, we can list all your functions in the function's list. However, you still need to instrument your functions in order to take most of Thundra such as distributed tracing, architectural view, local tracing and many more. There are many ways to instrument the functions like wrapping the handler, adding the layer, with Serverless Framework or with AWS SAM.

Today's update will enable our customers to handle monitoring with a button click. You'll be able to instrument your functions with a single click from the function list. If you want to disable instrumentation, you can also do this from the same view.

Just select your un-instrumented functions from the list and click on "Instrument"! That's all. In order to let you select more functions at once, we came up with new views for listing the functions. You can switch to Cozy or Compact view to list more functions at once. You can change the view by clicking on the button below.

This update unlocks many possibilities for us like configuring chaos engineering, sampling, masking from the console. Stay tuned for what's coming from us!

Happy observability!

As you may know, we came up with operations search very recently. With this, you are able to query the slow DynamoDB operations, or erroneous Redis interactions independent of the compute platform (AWS Lambda and etc.).

Today, we are adding a new capability on top of our flexible operations search. Now, you can set up alerts on top of the flexible querying. You don't need to think from function perspective, instead, you can create alerts as following:

- Alert me when I have more than 10 DynamoDB read operations to the table "User" with duration more than 500ms in 5 minutes.

- Alert me if I get 404 from any third party API

- Alert me if my PostgreSQL table starts to respond slower.

And many more.. You can start experimenting with operations alerts for our existing alerting integrations with Opsgenie, Pagerduty, Victorops, Slack, Email, and Webhook.

Happy observability!

We know that you are using your advantage to query your functions, traces and invocations. All these ways are very cool but they are all compute centric. Today, We’re happy to introduce this new angle to look at your serverless architecture. From now on, you don’t need to limit yourself from the lens of serverless functions. Instead, you’ll explore wherever in your serverless stack however you want thanks to Thundra’s flexible queries for your operations.

In order to do so, you can navigate to the our new Operations page. There, you'll have a chance of checking your serverless resources from many perspective. For example; you can search for slow operations to SQS or to Twilio.

With this new capability, we are extending serverless monitoring beyond functions to the any resource in your architecture. Please ask any questions about this update using the chat buble on bottom-right!

You can now get notified about your Thundra alerts on VictorOps.

In order to use this new feature, please follow following steps:

1. Follow this guide to setup a rest endpoint integration.

2. After setup, copy the url to notify.

3. Go to VictorOps settings at Thundra console and paste the URL to notify to the field there.

4. Press Save and you're done!

Now, you can set up VictorOps as another notification channel for your current alert policies and for the new policies that you'll create.

Please let us know what you think about this integration and about your new feature requests using the chat buble bottom-right.

You can now get notified about your Thundra alerts on Pagerduty.

In order to use this new feature, please follow following steps:

1. In your Pagerduty account, navigate to the Configuration menu and select Event Rules.

2. Click on Incoming Event Source and then copy Integration Key field to clipboard.

3. Go to Pagerduty settings at Thundra console and paste the Integration Key to the field there.

4. Press Save and you're done!

Now, you can set up Pagerduty as another notification channel for your current alert policies and for the new policies that you'll create.

Note that to be able to configure event behaviour, you should create a new event rule on Event Rules page if you don't already have one. You can filter your Thundra events by setting client equals thundra condition if you would like to create a seperate rule for Thundra alerts. You can read about event rules in here.

Please let us know what you think about this integration and about your new feature requests using the chat buble bottom-right.

Last month, we came up with our alerting feature which enables Thundra users to stay on top of their serverless issues. You can now redirect the alerts to your Opsgenie account and you can set up escalation policies in your organization more flexibly!

In order to use this feature, you need to follow these steps:

1. In your Opsgenie application, go to the team that you want to set up the Thundra integration for.
2. Go to Integrations and press "Add Integration".
3. From the list filter for Thundra and click on it.
4. Copy the field "API Key" to clipboard.
5. Go to Opsgenie settings at Thundra console and paste the API Key to the field there.
6. Press "Save" and you're done!

Now, you can set up Opsgenie as another notification channel for your current alert policies and for the new policies that you'll create.

Please let us know what you think about this integration and about your new feature requests using the chat buble bottom-right.

For a while, you have been able to set up alerts based on your functions and invocations. We are extending alerting capabilities with today's new feature. You can now set up an alert for your traces. With this new feature addition, you can set up alerts for the following cases:

• When the duration of a transaction (composed of chain of invocations) exceeds a threshold.
• When the origin Lambda function or any function in the transaction has errors
• When the duration of the interaction between any specific resource exceeds a threshold. (For example; you can get notified when the duration of interaction for DynamoDB table with name "users" take more than 300ms)

And many more. In order to try the trace alerts, you can navigate to "Traces" page and save the query as an Alert Policy. Please let us know what you think about this feature and what do you want to see in Thundra next using the chat bubble at bottom right or by emailing to support@thundra.io.