מערכת יכולה לייצר מיליוני שורות לוג ביום ועדיין להשאיר את הצוות בלי תשובה לשאלה פשוטה: מי נפגע, מאיזה רגע ובאיזה חלק של הזרימה. כמות נתונים אינה זהה ליכולת אבחון. צריך להתחיל בשאלות שתרצו לשאול כשיש לחץ, ולוודא שהאותות מאפשרים לחבר בין התנהגות המשתמש למתרחש בפנים.

ניקח תהליך יצירת הזמנה שעובר דרך API, מסד נתונים ותור. משתמש אומר ״התשלום עבר אבל ההזמנה לא התקדמה״. אם לכל שלב יש מזהה אחר ואין דרך לעקוב אחר הפעולה העסקית, החקירה תהפוך לחיפוש ידני בזמנים. אפשר לתכנן את יכולת החיבור מראש.

מגדירים קודם מהו שירות תקין

CPU נמוך אינו הוכחה שהמשתמש מצליח לבצע הזמנה. הגדירו מדד שקשור להתנהגות: שיעור פעולות שהושלמו, זמן המתנה עד סטטוס סופי, או גיל העבודה הוותיקה ביותר שטרם עובדה. מדדים תשתיתיים עדיין חשובים, אבל הם לא מחליפים מדד תוצאה.

בחרו חלון זמן שמתאים למוצר. שיעור שגיאות ממוצע על פני יום יכול להסתיר עשר דקות של תקלה קשה. מצד שני, התראה על כישלון בודד יכולה להיות רועשת מדי. צריך להחליט מתי האות מצביע על צורך בפעולה ומי אמור לבצע אותה.

לכל אות תפקיד

Metrics טובים לזיהוי מגמות, שיעורים והתפלגויות. Traces עוזרים להבין את מסלול הבקשה ואת חלוקת הזמן בין פעולות. Logs יכולים לתאר אירוע מפורט או החלטה שלא כדאי להפוך למדד. OpenTelemetry מתעדת את סוגי האותות ואת התפקידים שלהם.

אין צורך להעתיק כל מידע לכל ערוץ. למשל, שגיאת validation צפויה אינה חייבת לייצר stack trace מלא. החלטת routing חריגה יכולה לקבל לוג מובנה. חלוקת זמן של קריאה לספק שייכת היטב ל־span, ובמקביל אפשר לאסוף ממנה מדד מתאים.

מזהים צריכים לשרוד מעבר בין גבולות

העבירו context בין שירותים ותורים, ושמרו מזהה עסקי לא רגיש כשנדרש מעקב ארוך יותר מחיי בקשת HTTP. trace של קבלת הזמנה עשוי להסתיים לפני שסיים הצרכן לעבד אותה. הקשר העסקי עוזר לחבר את האירועים גם אז.

{
  "event": "order_processing_failed",
  "order_id": "public-order-reference",
  "attempt": 3,
  "dependency": "inventory",
  "error_type": "timeout"
}

זאת דוגמה ללוג מובנה, לא רשימת שדות אוניברסלית. לא מכניסים סיסמאות, קישורי כניסה או פרטי כרטיס כדי שיהיה ״קל לדבג״. כמות המידע, ההרשאות ומשך השמירה הם חלק מתכנון המערכת.

Cardinality יכולה להפוך מדד לבעיה

מזהה משתמש כתגית במדד יוצר פוטנציאל לסדרת זמן נפרדת לכל משתמש. במערכת גדולה זאת עלות אחרת לגמרי מתגית כמו סוג פעולה או אזור. הימנעו גם מכתובת URL מלאה שמכילה מזהים, כאשר אפשר להשתמש בתבנית route.

לפני הוספת תגית שאלו איזו שאלה היא תאפשר לענות. אם נדרש לחקור פעולה בודדת, ייתכן ש־trace או לוג מתאימים יותר. אם נדרשת השוואה בין סוגי עבודה, תגית בעלת מספר ערכים מוגבל יכולה לעזור. הבחירה היא בין כלים למטרות שונות, ולא בין ״יותר מידע״ ל״פחות מידע״.

ממוצעים מסתירים חוויה לא עקבית

שני שירותים יכולים להציג אותו זמן תגובה ממוצע, כשבאחד כמעט כולם ממתינים מעט ובשני חלק קטן ממתין הרבה מאוד. בדקו התפלגות וזנבות, והפרידו בין פעולות בעלות מאפיינים שונים. אל תחברו בקשת בריאות זולה והפקת דוח ארוך לאותו סיכום בלי להבין את המשמעות.

גם sampling ב־traces משפיע על מה שתוכלו לראות. תכננו איך לשמור דוגמאות של כשל נדיר, ואיך לא להסיק ששום דבר לא קרה רק כי לא נבחר trace. היעדר נתון אינו תמיד נתון של היעדר תקלה.

תרגיל: חקירה בלי גישה לשרת

הכינו חמישה ניסיונות הזמנה, כשאחד נכשל אחרי השמירה ואחד ממתין בתור. תנו לחבר לצוות לאבחן בעזרת האותות בלבד. האם הוא יודע כמה משתמשים נפגעו ומהו השלב התקוע? אם לא, הוסיפו את החיבור החסר במקום עוד לוג אקראי.

לאחר מכן כתבו התראה אחת עם פעולה ברורה: איזה מצב הפעיל אותה, איך מאמתים השפעה ומה עושים קודם. אפשר להמשיך אל תכנון תורים אמינים, שם גיל עבודה וגבולות עיבוד חשובים במיוחד.