What We Should All Worry About When Monitoring Serverless Applications
summary
Argues that monitoring serverless must track more than Lambda invocations — include APIs, managed resources and end-to-end transactions — and recommends automated distributed tracing (uses Jaeger / OpenTracing / X‑Ray as examples) to stitch events together. Gives a concrete cost bug: a log‑reader rate limit produces 5,000 concurrent Lambdas stuck ~5 minutes each, turning into roughly $3,000/month waste. Describes building a tracing backend and open tools (a dead‑function detector and per‑function cost estimator) that find issues and reduce spend.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:19Why we need monitoring
- 3:45From monoliths to microservices
- 4:28What serverless really means
- 6:38Tracking system health in serverless
- 9:48Troubleshooting errors in serverless
- 12:00Distributed tracing explained
- 15:56Challenges of serverless tracing
- 17:25Optimizing performance and cost
- 24:29Key takeaways for serverless monitoring
- 25:34Epsilon’s open-source tools
- 27:05Q&A
related talks
13mMonitoring Kubernetes VS Serverless-based applications
24mObservability across serverless asynchronous managed services
49mMonitoring serverless applications on AWS: the monitoring monster becomes your friend.
05mA Serverless Monitoring Checklist
34mObservability in Serverless Application
27mSite Reliability in the Serverless Age
49mYou Don't Want Serverless
42mBest practices for serverless developers