Distributed Tracing - Jaeger, OpenTelemetry
checkout request ב-Uber לוקח 2.3 שניות. מה גורם לזה? יש 47 microservices בpath. הmetrics מראים שכולם בריאים. הlogs מראים שאין errors. ועדיין - 2.3 שניות לrequest ש-SLO שלו 500ms.
בלי Distributed Tracing, התשובה לשאלה "מה איטי?" היא: ניחוש, SSH לשרתים שונים, שעות debug. עם Tracing - קוראים בחמש שניות שה-payment-service מחכה 1.8 שניות ל-fraud-detection-service שמריץ ML model עבה מדי.
ב-2022, צוות backend בחברת ecommerce ישראלית קיבל דיווח מ-customer success: "users מתלוננים שה-checkout לאט." Prometheus p99 latency לcheckout service: 380ms - בתוך ה-SLO. Error rate: 0.02% - fine. ה-SRE engineer שנשלח לחקור היה במצב לא נעים: מה לחפש כשאין metric שמסתכל עליו?
שני ימים של investigation ידני - SSH לשרתים, קריאת logs, ניסיון להבין מה קורה. בסוף גילו: ה-inventory service היה עושה N+1 queries לDB - לכל item בcart, query נפרד. Cart עם 8 פריטים = 8 queries = 800ms על ה-inventory call. אבל checkout p99 היה 380ms כי רק 20% מה-carts היו עם יותר מ-5 פריטים.
שלושה שבועות לאחר מכן הם הטמיעו Jaeger. בפעם הבאה שcustomer התלונן - ה-engineer פתח את Jaeger, חיפש trace שנקרא "checkout" עם duration > 1000ms, ובתוך 2 דקות ראה: span של inventory-service: 780ms, עם 12 child spans של DB queries עם שמות "SELECT item by id". N+1. מיד.