Error Tracking ב-SaaS: מ-Exception בודד ועד Root Cause בקנה מידה

מאת צוות מדיה דיל · 02.08.2026 · SaaS Architecture · 9 דק׳

מדריך טכני לבניית מערכת Error Tracking ל-SaaS - grouping אוטומטי, source maps, source context, ותכנון תהליך תגובה לשגיאות פרודקשן.

שגיאה שקורית פעם אחת ולא מדווחת היא בזבוז הזדמנות - היא בדרך כלל אינדיקציה מוקדמת לבעיה גדולה יותר. אבל כשמערכת SaaS מגיעה לאלפי משתמשים, שגיאות קורות כל הזמן - חלקן שוליות (משתמש הזין פורמט מייל שגוי), חלקן קריטיות (bug שגורם לאובדן נתונים). מערכת error tracking ייעודית - Sentry, Rollbar, Bugsnag - נבנתה בדיוק כדי לפתור את הבעיה הזו: לא רק "לתפוס" שגיאות, אלא לארגן אותן בצורה שמאפשרת לצוות פיתוח לתעדף נכון מה לתקן קודם, ולהבין את ההקשר המלא סביב כל שגיאה בלי לחפור בלוגים גולמיים.

למה לוגים בלבד לא מספיקים לניהול שגיאות

אפשר לחשוב ש-structured logging (שתיארנו במדריך ארכיטקטורת הלוגים) כבר פותר את בעיית מעקב השגיאות - כל שגיאה נכתבת ללוג, אז למה צריך כלי נפרד? התשובה היא שכלי error tracking פותר בעיה שונה: grouping וdeduplication. אם באג מסוים גורם לאותה שגיאה 5,000 פעמים ביום מ-3,000 משתמשים שונים, לוגים גולמיים יראו את זה כ-5,000 שורות נפרדות. Sentry (וכלים דומים) מזהים אוטומטית שמדובר באותה שגיאה בדיוק (לפי stack trace, מיקום בקוד, סוג exception), ומקבצים אותה ל"issue" אחד עם מונה - "קרה 5,000 פעמים, משפיע על 3,000 משתמשים ייחודיים, התחיל להופיע אחרי הדפלוי האחרון". זו תובנה שלוגים גולמיים לא נותנים בקלות, והיא ההבדל בין "אינספור שורות טקסט" לבין רשימת עדיפויות מסודרת של מה לתקן.

Source maps ו-symbolication: מקוד מכווץ בחזרה למקור

אתגר טכני ספציפי בעולם ה-frontend הוא ש-JavaScript שרץ בפרודקשן עובר minification - כיווץ הקוד לגודל קטן יותר עם שמות משתנים קצרים חסרי משמעות. שגיאה שקורית בקוד המכווץ הזה תיראה כמו stack trace חסר תועלת לחלוטין ("שגיאה בשורה 1, תו 48291 של bundle.min.js"). הפתרון הוא source maps - קובץ מיפוי שמאפשר לכלי כמו Sentry לתרגם את השגיאה חזרה לקוד המקור המקורי, עם שמות המשתנים והקבצים האמיתיים. חשוב להעלות את ה-source maps לכלי המעקב כחלק מתהליך ה-CI/CD בכל דפלוי, ולא לחשוף אותם בפומבי (כי הם חושפים את קוד המקור המלא) - הם צריכים להישלח רק לכלי המעקב עצמו, לא לדפדפן. אתגר דומה קיים בעולם ה-native (iOS/Android) עם symbolication של crash reports, ובעולם ה-backend המקומפל (Go, Java) עם debug symbols.

Context: מה חסר בstack trace לבדו

stack trace לבדו נותן תמונה חלקית - הוא מראה איפה השגיאה קרתה, אבל לא בהכרח למה. מערכת error tracking טובה מאפשרת לצרף context עשיר לכל שגיאה: מי המשתמש (user_id), באיזה tenant (חשוב מאוד ב-SaaS multi-tenant, כדי לזהות אם הבעיה משפיעה על לקוח ספציפי או על כולם), מה היו הפרמטרים של הבקשה, מה הייתה גרסת האפליקציה, ואילו breadcrumbs (עקבות פעולה) הובילו לשגיאה - למשל "המשתמש לחץ על כפתור X, אז נפתח מודל Y, ואז קרתה השגיאה בפעולת Z". breadcrumbs הם לעיתים ההבדל בין "אני רואה שהייתה שגיאה" לבין "אני מבין בדיוק את הרצף שהוביל אליה ויכול לשחזר אותה". חיבור ה-context הזה ל-trace_id המשותף עם שאר מערכות ה-observability מאפשר לקפוץ ישירות מ-issue בכלי השגיאות לtrace המלא ולכל הלוגים הרלוונטיים.

תעדוף: לא כל שגיאה שווה תיקון מיידי

אחת התועלות המרכזיות של כלי error tracking היא היכולת לתעדף. שגיאה שמשפיעה על 0.01% מהמשתמשים ולא חוסמת אף פונקציונליות קריטית שונה לגמרי משגיאה שחוסמת checkout לכל המשתמשים. תעדוף נכון מסתכל על כמה ממדים: impact (כמה משתמשים ייחודיים מושפעים), frequency (כמה פעמים זה קורה), severity (האם זה חוסם פעולה קריטית או רק חוויה משנית), ו-regression status (האם זו שגיאה חדשה שהתחילה עם הדפלוי האחרון - סימן חזק שקשורה לשינוי קוד ספציפי וקל לתקן, לעומת שגיאה כרונית ישנה). כלים מודרניים מסמנים אוטומטית שגיאות "חדשות" מול "רגרסיה" (שגיאה שכבר נפתרה וחזרה), מידע קריטי לתעדוף מהיר.

אינטגרציה עם תהליך הפיתוח

ערך אמיתי נוצר כשerror tracking לא נשאר "עוד דשבורד" אלא משתלב בזרימת העבודה הקיימת. אינטגרציה עם Slack (התראה על שגיאה חדשה קריטית לערוץ מתאים), עם Jira או Linear (יצירת issue אוטומטית מ-error חדש), ועם ה-CI/CD pipeline (release tracking - סימון איזו גרסה גרמה לאיזו שגיאה) הופכים את המערכת מכלי פסיבי לחלק אקטיבי מהתהליך. שיקול נוסף הוא alert routing חכם - שגיאות מהשירות של צוות A מגיעות לצוות A, לא לכולם, כדי למנוע alert fatigue דומה למה שתיארנו במדריך ה-Monitoring.

Privacy ו-PII scrubbing

בדיוק כמו בלוגים, יש לתת את הדעת למה שנשלח לכלי error tracking - stack traces ו-context עלולים לכלול בטעות מידע רגיש (סיסמאות בparameters, טוקנים, מספרי כרטיס אשראי). רוב הכלים המודרניים תומכים ב-scrubbing rules מוגדרים מראש שמסננים אוטומטית שדות ידועים כרגישים לפני שהם נשלחים לשרת החיצוני של הכלי, וחשוב להגדיר אותם באופן יזום ולא להסתמך על שיקול דעת מפתח בזמן אמת.

סיכום

error tracking ייעודי הוא הרבה מעבר ל"תפיסת exceptions" - הוא כלי לארגון, תעדוף והבנה של מרחב השגיאות השלם של המערכת, עם grouping חכם, context עשיר, ואינטגרציה לתהליך הפיתוח היומיומי. בשילוב עם logging, monitoring ו-tracing, הוא משלים את התמונה המלאה של observability ומאפשר לצוות פיתוח לתקן את מה שבאמת חשוב, בסדר העדיפויות הנכון.

תגיות: error tracking · Sentry · source maps · exception handling · stack trace · SaaS architecture · PII scrubbing

← חזרה לבלוג · צור קשר