עקיבה מקצה לקצה נשברת בגבולות השירותים
העקיבה מחזיקה בדיוק עד לגבול הראשון בין השירותים: קריאה ב-HTTP בתוך האשכול נראית במלואה, אך ברגע שהבקשה עוברת לתור, למשימת רקע או לשער חיצוני, ההקשר הולך לאיבוד. הספאנים אינם מתחברים לכדי עקיבה אחת, ובלוח נשאר קטע של הנתיב — עד לרגע שבו השירות העביר את העבודה הלאה. עקיבה מקצה לקצה הופכת לאוסף של מקטעים לא מקושרים, והשוואה ביניהם נעשית ידנית לפי הלוגים.
היקר ביותר זה מתגלה בניתוח תקלות. התורן פותח לוגים של ארבעה-חמישה שירותים, משווה חותמות זמן בעיניים ומגלה שלכל רכיב יש מזהה בקשה משלו.
צוואר הבקבוק מתבקש בחיפוש סדרתי: תחילה החשד נופל על בסיס הנתונים, אחר כך על מאגר החיבורים, ואז על המטמון — ורק לקראת סוף השעה מתברר שהנתיב הואט בגלל קריאה חיצונית אחת עם ניסיונות חוזרים. נראות שירותים קרועה לא מאפשרת להוכיח את הסיבה, ולכן ההידרדרות מספיקה לחזור על עצמה.
כדי שהעקיבה לא תיקרע, יש להעביר את ההקשר דרך כל התעבורות שקיימות במערכת, ולא רק דרך קריאות סינכרוניות. New Relic APM אוסף עקיבה מבוזרת על פני השירותים, אך התמונה הופכת שלמה רק כאשר גם מטפלי התורים, גם מתזמני משימות הרקע וגם לקוחות האינטגרציות החיצוניות מנוטרים.
חלק נפרד של העבודה — לקשר רשומות לוג לעקיבות לפי מזהה משותף, כך שהמעבר מספאן לשורת לוג יתבצע בקליק אחד.
אנחנו מפרקים כיצד זה נסגר: מה להגדיר בסוכן, כיצד לתייג שירותים ואילו בדיקות להטמיע כדי שהעקיבה תיאסף במלואה, ולא עד הגבול הראשון.
מה נותנת נראות מקצה לקצה על פני כל השירותים
נראות מקצה לקצה — זה כאשר לפי תלונה אחת אפשר לעקוב אחר כל נתיב הבקשה: מהשירות הנכנס דרך תורים וקריאות חיצוניות ועד לבקשה מסוימת לבסיס הנתונים.
New Relic APM אוסף עקיבות מבוזרות, מדדי יישומים ונתוני סביבה לתמונה אחת, ולכן סיבת התקלה מתבקשת לא בחיפוש סדרתי בלוגים של חמש מערכות, אלא לפי גרף התלויות. להלן — מה בדיוק משתנה בעבודת הצוות כאשר חיבור כזה כבר מוגדר.
- זמן איתור הסיבה. העקיבה מקשרת מקטעים לפי מזהה בקשה אחד — במקום שעות של תיאום «של מי המקטע הזה», הסיבה נמצאת תוך דקות.
- צווארי בקבוק בשירותים. רואים את רשימת הקריאות החיצוניות והבקשות הארוכות ביותר למאגר עם פילוח לפי זמן תגובה — ברור מה לייעל ראשון, ומה לא משפיע על התוצאה.
- התראות שווא. הכלל נבנה על שילוב אותות (שיעור שגיאות + משך + תפוקה), ולא על סף בודד — הפעלות ללא סטייה אמיתית כמעט נעלמות.
- סוג של כשלים נסתרים. הידרדרות שבה הכול «ירוק», אך מקטע אחד מגיב פי שלושה יותר זמן, מזוהה לפני פניות משתמשים.
- זמן התאוששות. כל פריסה משויכת אוטומטית לנקודת השחרור: השוואת «לפני ואחרי» וחזרה לאחור נשענות על עובדות, ולא על ניחושים.
- מפת תלויות. הקשרים בין השירותים נבנים לפי תעבורה בפועל, ולא לפי תיעוד שהתיישן.
- הקשר אחיד לניתוח. לוגים, מדדים ועקיבות נפתחים זה לצד זה, ולכן ניתוח תקלה לא הופך לאיסוף ידני של דוחות ממערכות שונות.
המשמעות אינה בלוח ניטור, אלא בשינוי התהליך: מגדירים כללי התראות, נהלי ניתוח ותיוג שירותים כך שהנראות תעבוד עבור צוות התורנות, ולא תתקיים בפני עצמה.
דרכים לאיסוף טלמטריה: סוכן, תיוג, שער
את שיטת איסוף הטלמטריה בוחרים לפי קריטריון אחד: היכן אנחנו מוכנים לבצע שינויים — בקונפיגורציה של הצומת, בקוד היישום או בשירות נפרד בין היישום למאגר.
סוכן ניטור מותקן על מארח או בקונטיינר, אינו דורש שינויים בקוד ומיד מספק בקשות, שגיאות וזמן קריאות חיצוניות; המחיר — להחזיק ולעדכן אותו בכל צומת. אינסטרומנטציה של הקוד נותנת גבולות מדויקים של פעולות עסקיות, אך כובלת אותנו לשפה ולמשמעת של צוות הפיתוח.
קולטן מדדים נפרד — פשרה לארכיטקטורת איסוף נתונים מבוזרת: סוכנים וספריות שולחים לו נתונים, והוא מחליט מה עובר הלאה, כיצד מועשר ומסונן. ב-New Relic אפשרויות אלה משלימות זו את זו, ולכן הבחירה אינה «או», אלא «באיזה סדר».
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן על מארח או בקונטיינר | נדרשת טלמטריה ללא שינויים בקוד ומספר שפות | גישה לצמתים, יש לשמור על סנכרון גרסאות הסוכנים |
| ספרייה בתוך היישום | נדרשים מדדים עסקיים וגבולות מדויקים של פעולות | שינויים בקוד, תלות בשפה, בנייה מחדש ושחרור |
| קולטן-שער נפרד | מקורות רבים, נדרשים קליטה וסינון אחידים | מהווה שירות בעצמו: סקייל, עדכונים, עמידות בתקלות |
| סוכן על צומת יחד עם ספרייה | נדרשים גם נתוני תשתית וגם נתוני יישום | כפילות מדדים, נדרשת נורמליזציה של שמות |
גבולות האפשרויות מיטשטשים: סוכן על צומת פותר את המשימה ביום, וספרייה מוסיפה את מה שלא נראה מבחוץ. בהמשך נפרק כיצד לשלב ביניהם בלי כפילויות בדיווח.
כיצד מתבצעת ההטמעה: מתרשים ועד מסירה
הטמעת ניטור לעתים רחוקות מסתכמת בהתקנת סוכן: תחילה צריך להבין אילו שירותים קשורים זה לזה והיכן הולך לאיבוד הקשר הבקשה. לכן אנו מתקדמים בשלבים — מסקר הסביבה ועד למסירת נהלים, כדי שתכנית הנראות תעבוד גם בלעדינו.
- סקר הסביבה. עורכים מלאי של שירותים, סביבות ונקודות כניסה, מתעדים מה כבר מספק מדדים ומה יצטרך להיסגר ידנית.
- תכנון תכנית הנראות. מסכמים מה נחשב לשירות נפרד, כיצד מקשרים בקשה ביניהם וכמה זמן שומרים נתונים — את התקופה בוחרים בהתאם לניתוח תקלות.
- הגדרת סוכנים. מתקינים סוכן New Relic לצד היישום, מפעילים איסוף כברירת מחדל ומוסיפים באופן ממוקד מדידות ידניות במקומות שבהם האוטומציה אינה רואה את הפעולה העסקית.
- עקיבה מבוזרת. מעבירים את ההקשר דרך שירותים ותורים ומגדירים את שיעור הבקשות הנשמרות: הדגימה נשארת מייצגת, ונפח הנתונים אינו גדל ללא בקרה.
- לוחות וכללי התראות. בונים לוחות עבור התורן, הטק-ליד ומנהל התחום, ואת הכללים מגדירים לסטייה מהנורמה, ולא לכל עלייה.
- בדיקת עומס. מריצים פרופיל קרוב לזה של העבודה ומקפידים שכתיבת הנתונים לא תאכל את התפוקה ולא תוסיף השהיות מורגשות למשתמש.
- מסירת נוהל תפעול. מתעדים מי וכיצד מגיב להתראה, כיצד מבצעים חזרה לאחור של שינויים וכיצד מחברים שירות חדש לתכנית.
מדיניות גישה, תפקידים והפרדת נתונים
הפרדת גישות במערכת העקיבה אינה ביורוקרטיה, אלא תנאי שבו ניתן לתת אמון בתוצאות החקירה. חשבון משתמש כללי אחד עם הרשאות מלאות ב-New Relic מאפס את הביקורת: אי אפשר להבין מי שינה את כלל ההתראה ומי ייצא עקיבות עם פרמטרים של בקשות.
תפקידי צפייה בונים מתוך מבנה הצוותים: מפתח רואה את השירותים שלו, התורן — את כל המתאר, קבלן חיצוני — רק את הקטע המוסכם.
הלקוח מקבל לידיו:
- מטריצת תפקידים עם שיוך לצוותים ולשירותים: מי צופה במדדים, מי — בעקיבות, מי מנהל את הכללים;
- מדיניות הפרדת נתונים ומיסוך: פרמטרים של בקשות נחתכים לפני הכתיבה, ולא אחריה;
- תרשים זרימת נתונים מקולטן המדדים ועד למאגר, עם ציון נקודות האנונימיזציה;
- נוהל תורנויות ואסקלציה: זמני תגובה, סדר מסירת משמרת, קריטריונים לקריאה בלילה;
- תיעוד תפעול: רוטציה של מפתחות גישה, סקירת הרשאות, חיבור שירות חדש לעקיבה;
- יומן ביקורת פעולות והוראות לניתוח תקלות עם קישורים ללוחות ולשאילתות מסוימות;
- רשימת בדיקה לקבלה, לפיה ניתן לבדוק את הקונפיגורציה בלעדינו: שאילתות, מסננים, אזורי נראות.
הגדרת התראות בלי רעש: ספים וקבוצות
כברירת מחדל צוותים מציבים ספים סטטיים «לפי העין»: זמן תגובה גבוה מערך מותנה — התראה. בשעות שיא סף כזה מופעל עשרות פעמים, התורן מתרגל להתעלם מהערוץ, והכשל האמיתי מגיע יחד עם הרעש.
זה לא מטופל על ידי השבתת כללים, אלא על ידי הפרדת התנאים לפי אופי המדד — ב-New Relic זה נעשה ברמת המדיניות והתנאים.
מדדי משאבים — ניצול דיסק, מיצוי מאגר החיבורים, גידול בתור — מחזיקים על ספים סטטיים: יש להם גבול פיזי, והסטייה תמיד משמעותית. מדדים תלויי-תעבורה — זמן תגובה, שיעור שגיאות, תפוקה — מעבירים לספים בסיסיים עם חלון החלקה של כמה ימים ודרישה שהסטייה תימשך יותר ממדידה אחת. זה מסיר הפעלות על עלייה בודדת ומשאיר את אלה שמאושרות על ידי מדדים שכנים של השירות.
מקור רעש שני — כשל אחד שמוליד ארבעים התראות. קיבוץ תקלות לפי ישות ומאפיינים מרכזיים אוסף הפעלות קשורות לתקלה אחת עם הקשר משותף, והפרדה לרמות קריטיות ומזהירות לא נותנת לאירועי רקע לדרוס את הקריטיים. סף האזהרה מציבים במכוון נמוך מהקריטי — הוא פועל כאות מוקדם, ולא כעילה לשיחה בלילה.
ניתוב התראות נשען על תגים: לכל ישות מוצמד הבעלים של השירות, וכללי המסירה מפרשים את ההפעלות לפי תורנויות — קריטי עובר לערוץ התורנות עם אסקלציה, אזהרות לערוץ הצוות, וזרם רקע לילי מתקפל לתקציר בוקר.
דיכוי רעש כולל כללי השתקה בזמן עבודות מתוכננות ופריסת שחרור, כדי שהעדכון לא ייראה כתקלה. התוצאה — שיעור ההתראות שבאמת עושים בהן משהו עולה, והזמן עד לתגובה יורד.
במה שונה עקיבת בקשות ממדדים?
מדד עונה על השאלה «מה ובאיזו תדירות», עקיבה — «היכן בדיוק ולמה». הבחירה «מדדים או עקיבות» היא התפצלות שווא: אלה כלים עוקבים, ולא מתחרים. מדדים מצטברים מראים שהבעיה קיימת ובאיזה חלון זמן, ועקיבת בקשות מובילה למקטע מסוים בנתיב שיוצר אותה.
מדדים מצטברים מחושבים על פני כל הבקשות בבת אחת: שיעור שגיאות, האחוזון ה-95 של זמן התגובה, מספר פניות בשנייה, רוויה של מאגר החיבורים. הם זולים בנפח וטובים לתצפית — לפיהם רואים שלאחר פריסה עלה שיעור הכשלים או ירד האחוזון של ההשהיה.
מה שחסר בהם הוא שיוך לבקשה בודדת: המדד יגיד שמשהו איטי, אך לא יראה באיזה שלב עיבוד אבדו מאות מילישניות.
עקיבה היא רשומה של נתיב אחד: מנקודת הכניסה דרך שירותים פנימיים ועד לבסיס הנתונים ולקריאות חיצוניות, עם משך כל מקטע והקשר ביניהם. היא שומרת את הקשר השגיאה — איזה מטפל קרס, עם אילו פרמטרים הגיעה הבקשה, מה קרה בשירותים השכנים. לאבחון תקלה מצמצמים תחילה את החלון לפי מדדים, ואחר כך פותחים עקיבות בדיוק של אותו פרק זמן.
ב-New Relic APM שני השכבות קשורות לתמונה אחת: עקיבה מבוזרת מדביקה מקטעי נתיב בין שירותים, והמדדים שלהם נכנסים לאותם גרפים שלפיהם מתנהלת התורנות. הניתוח הולך מלמעלה למטה — מ«עלה שיעור השגיאות בתשלום» ל«קריאה לשער חיצוני הפסיקה להיכנס לטיימאאוט».
מקרה בוחן: ניתוח הידרדרות של שירות תשלומים
שירות תשלומים ביצע תשלומים דרך שרשרת של ארבעה מקטעים: קליטת בקשה, בדיקת אנטי-פראוד, פנייה לספק חיצוני ורישום התוצאה. זמן התגובה הממוצע בכניסה נשמר בנורמה, אך בחלק מהפעולות הוא זינק פי כמה — בגרף המסכם זה לא נראה.
לפני: העקיבה נקטעה באמצע השרשרת
העקיבה נאספה רק בשני המקטעים הראשונים: משם והלאה הקשר הבקשה אבד, מכיוון שהשכבה המתווכת לא העבירה כותרות. New Relic קיבל טרנזקציות מפוזרות בלי שיוך לתשלום מסוים, וניתוח כל מקרה הפך להשוואה ידנית של יומנים לפי חותמות זמן.
זמן חיפוש הסיבה הגיע עד 4–6 שעות, וכמעט מחצית מהניתוחים הסתיימו במסקנה «לא הצלחנו לשחזר». שינויים באנטי-פראוד בוצעו בעיוורון: לא היה ברור מה מוסיף השהיה — הבדיקה או ההמתנה לתגובת הספק.
אחרי: קישור מקצה לקצה לפי מזהה תשלום
העברנו את מזהה התשלום דרך כל המקטעים והפעלנו עקיבה מבוזרת בשכבה המתווכת, ואת השגיאות פילחנו לפי סוגים ומקטעים — כשל של הספק הפסיק להתערבב עם שגיאה פנימית של פענוח התגובה.
- זמן חיפוש הגורם השורשי לאירוע: 4–6 שעות → 10–20 דקות.
- שיעור המקרים עם סיבה שנמצאה בניתוח הראשון: כמחצית → תשעה מתוך עשרה.
- שינויים באנטי-פראוד: לפי השערות → לפי פילוח השהיות בין מקטעים.
את האפקט נתנה לא הטלמטריה עצמה, אלא הרציפות של העקיבה: קרע במקטע אחד הפחית מערכם של נתוני כל האחרים.
ספקות טכניים לפני תחילת העבודה
ההתנגדויות לפני הטמעת עקיבה מקצה לקצה בדרך כלל אינן לגבי יכולות, אלא לגבי מחיר התפעול: תקורה, תאימות ופרטיות נתונים. נפרק ארבעה שמעכבים פרויקטים לרוב.
האם איסוף הנתונים לא יעמיס על השירותים עצמם?
הסוכן אוסף מדדים באופן קבוע, ואילו עקיבה מבוזרת מפעילים באופן ממוקד — בנתיבים קריטיים ועם דגימה. את התקורה מחזיקים בתוך כמה אחוזים מזמן התגובה, ומודדים אותה לפני ואחרי על אותו פרופיל עומס. בשירותים הרגישים להשהיות, מצמצמים את העקיבה לפעולות מסוימות.
מה עושים עם שירותים מיושנים?
אין חובה לשכתב אותם: את התאימות מספקים ברמת הסביבה — איסוף דרך פרוקסי ולוגים, ולא דרך סוכן בתוך היישום. כך שירותים ישנים נכנסים לתמונת העקיבה הכללית, גם אם איש אינו נוגע בקוד שלהם.
מה עושים עם פרטיות הנתונים?
את המיסוך מגדירים בצד הסוכן: שדות אישיים, מזהים וגופי בקשות נחתכים לפני השליחה, והחוצה יוצאים שמות פעולות וטיימינגים. כללי המיסוך נמצאים בקונפיגורציה ומכוסים בבדיקות — בעת שינוי סכמת הנתונים הם אינם מתרחקים מהמציאות.
כמה זמן נשמרות עקיבות וכיצד להגביל את הנפח?
את תקופת השמירה קובעים במדיניות: עקיבות גולמיות נשמרות לזמן מוגבל, מדדים מצטברים — יותר זמן, מכיוון שהם תופסים פחות מקום ונדרשים למגמות. לאחר הפעלת דגימה וניקוי לפי מועד, נפח האחסון מפסיק לגדול באופן ליניארי.
נדון במשימת הנראות שלכם
כדאי להתחיל בתיאור המשימה: אילו שירותים משתתפים בעיבוד הבקשה, היכן כעת הולך לאיבוד ההקשר ביניהם ואיזו שאלה צריך לסגור — חיפוש מקור השגיאות, ניתוח מקטעים איטיים או בקרה על זמן התגובה בכל הנתיב.
לניתוח מקדים מספיקים רשימת שירותים, סביבת ההרצה שלהם ותרשים הסביבה: בנפרד מתארי פיתוח, בדיקות ועבודה.
הערכת העבודה לא נבנית לפי העין. אנו סופרים את מספר נקודות הכניסה, עומק שרשרת הקריאות, נפח זרימת הבקשות ואת השיעור הנדרש של נתיבים מכוסים. אם הנראות כבר פרוסה חלקית, בודקים היכן מותקנים קולטני הנתונים ואילו קרעים בהקשר נותרו — זה מראה אם די בהגדרה משלימה או שיידרש מעבר לוגיקה.
לפי תוצאות הניתוח נחזור עם תכנית הטמעה ותרשים סביבה: סדר חיבור השירותים, שלבים, תחומי אחריות, קריטריוני קבלה ונקודות חזרה לאחור.
מה בדרך כלל נדרש בכניסה כדי לעבור לתחילת העבודה:
- רשימת שירותים וקשרים ביניהם, כולל משימות רקע ותורים;
- תרשים סביבה עם ציון היכן נמצא כל מתאר וכיצד הם מתקשרים ביניהם;
- גישות למערכות נראות ולמאגרי יומנים — חשבונות שירות עם הרשאות קריאה בלבד;
- סביבות הרצה וגרסאות של ספריות שיוצרות עקיבה;
- רשימת מקורות נתונים שכבר מחוברים והתראות מוגדרות;
- ציפיות לגבי עומק אחסון העקיבות ומהירות החיפוש;
- עובד שיאשר את קריטריוני הקבלה בצד הלקוח.
תארו את המשימה כפי שנוח לכם — במכתב קצר או בפגישה. נחזור עם הערכה, תכנית ונפח ברור של השלב הראשון.