No. Once you set up asynchronous monitoring, our collector module will start to collect the monitoring data asynchronously. This is unique to Thundra and we are proud of it.
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. 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.
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.
It takes 1-2 minutes to see your function’s monitor data (audit, stat and log) in the application. Why?
Thundra currently supports Lambda functions in Java, Node.js, and Go. We are planning to support Python in the very near future. Using the same API key, you can monitor functions in all of the supported languages.