Debugging an app with a service mesh
summary
Linkerd is used to inspect live Kubernetes traffic with Linkerd tap and the viz CLI, revealing a grpc unknown error and 0% success for donut votes while the emoji-photo namespace shows 95% versus an expected 100%. Service profiles are created from protobufs or by observing calls (service profile generated from traffic), saved as JSON tap output, and a platform-level retry rule restores failing routes to retries lift success to 100% at the cost of increased latency.
AI-written summary · about
chapters (19)
- 0:00Debugging with Linkerd
- 1:02Emoji voting service debugging
- 2:29Linkerd CLI diagnostics
- 3:10Service mesh metrics analysis
- 4:57Failing API routes in web
- 7:03Root cause with traffic tap
- 9:09Detailed request capture
- 11:59Emoji photo problem solution
- 12:21Debugging with service profiles
- 13:25Custom profiles for gRPC
- 14:28Profiles from observed traffic
- 15:56Books app debugging
- 16:39Books service route failures
- 18:25Tracing service failures
- 19:49Intermittent author service failures
- 20:52Fixing retries at platform
- 22:18Latency impact after fixes
- 23:24Ensuring service reliability
- 24:05Q&A on SLA monitoring
related talks
21mTap Tap, Debugging an App with your Service Mesh
19mSeeing the Invisible Observability with
05mLightning Talk: Locating and Debugging Failures with Linkerd...
41mDebugging an Application with Service Mesh
31mClean-up Your Service Mess with Service Mesh
29mObservability and Debugging Cloud-Native Apps using Linkerd & Conduit
20mKeynote: Service Meshes and Observability
19mIstio, we have a problem! Understanding and fixing bugs with a service-mesh