Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
A few weeks ago we posted the “How we built a serverless Stonks checker API for Wall Street Bets” article. And ever since, we’ve seen quite a lot of volume in the Stonks checker app. In this follow-up article, we will show you some interesting findings around the API.
Over the past three weeks, we have seen a good amount of usage of the API we set up. You can see that there was a nice spike soon after the story broke. To note is that we have HTML caching setup in the returned value from the Lambda function. So you can see that about half the time, a Lambda is not called, and the results are a cached HTML version.
The Hot Stock Checker (HSC) has run for a month now and got used quite a bit. We added the Dashbird integration to the AWS account that hosted the HSC infrastructure and looked at the past three weeks.
So, let’s jump right in and look at the Dashbird metrics of the Lambda function.
In the three weeks of running the HSC, we got the most invocations at the launch, which is obvious. But Dashbird also shows other interesting findings.
The best insight here is, it didn’t cost us any money to run this application. The usage was so low that we never left the free tier of AWS Lambda.
You can learn more about saving money on your Lambdas in this article about 6 cost optimization strategies that actually work.
Over half of these invocations were cold-starts. In this specific application, it’s to be expected since it doesn’t have enough invocations per second to keep around a warm Lambda function. Still, if this was a production application that has to deliver on SLOs, it could be a good idea to use provisioned concurrency for the Lambda function to get rid of these cold-starts. This would also lower the average duration of our function.
The next point is memory usage. The Lambda function is configured with 256 MB of memory but only uses 28% of it. This is a bit tricky to optimize. In a low memory config like that, it’s not advisable to lower the memory consumption because memory config implicitly configures CPU performance.
So, if we lower the memory config, things would get cheaper but also slower. In the case of a Lambda function connected to an API Gateway, this could lead to higher latency and, in turn, a worse user experience. If it’s just about saving costs, and we would leave the free tier with our Lambda function, we could set the memory to 128 MB and save some money.
We can also see the last invocation, the last error, and an insight.
We can use the last invocation to get details about that specific invocation, which isn’t very interesting in this project. So let’s move to the last error.
The last error was 4 months ago, but Dashbird was integrated with that AWS account much later. This illustrates how Dashbird works under the hood. It reads data from CloudWatch Logs, which get written right when a Lambda function was deployed. So the data is already here before a potential customer decides to use Dashbird. This enables Dashbird to show us data from before its integration.
The way Dashbird uses already existing logging data especially shines with the Dashbird Well-Architected Lens. It is built around the automated AWS Well-Architected Reports, based on the AWS Well-Architected Framework‘s set of whitepapers containing best practices for building software on AWS infrastructure.
The old logs aren’t very interesting on their own. After all, we could open up CloudWatch ourselves and look for four months old errors. But with the Dashbird Well-Architected Lens, we can get higher-level insights about our infrastructure, like Lambda functions that aren’t used anymore or, like shown in the screenshot above, an upgradable Lambda runtime.
You can check out the insights Dashbird provides to you on top of CloudWatch logs in our event library. It doesn’t just come with insights for Lambda, but also API Gateway, DynamoDB, and even Kinesis.
Further reading:
Introducing Dashbird’s automated Well-Architected Reports
AWS CloudWatch vs Dashbird observability
Log-based monitoring for AWS Lambda
Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.