מעקב מבוזר: מה נשבר בלי Tempo ו-Grafana
כל עוד המערכת מורכבת משירות אחד, השאלה «איפה בדיוק יש האטה» נפתרת על ידי צפייה ביומן האפליקציה. ברגע שמופיעים שער, כמה שירותים ותור הודעות, המדדים מראים שזמן התגובה עלה, אבל לא מראים באיזה קטע בשרשרת הקריאות זה קרה. התשובה מפוזרת בין היומנים של כל השרתים, והקשר ביניהם נראה רק לפי מזהה הבקשה, שלא תמיד מגיע עד הסוף.
ניתוח תקלה הופך להרכבה ידנית: מהנדס מוריד יומנים מכמה צמתים, משווה חותמות זמן, משחזר את סדר הפניות — ובכל זאת לא רואה קריאות שלא השאירו רשומות. בזרם של כשלים מדובר בשעות עבודה של כמה אנשים, והסיבה לא תמיד נמצאת: לעתים קרובות יותר נמצא הקטע שפשוט לעתים קרובות יותר נמצא בחשד.
אזורים עיוורים בניטור נמצאים בדרך כלל במקום שבו הקריאה אינה סינכרונית: משימות רקע, פרסום לתור, ניסיונות חוזרים לאחר פקיעת זמן ההמתנה. צומת תקול אחד יוצר סדרה של חזרות, ולפי המדדים זה נראה כעלייה כללית בעומס, ולא ככשל מסוים. בלי מעקב מבוזר מאבחנים מפלים כאלה בדיעבד, כשההידרדרות כבר פגעה במשתמשים.
מעקב מבוזר סוגר את זה: שרשרת הקריאות נאספת בכל השירותים, כולל מעברים אסינכרוניים, וניתוח התקלה מתחיל מקטע איטי מסוים, ולא ממיון יומנים. בהמשך נסביר איך זה בנוי על Tempo ו-Grafana ומה צריך כדי שהנראות בין השירותים תופיע לא רק בתאוריה.
מה נותן מעקב מקצה לקצה: זמן תגובה וניתוח כשלים
מעקב מקצה לקצה מקשר בקשה אחת של משתמש עם כל הקריאות שהיא יצרה: משער הכניסה ועד התור, המטמון ומסד הנתונים. במקום עשרה יומנים מפוזרים יש ביד מסלול אחד עם משך הזמן של כל קטע. Tempo בשילוב עם Grafana שומר את המסלולים האלה ומאפשר לחפש בהם — לפי קוד התגובה, שם הפעולה, משך הזמן.
האפקט המדיד הראשון — זמן איתור הסיבה. כל עוד הניתוח נעשה לפי יומנים, המהנדס עובר על השירותים ידנית, והתקלה אורכת כשעה. מעקב מראה את הקטע הבעייתי מיד: רואים באיזה שלב הבקשה איבדה זמן או נפלה, והניתוח מסתיים בתוך 5–10 דקות.
במקביל גדל שיעור הכשלים שנמצאו — חלק מהכשלים לא משאירים רשומה ביומני האפליקציה, ובעקבה נשאר קטע קטוע.
האפקט השני — צמצום זמן ההשבתה. ככל שהאחראי נמצא מהר יותר, כך חלון הזמן שבו המשתמשים מקבלים שגיאות קצר יותר. בתקלה טיפוסית, ההבדל בין חיפוש ידני לעבודה לפי עקבה הוא עשרות דקות של אי-זמינות: חזרה לאחור או מעבר לענף גיבוי מופעלים כשהתמונה עוד טרייה, ולא אחרי ניתוח ארוך.
האפקט השלישי — מחלקה שלמה של כשלים שבדרך אחרת כמעט לא נתפסת: בקשות איטיות נדירות, הידרדרות תחת עומס, שגיאות בממשק בין שירותים. לפי מדדים בודדים הם נראים כתקינים, ובעקבה רואים שקטע אחד מוסיף השהיה באופן קבוע. הניתוח מפסיק להיות ניחוש, וכשלים כאלה נכנסים לסטטיסטיקה, ולא צפים שוב.
חיבור Tempo ל-Grafana: השוואת אפשרויות פריסה
Grafana מתחברת ל-Tempo כמקור נתונים סטנדרטי דרך HTTP, והאינטגרציה עצמה נראית זהה בכל התרחישים. הפיצול הוא במקום אחר: היכן פיזית נמצאים בלוקי העקבות, מי מתחזק את האחסון ולאיזו תקופה הוא מיועד. מזה תלויים תקופת השמירה, העומס על השירותים ואופן ההפרדה בין סביבות.
אפשרויות מיקום אחסון העקבות
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דיסק מקומי על צומת אחד | ארגז חול, דיבוג, זרימה קטנה | אין שכפול, תקופת השמירה מוגבלת בגודל הדיסק |
| אחסון אובייקטים במצב מונוליטי | זרימה בינונית, נדרש שליטה מלאה בנתונים | תהליך אחד אחראי גם על הקליטה וגם על דחיסת הבלוקים |
| מצב מבוזר מעל אחסון אובייקטים | זרימה גבוהה, שמירה ארוכה | יותר רכיבים — קשה יותר לתחזק ולהרחיב |
| שירות מנוהל | אין צוות תפעול משלכם | הנתונים מחוץ לסביבה שלכם, ההפרדה נקבעת על ידי הספק |
תקופת השמירה נקבעת במדיניות ברמת הבלוקים: רכיב רקע מוחק בלוקים ישנים מחלון שהוגדר, ואת הכללים אפשר לקשור לדיירים שונים. כך עקבות של מוצר נשמרות חודשים, וזרימת דיבוג מסביבת בדיקות מנוקה בתוך ימים — בלי אשכול נפרד לכל אחד.
העומס על השירותים נקבע לא לפי אפשרות האחסון, אלא לפי נפח הספאנים הנשלחים: חוצץ הקליטה ממתן פיקים, אבל אינו אינסופי, ולכן מגדירים דגימה ומגבלות לדייר.
ההפרדה בין סביבות נעשית או באמצעות מופעי Tempo נפרדים לפרודקשן ולסטייג', או באמצעות מופע אחד עם מזהי דיירים שונים — הדרך השנייה זולה יותר לתחזוקה, אבל דורשת משמעת בהרשאות הגישה של Grafana.
שלבי הטמעת מעקב: מביקורת שירותים ועד מסירה
לפני שמחברים איסוף נתונים, צריך להבין איך המערכת בנויה באמת: אצל רוב הצוותים מפת הקריאות שונה מהמציאות, וחלק מהשירותים לא עברו אינסטרומנטציה. העבודה מתנהלת בחמישה שלבים — ממלאי ועד מסירת סביבת תחזוקה מוכנה.
- ביקורת שירותים וקשרים. אוספים רשימה של שירותים, תורים ותלויות חיצוניות, מסמנים מי קורא למי ואיפה הקריאות סינכרוניות. בפלט — רשימת שירותים בלי אינסטרומנטציה ו«אזורים עיוורים» במסלול הקריטי.
- תרשים זרימות בקשות. משרטטים מסלול מקצה לקצה של בקשה מנקודת הכניסה ועד האחסון, מסמנים נקודות מדידה מרכזיות. את התרשים מתאמים עם בעלי השירותים, אחרת מפת העקבות תסתור את הקשרים בפועל.
- הגדרת איסוף עקבות. פורסים קליטה ואחסון (Grafana Tempo), מחברים אפליקציות, קובעים שמות אחידים לשירותים ולפעולות, תקופת שמירה ושיעור דגימה. בלי כללי שמות משותפים, קטעים של אותה בקשה לא מתחברים לעקבה אחת.
- בדיקה על קבוצת שירותים פיילוט. לוקחים כמה שירותים במסלול הקריטי ובודקים תקורה, שלמות קשרים, זמן איתור סיבת הכשל. פערים סוגרים לפני פריסה על כל המערכת.
- נוהל תחזוקה ומסירה. מתעדים כללי שמות, תקופות שמירה, שאילתות אופייניות לתורן וסדר חיבור שירותים חדשים. צוות הלקוח מקבל תיעוד וניתוח על כשלים אמיתיים.
ערכת מסירה: קונפיגורציות, תרשימים ונוהלים
מעקב מביא תועלת כל עוד הצוות מבין איך הוא נאסף ולמה הוא מתנהג דווקא כך כשהעומס גדל. אנחנו מוסרים לא רק סביבה עובדת, אלא גם ערכה שלפיה המהנדסים שלכם משנים דגימה בעצמם, מוסיפים שירותים למסלולים ומנתחים תקלות בלי התמיכה שלנו.
- קבצי הגדרה של הקולט, האחסון והאוספים — עם הערות איזה פרמטר על מה אחראי ואילו ערכים בטוח לשנות בלי לבנות מחדש את הסביבה.
- תרשימי מסלולי בקשות: איך העקבה עוברת מהשירות עד האחסון, איפה היא הולכת לאיבוד בעומס יתר, אילו כללי דגימה חלים על אילו שירותים.
- מדיניות גישה: תפקידי מפתחים ותורנים, הפרדה לפי מרחבי שמות, סדר הנפקה ושלילה של מפתחות כשעובד עוזב.
- נוהל שמירה: תוחלת החיים של העקבות, מה מנוקה לפי לוח זמנים ואיך גדל נפח המרשם כשהעומס מוכפל.
- הנחיות למשמרת תורן: לאן להסתכל כשעקבות נעלמות, איך להבדיל בין הצפת אחסון לתקלת אספן ואילו פעולות בטוחות בלילה.
- רשימת בדיקות לפני קבלה: במה מאשרים שעקבה מגיעה מהשירות עד לבקשה, ואיך לשחזר כל בדיקה ידנית.
- מפת שירותים ובעלים: למי לפנות כשמשנים סכימת תגים או מוסיפים שירות חדש למסלול.
הערכה נשארת חיה: מעדכנים אותה יחד עם שינויי הסביבה ומנתחים עם הצוות שלכם במפגש נפרד. אחריו התורן סוגר תקלה טיפוסית בעצמו, בלי לחכות לנו.
מקרה בוחן: ניתוח תקלה הצטמצם משעתיים לעשר דקות
תקלה לילית בעומס שיא: השער התחיל להחזיר שגיאות, ההתראה הופעלה, התורן פתח את היומנים. אחר כך — כמעט שעתיים של חיפוש סיבת הכשל. חלק מהבקשות לא נכנסו ליומן האפליקציה, חלק אבדו בצד המטמון, המדדים הראו עלייה בהשהיה, אבל לא ענו איזו קריאה בדיוק יוצרת אותה.
את הסיבה חיפשו על ידי מעבר על השערות: שירות פנימי אחד חיכה לתשובה משירות שני, וזה עמד בתור על מאגר חיבורים. על התיקון עצמו עברו כעשרים דקות, והשאר — על להבין איפה להסתכל.
מה שינו
הפעלנו מעקב מבוזר על Tempo: השירותים שולחים ספאנים דרך קולט משותף, מזהה הבקשה עובר דרך כל הקריאות, כולל אסינכרוניות. יומנים ומדדים קישרנו לעקבות לפי המזהה הזה — במקום לעבור בין שלושה פאנלים, המהנדס פותח עקבה אחת ורואה באיזה קטע הזמן גדל. כללי ההתראות מחזירים קישור לעקבות איטיות באותו מרווח, ולכן הניתוח מתחיל לא מדף חלק.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| איתור סיבת כשל | ~100 דקות | 8–10 דקות |
| ניתוח בלי הסלמה לבכיר | מקרים בודדים | רוב התקלות |
| תמונה לפי בקשה | יומנים ומדדים בנפרד | עקבה, יומנים ומדדים על ציר אחד |
ממערכת הכשלים נעלם סוג נפרד — השהיות צפות, שלא שוחזרו מחוץ לעומס ולפני כן נסגרו «לפי תחושה». עכשיו תקלה כזאת מאושרת בעזרת עקבה בתוך דקות, ולא נשארת ברשימת הלא-מנותחות.
מה לעשות אם מעקב כבר נפרס חלקית?
הטמעה חלקית היא יותר כלל מאשר יוצא מן הכלל: מעקב מפעילים על שירות אחד או שניים כדי לבדוק את הגישה, ואחר כך הסביבה מתמלאת בקטעים בלי תרשים משותף.
הנתונים זורמים, אבל התמונה לא מתחברת: חלק מהשירותים שולחים עקבות מפורטות, אחרים — רק שגיאות, ואחרים מאבדים את המזהה כשמעבירים את הבקשה הלאה בשרשרת. אין צורך לבנות הכל מחדש — חשוב למצוא את הפערים ולהשלים את מה שכבר עובד.
מתחילים ממלאי: אילו שירותים שולחים נתונים, באיזו דרך ובאיזו רמת פירוט, ולאן הם מגיעים. אם יש כמה קולטים — חלק מהזרימה הולכת ל-Grafana Tempo, חלק לאספן אחר — אנחנו לא גוררים את שתי הסביבות במקביל, אלא מאחדים את הנתונים לאחת, כך שחיפוש לפי מזהה יחזיר את השרשרת כולה, ולא שבר שלה.
האיחוד נשען על שלושה דברים: שם שירות אחיד בכל המקורות, העברת הקשר מקצה לקצה דרך תורים ומשימות רקע, כללי דגימה ותקופות שמירה זהים.
עקבות לא שלמות נוצרות לרוב דווקא במעברים אסינכרוניים — במקום שבו ההקשר לא מועבר הלאה או נקטע במעבד ביניים; מקומות כאלה מוצאים וסוגרים נקודתית, בלי לכתוב מחדש את השירות.
העברת ההגדרות נעשית בלי לעצור את האיסוף: כללי הדגימה, תקופות השמירה והסימון מועברים מהסביבה שכבר עובדת, ולא מגדירים אותם מחדש.
בהמשך, השלמת הסביבה הקיימת מצטמצמת לחיבור השירותים החסרים ולבדיקת קישוריות — אחריה כל עקבה נקראת מנקודת הכניסה ועד הקריאה האחרונה, ולפי הזמן רואים איזה קטע מחזיק את ההשהיה.
ספקות טכניים: תקופות שמירה, עומס והרשאות
לפני ההתחלה צפות אותן שאלות — לא על המעקב עצמו, אלא על איך הוא יסתדר עם התשתית. עונים בקצרה כדי להסיר אותן לפני הערכה.
איזה נפח עקבות לשמור והאם הוא לא יתפח?
את הנפח קובעים שיעור איסוף הדגימה ומספר הבקשות. את השאר פותרת מדיניות השמירה: תקופה בסביבה החמה, דילול בלוקים ישנים, ייצוא לאחסון קר. כך הנפח מפסיק לגדול יחד עם מספר השירותים.
האם האיסוף לא יוסיף עומס על השירותים עצמם?
הסוכן שולח נתונים במנות, וכשאין מספיק רוחב פס הוא משליך חלק, ולא מעכב את עיבוד הבקשה. התקורה — שברי אחוז מזמן המעבד. לשירותים רגישים להשהיה מפעילים איסוף רק עבור בקשות איטיות ושגויות.
האם כל השירותים ייכנסו לתמונת העקבות?
הכיסוי תלוי בספריות באפליקציה: מחסניות עדכניות עוברות אינסטרומנטציה אוטומטית, בלי שינויי קוד. חלק מהמערכות מחברים נקודתית — תוכנית הכיסוי נערכת כבר בהתחלה ומסמנים מיד מה נשאר מחוץ למסגרת.
מה לעשות עם מערכות ישנות בלי תמיכה במעקב?
עבורן שמים פרוקסי שמשחזר את ההקשר מכותרות הבקשה הנכנסת. רכיב מיושן הופך לחוליה בשרשרת, ולא לחור בה. הכלל פשוט: מקבל בקשה — אפשר להעביר את ההקשר הלאה.
איך להפריד גישה בין צוותים?
באמצעות תפקידים במערכת הנראות: צוות רואה את השירותים שלו ואת מקורות הנתונים שלו, התורן — את כל התמונה, אבל בלי הרשאה לשנות את כללי האיסוף. הנתונים של צוותים שונים לא מתערבבים, והיסטוריית הבקשות נשארת בשליטה.
נדבר על המשימה: מה צריך כדי להתחיל בעבודה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם שאלות הבהרה, מספיק לשלוח חמישה דברים. גישה לסביבת העבודה בשלב הזה לא נדרשת — די בתיאור ובתרשים.
- תיאור המשימה. מה כואב: איפה הולך לאיבוד ההקשר בין השירותים, כמה זמן לוקח איתור סיבת כשל, אילו שאלות למערכת נשארות בלי מענה היום.
- רשימת שירותים. אילו רכיבים משתתפים בעיבוד הבקשה, באיזו שפה נכתבו, איך מתקשרים ביניהם — קריאות ישירות, תורים, משימות רקע. בנפרד סמנו מי כבר שולח מדדים ויומנים.
- תרשים סביבות. כמה סביבות ומה ההבדל ביניהן בהרכב השירותים ובעומס. בדרך כלל מעקב מטמיעים בסביבת בדיקות, ואת הפרודקשן מחברים אחרי בדיקה.
- סדרי עדיפויות בניתוח. מה לנתח קודם: שגיאות בקריאות חיצוניות, קטעי עיבוד איטיים, ניתוח תקלות בדיעבד או בקרה על זמני ביצוע פעולות.
- מגבלות והרשאות. מדיניות אבטחה, דרישות לשמירת נתונים, היכן אסור לשנות קונפיגורציה של שירותים, מי מאשר הרשאות. זה משפיע על תרשים האיסוף יותר מאשר נפח הנתונים.
- כלי העבודה הקיימים. מה כבר מותקן ואיך לשלב מעקב דרך Tempo ו-Grafana לצידו, בלי לשכפל את האיסוף.
הצעד הראשון מצדכם — שיחה קצרה על הנקודות האלה, בדרך כלל 20–30 דקות. אחר כך אנחנו חוזרים עם תוכנית: תרשים איסוף העקבות, נפח הנתונים ודרישות למשאבים, שלבי העבודה ומה שתראו אחרי כל שלב.