If Thundra gathers data synchronously through Lambda calls, it will create some delay to your Lambda function execution. Remediation is to enable asynchronous monitoring. You can check out this part of the documentation or start directly with our to learn how to set up asynchronous monitoring.
No. Once you set up asynchronous monitoring, our collector module will start to collect the monitoring data asynchronously. According to our benchmarks, we only add 2 ms to the invocation time on average. This is unique to Thundra and we are proud of it.
If you need to send your data synchronously, it'll add a minimal overhead to your application. It's 5 ms on average. We are continuously working to reduce the overhead and you can see our latest benchmarks here.
No. Systems using synchronous monitoring should have a retry mechanism to make sure there is no data loss, as data sending may fail in some attempts. Retries result in latency or there could be data loss if there is no retry mechanism. Thundra solves these issues thanks to its asynchronous monitoring capability.
Yes. By default, request and response of the invocation is not sent to Thundra. You can enable or disable it using environment variables. You can also manage to mask the objects, arguments, return values, local variables by serializing them using programmatic API. You can read more about it here.
Yes. Thundra doesn’t run along with your Lambda function; instead its tracing capabilities are injected to your function and log collection happens asynchronously through Amazon CloudWatch. That’s why VPC rules don’t apply to Thundra with asynchronous monitoring. For all other unique advantages of asynchronous monitoring, check out our blog post: https://medium.com/thundra/4-reasons-why-you-should-publish-monitoring-data-async-in-aws-lambda-fd1e56473941
In Thundra, API keys are required to send monitor data. API keys are used for authentication, identifying requests, and applying rate limiting to the requests (as needed). In order to serve users better, we need to put a limit to number of requests per account. For now, the limit is set as 1000 requests per minute.
Yes. You can create multiple API keys to distribute your total request count to different teams within your organization. Note that the total limit for multiple API keys is still 1000 requests per minute.
In this case, the exceeding requests are simply dropped. If you are using synchronous monitoring, you will face HTTP errors. If you are using asynchronous monitoring, you will see the error logs in CloudWatch logs.
When you hit the limits of your plan, we block your trace data. You can still continue to use Thundra however you can only monitor your invocation data.
When you doubled your limits without using tracing capabilities, you exceed a lot your allotment. That's why we restrict your Thundra usages. Until the next period of your plan, Thundra doesn't accept data and invocation. You can upgrade your plan from the billing page to continue using Thundra.
You can track your usages on the Report tab of billing page.
It takes 1-2 minutes to see your function’s monitor data in the application.
Thundra currently supports Lambda functions in Java, Node.js, Python, Go and .NET. Using the same API key, you can monitor functions in all of the supported languages.
Just join our Slack channel, we'll be glad to assist you.
CloudWatch only allows one subscription per log group. If the log group already have a subscription filter, (such as Elasticsearch subscription filter or AWS Lambda subscription filter) you have to remove the existing filter shown as below.