Oops my app performance sucks... what if observability could be a game changer?
summary
Claims that shifting to an end‑user perspective cuts MTTD and cloud cost by surfacing traces (spans and flame graphs) correlated with logs and metrics. Demonstrates OpenTelemetry instrumentation, Jaeger-style traces and Datadog/continuous profilers to pinpoint a slow request to a high‑CPU host and to find CPU/memory hotspots that reduce billable time. Shows front‑end correlation using core web vitals (LCP <2.5s good, >4s bad, FID/CLS thresholds) so front or back end culpability is unambiguous.
AI-written summary · about
chapters (10)
- 0:00Introduction to observability
- 1:48Logs and metrics limitations
- 4:59What are observability signals
- 6:23Instrumenting applications
- 8:11Dynamic and ephemeral systems
- 9:59Distributed tracing explained
- 13:10Continuous profiling benefits
- 15:01Front-end observability
- 16:04Core web vitals overview
- 18:14Future of observability tools
related talks
41mModern Application Debugging: An Introduction To OpenTelemetry
52mIs your JVM app flying blind? Unmask hidden issues with Observability superpowers!
52mGraphQL Observability with Elastic and OpenTelemetry
01h 02mWhat is your app really doing? Make it tell you with OpenTelemetry.
32mCustomer Centric Observability: How Intuit Reduced Time To Detect Customer Impact From 30+ Minutes To Under 3 Minutes.
47mUsing metric and traces to diagnose our cloud-native applications
33mWhat Developers Should Know About Observability
21mMonitoring Your Apps is not About Devops