With Thundra, you can gather useful insights about your AWS Lambda function such as detecting errors and performance degradations. Thundra gives you flexibility to instrument your code either manually or by using automated approach with no code change. Now, it is time to send the monitoring data to Thundra for evaluation. Thundra gives you two options to send your monitoring data:
I remember my first times writing some code in C years ago. I was struggling to discover why my code got segmentation fault. To detect the point of failure, I was printing every single variable to console at some specific checkpoints which hopefully would tell me why. Back then, I wasn’t aware that my silly
printf s were primitive examples of manual instrumentation.
Suppose you want to buy a ticket to a concert of your favorite band and you know that the tickets are running out. You need to open your computer, wait for the launch of the browser, go to the website of ticket sales, see there is only one ticket remaining, and click to buy. Then boom, “Sold out” is the phrase you are going to hate for a while. We are sad to say but you are “cold started”. You would have been able to catch the last ticket if your browser window was open, showing the website, and ready for you to click the “buy” button. You should have kept your computer warm to buy this ticket.
We conducted our first webinar last week. After we released our public beta, we got some questions and feedback about Thundra. That’s why it was time to make this webinar, with Serkan Özal, our lead engineer, and me as product manager.