There's a lot that comes out of the box to gain insights into how well your serverless app is performing
A quick overview to get you started โ
1๏ธโฃ Amazon CloudWatch
CloudWatch automatically monitors your functions on your behalf. It reports a lot of useful metrics:
โข number of invocations
โข execution durations
โข occurred errors
โข function throttles
Everything is exposed on a function level!
2๏ธโฃ Amazon CloudTrail
CloudTrail offers you governance, compliance & auditing features for several services, including Lambda.
It enables you to log all (encryption supported!) actions taken regarding your infrastructure, regardless if it's via the console UI or AWS SDK!
3๏ธโฃ AWS X-Ray
With X-Ray, you can add fine-grained traces for your function invocations to easily determine the root causes of errors or performance bottlenecks. It enables you to define trace spans to strictly separate sub-processes or downstream calls!
4๏ธโฃ AWS Config
AWS Config allows you to track configuration changes (e.g. concurrency settings, code size, timeout settings) for your functions as well as changes to the executions roles, attached subnets, or security groups.
It's a detailed view about your functions lifecycles
That's it - the basics are covered! ๐
Always keep in mind that you never want to run an app on blindsight - you need to know what's going on.
For an extended & detailed out-of-the-box solution, third-party tools like @thedashbird got you covered for your next production app ๐ฉโ๐ป
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
โข Introduction
โข Importance of Messaging Systems
โข Fundamentals
โข Queue Types
โข Visibility Timeouts
โข Retention Periods
โข Limitations
{ 1/22 }
๐๐ป๐๐ฟ๐ผ๐ฑ๐๐ฐ๐๐ถ๐ผ๐ป
Believe it or not: SQS was the ๐ณ๐ถ๐ฟ๐๐ publicly launched service by AWS!
Quoting Jeff Bar:
"We launched the Simple Queue Service in ๐น๐ฎ๐๐ฒ ๐ฎ๐ฌ๐ฌ๐ฐ, Amazon S3 in early 2006, and Amazon EC2 later that summer."
Thanks for all your interest in my AWS 1x1 threads! ๐ ๐
The good news: ๐๐ต๐ฒ๐ฟ๐ฒ'๐ ๐ฎ ๐น๐ผ๐ ๐บ๐ผ๐ฟ๐ฒ ๐ถ๐ป ๐๐ต๐ฒ ๐ฝ๐ถ๐ฝ๐ฒ๐น๐ถ๐ป๐ฒ!
... also for Azure ๐
Didn't see the previous ones yet?
๐๐ถ๐ป๐ธ๐ ๐๐ผ ๐ฎ๐น๐น ๐บ๐ ๐ฟ๐ฒ๐ฐ๐ฒ๐ป๐ ๐ฝ๐ผ๐๐๐ ๐ฎ๐ฟ๐ฒ ๐ฏ๐ฒ๐น๐ผ๐ โ
โข Fan-in & Fan-out
โข Simple Web Service
โข Publish/Subscribe
โข Strangler
โข Aggregator
{ 1/7 }
๐๐ฎ๐ป-๐ถ๐ป & ๐๐ฎ๐ป-๐ผ๐๐
Common problem: large tasks that are exceeding Lambda's execution time limit
With Fan-out, you're splitting those large tasks into small ones and delegating those to Lambda workers.
Afterward, results are aggregated (= Fan-in).
๐๐ฒ๐'๐ ๐ฏ๐ฒ ๐ต๐ผ๐ป๐ฒ๐๐: generally, debugging is not a fun task ๐คข
Especially for serverless, event-driven & distributed systems.
From Lambda's logging basics to ๐๐ฎ๐๐ถ๐ป๐ด ๐๐ถ๐บ๐ฒ & ๐ป๐ฒ๐ฟ๐๐ฒ๐ โ
Lambda's a serverless technology provided by AWS.
But that ๐ฑ๐ผ๐ฒ๐๐ป'๐ ๐บ๐ฒ๐ฎ๐ป that there are no servers.
In the background, there are countless micro-containers running on top of the traditional servers.
Where do all the logs of those containers go to?
By default, they will end up in CloudWatch.
Every Lambda will receive its own ๐น๐ผ๐ด ๐ด๐ฟ๐ผ๐๐ฝ.
Like a repository for logs.
Not only that, every micro-container will create a new so-called ๐น๐ผ๐ด ๐๐๐ฟ๐ฒ๐ฎ๐บ.
Think of it as a text file where logs are written to.