למה הטריסינג הולך לאיבוד: מה נשבר בלי Jaeger
במערכת מבוזרת, בקשה אחת עוברת דרך שער, מספר שירותים, תור ובסיס נתונים. אבל אין חוט מקשר ביניהם: מזהה הבקשה לא מועבר הלאה בשרשרת, חותמות הזמן בצמתים שונים אינן מתואמות, וחלק מהקריאות יוצאות באופן אסינכרוני וכלל לא נכנסות ליומן של הצד הקורא. אי אפשר להרכיב מזה את נתיב הבקשה — אפשר רק לשער היכן הוא נשבר.
ואז מתחיל חיפוש אחר השערות. המהנדס מסתכל על מטריקות, מרים יומנים של שירותים אחד אחד, משווה ידנית חלונות זמן — ובכל זאת לא רואה באיזה מעבר בדיוק הבקשה נחלשה. טרייסים אבודים משמעם שתקלה נדירה אך סדירה מתרחשת לסירוגין, והסיבה נשארת השערה עקיפה.
המחיר של אבחון תקלות כזה — לא רק שעות של תורן. כל עוד המקור לא נמצא, ההשהיות גדלות, שגיאות מצטברות בצד הלקוחות, והשינויים נעשים באקראי: תיקון ש'היה אמור לעזור' סוגר את הסימפטום ומסתיר את הסיבה.
טריסינג מקצה לקצה סוגר את זה אחרת: כל בקשה מקבלת מזהה אחיד, שמועבר לאורך כל שרשרת הקריאות, ו-Jaeger אוסף מהנתונים האלה עץ של פעולות עם משך הזמן של כל אחת. בהמשך נסביר כיצד זה נפרס ומה זה נותן ברגע של תקלה אמיתית.
מה נותן טריסינג מקצה לקצה במערכת מבוזרת
במערכת מבוזרת, בקשה אחת עוברת דרך מספר שירותים, ובמקרה של תקלה הלוגים מראים רק שברים: רואים ששירות ענה לאט, אבל לא רואים בגלל מה. צפיות ללא טריסינג מקצה לקצה נתקעת בחיפוש ידני בין שירותים, וכל דקת חיפוש היא דקת אי-זמינות.
טריסינג מקצה לקצה אוסף את כל נתיב הבקשה לשרשרת אחת עם משך הזמן של כל שלב. Jaeger שומר שרשראות כאלה ומפרק את הבקשה למרווחים: איזו קריאה לקחה את עיקר הזמן, היכן הצטבר תור, איזו תלות ענתה באיחור.
המהנדס פותח בקשה איטית ספציפית ורואה את צוואר הבקבוק לפי זמן ונפח פניות — בלי לעבור ידנית על שירותים.
האפקט המעשי מדיד: חיפוש סיבת התקלה מתקצר משעות של חיפוש השערות לדקות, ושיעור הכשלים שלא מצליחים להסביר יורד — השרשרת או מציגה את הקטע הבעייתי, או מוכיחה שהעניין מחוץ למערכת.
גם סוג הכשלים שמנתחים משתנה. במקום 'לפעמים הכל מאט' מופיע קטע ספציפי עם חריגה בזמן, הקשור לגרסה, לתצורה ולנפח העומס. זמן השחזור נקבע כבר לא לפי חיפוש האשם, אלא לפי התיקון.
טריסינג משלים מטריקות ולוגים, ולא מחליף אותם: מטריקות אומרות מה נעשה גרוע יותר, לוגים — מה קרה, שרשראות — איפה בדיוק. אנחנו מפעילים אותו בהדרגה, כדי שזרימת הטרייסים לא תגדל ללא שליטה ולא תשפיע על זמן התגובה של השירותים.
מצבי פריסה של Jaeger: השוואת אפשרויות
בחירת מצב הפריסה קובעת לא רק כמה מהר הטרייס מגיע לממשק, אלא גם כמה משאבים להקצות לאשכול וכיצד להפריד סביבות. האינסטרומנטציה של השירותים עצמה לא תלויה בכך, אבל אחסון הטרייסים, עמידות בתקלות והסקיילינג — תלויים לחלוטין. להלן האפשרויות שביניהן באמת בוחרים בהתחלה ובצמיחת זרימת הספאנים.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| תהליך אחד עם אחסון בזיכרון | דיבוג מקומי, בדיקת תקינות האינסטרומנטציה, הדגמה | הטרייסים נעלמים באתחול מחדש, אין גדילה אופקית, לא מתאים למתאר כללי |
| קולטור ואחסון Elasticsearch בתוך אשכול העבודה | צוות בגודל בינוני, עומק אחסון 14–30 ימים, סביבות מופרדות לפי מרחבי שמות | משאבים משותפים עם שירותי העבודה, חובה להגדיר ריטנשן ומספר רפליקות |
| מתאר טריסינג נפרד על Cassandra | זרימת ספאנים גבוהה, אחסון לחודשים, מתאר תפעול נפרד | יקר יותר לתחזוקה, נדרש מומחיות בסכימה ובעדכונים, מסובך יותר לפרוס סביבות |
| קולטור כחוצץ (Kafka) לפני אחסון חיצוני | עומסי שיא, ירידה באחסון לא צריכה להפיל את קליטת הטרייסים | טרייסים מופיעים באיחור, מתווספות נקודות כשל, נדרש ניטור תור |
| שירות טריסינג מנוהל | צוות קטן ללא תורן ייעודי לאחסון | פחות שליטה על הסכימה ותקופת האחסון, תלות בספק |
הקולטור אינו שומר מצב: המופעים שלו מתרחבים אופקית מאחורי מאזן עומסים, והסוכן בכל צומת מבצע חוצץ לספאנים ושורד אתחול מחדש. עמידות בתקלות נתקעת באחסון — רפליקות וקוורום מוגדרים בצד בסיס הנתונים, ולא בצד הטריסינג.
בידוד סביבות עדיף לעשות עם מופעים נפרדים של קולטור ואינדקסים נפרדים לכל סביבה, אחרת זרימת הבדיקות מטשטשת את הדגימה ומנפחת את נפח האחסון.
תדירות הדגימה נקבעת בנפרד לכל סביבה: בפיתוח כותבים הכל, בפרודקשן — חלק עם שמירה מובטחת של בקשות איטיות ושגויות, אחרת ניתוח התקלה נשאר בלי נתונים.
הטמעת Jaeger: שלבי העבודה ההנדסית
מתחילים במיפוי מלאי, לא בפריסה: עד שלא ברור היכן נולדת הבקשה ואילו קריאות חוצות גבולות שירותים, סכימת הטרייסים תהיה חלקית. סדר העבודות שלהלן — מה שאנחנו עוברים בכל הטמעה, מהסקר ועד למסירת הנהלים.
-
סקר שירותים ונקודות כניסה. מתעדים את רשימת השירותים, פרוטוקולי התקשורת ומקומות שבהם הקונטקסט הולך לאיבוד: תורים, משימות רקע, קריאות חוץ. בפלט — מפה שמראה אילו קטעים בנתיב אינם נראים כרגע.
-
סכימת זרימת טרייסים. מסכמים על פורמט אחיד להעברת קונטקסט בין שירותים, כללי שמות לפעולות ולתכונות. בלי זה הטרייסים מתאחים לקטעים קרועים ולא מציגים את זמן התגובה המלא.
-
פריסת Jaeger. קולטור קליטה, אחסון, ממשק חיפוש: מפרידים בין קליטה לכתיבה, קובעים תקופת שמירת טרייסים וניקוי ישנים, מחליטים היכן להתקין סוכנים — על הצמתים או לצד האפליקציה.
-
אינסטרומנטציה של שירותים. מפעילים איסוף אוטומטי בספריות סטנדרטיות, קטעים קריטיים מסמנים ידנית, כדי שיופיעו בטרייס תכונות עסקיות. כאן גם קובעים כללי דגימה: איסוף מלא בשיא מנפח את האחסון, דליל — מפספס אנומליות.
-
בדיקה תחת עומס. מריצים תעבורה קרובה לזו של הפרודקשן ובודקים שלושה דברים: שיעור הטרייסים המודבקים, תקורה בצד השירות, התנהגות האחסון בשיא. כללי הדגימה מתקנים לפי המצב בפועל, לא לפי חישוב.
-
מסירת תיעוד ונהלים. מוסרים סכימות זרימה, תצורה, לוחות ניטור, כללי התראות וסדרי פעולה בעת ירידה בביצועים. הצוות מוסיף שירות חדש לנראות כבר בלעדינו.
מכאן והלאה נשארות רק התאמות: חיבור שירות או החלפת אחסון — זה שינוי תצורה, לא בנייה מחדש של המערכת.
ערכת מסירה: סכימות טריסינג, מדיניות סינון ונהלים
את הערכה אנחנו מוסרים לא כארכיון הגדרות, אלא כמתאר עובד: לכל מסמך יש בעלים ותרחיש שימוש. להלן מה נשאר בתשתית שלכם יחד עם Jaeger פרוס וכיצד להשתמש בזה בלעדינו.
- תצורות איסוף — קבצי קליטה ועיבוד של טרייסים עם כללי דגימה: אילו שירותים מתויגים במלואם, אילו לפי שיעור בקשות, אילו הוצאו בגלל נפח.
- סכימת זרימת טרייסים — תרשים נתיב הנתונים מהשירות לאחסון ולממשק החיפוש, עם נקודות כשל מסומנות ומקומות שבהם הטרייס הולך לאיבוד.
- מדיניות גישה — תפקידים ותחומי נראות: מי רואה את כל השירותים, מי רק את שלו, כיצד מוענקות ומבוטלות הרשאות, היכן מאוחסנים מפתחות.
- כללי אחסון — תוחלת חיים של טרייסים לפי סוגים, תנאי מחיקה מוקדמת, חלוקה לאינדקסים ודחיסה; בנפרד תקופה ארוכה לטרייסים של תקלות שנותחו.
- הוראות למשמרת תורן — כיצד תוך דקה לבדוק שהטריסינג חי, מה לעשות בעת עיכוב בקליטה וכיצד להחזיר אחורה שינוי בתצורה.
- נוהל בדיקות מתוכננות — השוואת נפח האחסון, בקרת שיעור הטרייסים שנזרקו, בדיקת מקצה לקצה לאחר עדכון שירותים.
- מפת אינסטרומנטציה — שירותים וספריות עם גרסאות, כדי שבעת עדכון לא לאבד תאימות ולא להישאר בלי טרייסים.
- יומן שינויים — מי ולמה שינה את כללי הדגימה; בלעדיו, כעבור חצי שנה איש לא יסביר את היעלמות הטרייסים של שירות מסוים.
מקרה בוחן: כיצד קיצרנו את זמן חיפוש סיבת התקלה
פלטפורמה של כמה עשרות שירותים, חלק מהתקשורת — דרך תורים. בתקלה, התורן ראה זינוק בשגיאות בכניסה, אבל הסיבה לעתים קרובות הייתה בשירות השלישי-רביעי בשרשרת, והלוגים של כל שירות חיו בנפרד. לא היה מזהה בקשה אחיד — אירועים קושרו ידנית, לפי זמן ולפי סימנים עקיפים.
איתור הסיבה ארך 3-4 שעות, ועוד אותו זמן — לאישור ההשערה. כשליש מהתקלות נסגרו בלי סיבה מוסברת: הסימפטום הוסר, השורש לא נמצא, וכעבור כמה שבועות הוא הופיע במקום אחר. זמן השחזור הממוצע עמד על כמה שעות.
מה שינינו
הטמענו Jaeger ומזהה בקשה מקצה לקצה, שמועבר דרך כל הקריאות, כולל אסינכרוניות. תייגנו מקומות שבהם הזמן הלך לאיבוד לרוב: פניות לבסיס הנתונים, קריאות חוץ, הצבה ועיבוד של הודעות בתורים. הדגימה הוגדרה אדפטיבית — בקשות איטיות ונדירות נשמרות במלואן, וזרימת השגרה לא מנפחת את האחסון.
מה השתנה
קישור לטרייס מצורף לכרטיס התקלה — הניתוח מתחיל מעובדה, לא מחיפוש גרסאות. האיתור התקצר ל-10-15 דקות, זמן השחזור — פי כמה, ושיעור התקלות בלי סיבה מוסברת ירד למקרים בודדים. תקלות חוזרות נראו בתמונה הכללית של הקריאות, וסוגרים אותן בדיון, לא אחרי הפנייה השלישית.
במה Jaeger שונה מאיסוף לוגים ומטריקות
יומנים ומדדים מספריים עונים על שאלות שונות, אבל שניהם מסתכלים על המערכת בשברים. מטריקה מראה שההשהיה גדלה או ששיעור התגובות המוצלחות ירד — אבל לא אומרת באיזה שלב זה קרה. יומן מתעד אירוע עם טקסט והקשר של שירות בודד, ובמתאר מבוזר יש להשוות אותו ידנית עם רשומות של שכנים לפי זמן.
טריסינג ב-Jaeger נבנה סביב הקונטקסט של הבקשה: מוקצה לה מזהה שמועבר דרך כל הקריאות, וכל שלב משאיר רשומה עם משך זמן וקשר לשלב האב. מתקבל עץ — נתיב הבקשה בין השירותים בשלמותו, כולל ענפים אסינכרוניים דרך תורים וניסיונות חוזרים.
גבול היישום פשוט. יומנים הכרחיים כשצריך טקסט שגיאה מדויק או ערך של שדה. מדדים מספריים — כשחשובים מגמות, התראות ועלות אחסון: הם קומפקטיים וזולים בטווח ארוך.
נתיב הבקשה נחוץ במקומות שבהם אובדן זמן נולד במפגש בין שירותים: מטריקה מוצאת זינוק, טריסינג מצביע על שלב ספציפי וחלקו בהשהיה הכוללת, ויומן לפי אותו מזהה נותן את הסיבה.
הם משלימים זה את זה, ולא מחליפים: הצירוף 'זינוק → שלב ספציפי → הודעת שגיאה' מקצר את חיפוש הסיבה משעות לדקות. עם זאת, אין צורך לתייג הכל — דגימה בכניסה קובעת את שיעור הבקשות הנרשמות, וסינון לפי שגיאות ותגובות איטיות משאיר בדיוק את אלה שכדאי לנתח.
ספקות טכניים: עומס, נפח נתונים, תאימות
ספקות לגבי עומס ונפח אחסון מופיעים כשהטריסינג כבר פעיל בכמה שירותים ורואים כמה נתונים מכניסה כל פעולה. להלן תשובות לשאלות שמהנדסים שואלים לפני חיבור שאר השירותים.
כמה יגדל זמן התגובה?
העבודה הנוספת — רישום מרווחים והעברת קונטקסט בין שירותים. כשדוגמים חלק מזרימת הבקשות, הגידול נשאר בטווח של אחוזים בודדים, ובנתיבים קריטיים שמים כללי עדיפות נפרדים. מדידות נלקחות לפני ואחרי ההפעלה במתאר הפרודקשן, ולא מוערכות בעין.
כמה מהר גדל נפח האחסון?
את הנפח קובעים שלושה דברים: מספר הפעולות המתויגות, מקדם הדגימה ותקופת האחסון. מרווחים גולמיים נשמרים כמה ימים, מחברים — יותר זמן, ולכל שם שירות מגדירים מדיניות מחיקה. המאגר מפסיק לגדול ללא שליטה, וניתוח תקלה מהשבוע שעבר נשאר אפשרי.
האם זה תואם לסביבות ולסטאקים שלנו?
האיסוף מתבצע בפורמט אחיד לקונטיינרים, מכונות וירטואליות ופונקציות ללא שרת: הסוכן מותקן לצד האפליקציה, לכן מעבר בין סביבות לא משנה את סכימת הנתונים. גם הסטאק לא קריטי — ספריות אינסטרומנטציה קיימות לשפות עיקריות, ומעטפות לא סטנדרטיות מכסים במרווחים ידניים או בשער מתווך.
מה לעשות עם שירותים שתויגו חלקית?
אותם מחברים בהדרגה: נקודות הקצה — מאזן עומסים, שער, בסיס נתונים — נותנות תמונה מקצה לקצה מיד, וחוליות ביניים מוסיפים עם ההתאמות בקוד. פער בשרשרת נראה כמרווח נפרד ומסומן בסכימות כקטע לא סגור, אבל זה לא מפריע למצוא את צוואר הבקבוק.
האם אפשר להפחית את האיסוף בלי לבנות מחדש את השירותים?
כן. הדגימה והקליטה מנוהלות בצד האוסף: בעומס חריג מספיק להקטין את המקדם או להשבית זמנית את המקור — האפליקציות ממשיכות לעבוד. חזרה לתצורה קודמת של הסוכן גם אינה מצריכה ריליס.
נדון במשימה: מה יידרש מצדכם
הסוכן אוסף טרייסים ושולח אותם ל-Jaeger, אבל כדי לפרוס קולטור ולחבר אותו לשירותים שלכם, צריך גישה לתשתית והבנה כיצד בנויים המתארים. להלן מה שאנחנו מבקשים בתחילת העבודה: זה מספיק כדי לחזור עם תוכנית והערכה, בלי סבבי הבהרות באמצע ההטמעה.
- גישות: חשבונות לאשכול ולמאגר התמונות, הרשאות ליצירת אובייקטים במרחב שמות נפרד — בלי הרשאות לשינוי עומסי הפרודקשן.
- רשימת שירותים: אילו אפליקציות מתייגים, באילו שפות וספריות הן כתובות, האם יש כבר ייצוא טרייסים כלשהו.
- סביבות: כמה מתארים — פיתוח, קדם-פרודקשן, פרודקשן; האם צריך Jaeger בכל אחד או שמספיק אחד עם הפרדה לפי מחלקות.
- דרישות לתקופות אחסון: כמה ימים הטרייסים צריכים להישאר זמינים לניתוח תקלות ומי ניגש אליהם.
- סדר אישור שינויים: מתי אפשר להעלות שינויים בתצורת השירותים, מי מאשר, האם נדרשת חזרה אחורה בצעד אחד.
- סכימת קשרים בין שירותים: האם יש פרוקסים ומאזני עומסים שצריך להתחשב בהם כדי שהקונטקסט לא ילך לאיבוד.
- אחראי קבלה: מהנדס שיבדוק שהטרייסים נאספים מקצה לקצה ונמצאים לפי מזהה הבקשה.
תארו את המשימה ושלחו את הנתונים האלה — נחזור עם תוכנית עבודה: שלבים, גבולות האחריות שלנו, סדר העלאה לפי סביבות ונקודות שבהן נדרש אישורכם.