מעקב מבוזר: עשינו את זה לא נכון

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

[איור נלקח מתוך חומר אחר על מעקב מבוזר.]

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

האתגר העיקרי של מעקב מבוזר הוא לא איסוף נתונים, סטנדרטיזציה של פורמטים להפצה והצגת תוצאות, או קביעה מתי, איפה ואיך לדגום. אני לא מנסה לדמיין קַטנוּנִי "בעיות ההבנה" הללו הן, למעשה, טכניות משמעותיות למדי ו(אם אנחנו שוקלים באמת קוד פתוח) תקנים ופרוטוקולים) אתגרים פוליטיים שצריך להתגבר עליהם כדי שבעיות אלו ייחשבו כפתורות.

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

זכר כזה שונה

מעקב מבוזר כולל מספר מרכיבים שונים:

• ציוד יישומים ותוכנות ביניים בכלי בקרה;
• העברת הקשר מבוזרת;
• אוסף עקבות;
• אחסון עקבות;
• החילוץ וההדמיה שלהם.

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

הערה. תרגום: כדי להפוך טקסט נוסף לקל יותר להבנה, הבה נגדיר שני מונחים בסיסיים לפי תיעוד פרויקט OpenTracing:

• לְהַקִיף - המרכיב הבסיסי של מעקב מבוזר. זהו תיאור של זרימת עבודה מסוימת (לדוגמה, שאילתת מסד נתונים) עם שם, זמני התחלה וסיום, תגים, יומנים והקשר.
• טווחים מכילים בדרך כלל קישורים לטווחים אחרים, המאפשרים לשלב טווחים מרובים עקבות - הדמיה של חייה של בקשה כשהיא נעה במערכת מבוזרת.

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

• למשל, אובר использует מעקב אחר תוצאות כדי להבדיל בין תעבורת בדיקה לתעבורת ייצור.
• פייסבוק использует נתוני מעקב לניתוח נתיב קריטי ולמעבר תנועה במהלך בדיקות התאוששות מאסון רגילות.
• גם רשת חברתית חל מחברות Jupyter המאפשרות למפתחים להריץ שאילתות שרירותיות על תוצאות מעקב.
• חסידים LDFIA (הזרקת כשל מונע בשושלת) שימוש חילקו עקבות לבדיקה עם הזרקת שגיאה.

אף אחת מהאפשרויות המפורטות לעיל אינה חלה לחלוטין על התרחיש לנפות, שבמהלכו המהנדס מנסה לפתור את הבעיה על ידי התבוננות בעקבות.

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

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

בעבר אני התלונן נראה שרוב ה"חידושים" במעקב UI/UX מוגבלים אליהם מדליק מטא נתונים נוספים במעקב, משקיעים בהם מידע עם קרדינליות גבוהה (קרדינליות גבוהה) או לספק את היכולת להתעמק בטווחים ספציפיים או להפעיל שאילתות inter-ו-inttra-trace... שבו צפייה במסלול נשאר כלי ההדמיה העיקרי. כל עוד מצב עניינים זה נמשך, מעקב מבוזר יתפוס (במקרה הטוב) את המקום הרביעי ככלי איתור באגים, אחרי מדדים, יומנים ועקבות מחסניות, ובמקרה הרע יתברר כבזבוז של כסף וזמן.

בעיה עם traceview

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

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

אם אתה באמת מערכת מבוזרת מורכבת להפליא, אז אף אדם לא מסוגל להחזיק את זה בראשו полную תְמוּנָה. למעשה, פיתוח כלי המבוסס על ההנחה שזה בכלל אפשרי הוא משהו אנטי-דפוס (גישה לא יעילה ולא פרודוקטיבית). באופן אידיאלי, איתור באגים דורש כלי שעוזר לצמצם את אזור החיפוש שלך, כך שמהנדסים יכולים להתמקד בתת-קבוצה של ממדים (שירותים/משתמשים/מארחים וכו') הרלוונטיים לתרחיש הבעיה הנחשב. בעת קביעת הסיבה לכשל, מהנדסים אינם נדרשים להבין מה קרה במהלך כל השירותים בבת אחת, מכיוון שדרישה כזו תסותר את עצם הרעיון של ארכיטקטורת מיקרו-שירותים.

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

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

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

אבוי, צפייה במסלול לא יכול להיקרא כלי עם ממשק אינטראקטיבי. הדבר הטוב ביותר שאתה יכול לקוות לו בעת השימוש בו הוא למצוא מקור כלשהו להשהייה מוגברת ולבחון את כל התגים והיומנים האפשריים הקשורים אליו. זה לא עוזר למהנדס לזהות דפוסים בתנועה, כגון הפרטים של התפלגות ההשהיה, או זיהוי מתאמים בין מדידות שונות. ניתוח עקבות כללי עשוי לעזור לעקוף חלק מהבעיות הללו. בֶּאֱמֶת, יש דוגמאות ניתוח מוצלח באמצעות למידת מכונה כדי לזהות טווחים חריגים ולזהות תת-קבוצה של תגים שעלולים להיות קשורים להתנהגות חריגה. עם זאת, עדיין לא ראיתי הדמיות משכנעות של למידת מכונה או ממצאי כריית נתונים מיושמים על טווחים שונים באופן משמעותי מ-traceview או DAG (גרף א-ציקלי מכוון).

הטווחים ברמה נמוכה מדי

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

יתר על כן, אני אקח את החופשי לטעון את הדברים הבאים: באופן אידיאלי, אנחנו לא צריכים תמונה מלאה התרחש במהלך מחזור החיים של הבקשה, המיוצג על ידי כלי מעקב מודרניים. במקום זאת, נדרשת צורה כלשהי של הפשטה ברמה גבוהה יותר המכילה מידע על מה השתבש (בדומה ל-backtrace), יחד עם הקשר כלשהו. במקום לצפות בכל המעקב, אני מעדיף לראות אותו часть, שבו קורה משהו מעניין או יוצא דופן. נכון לעכשיו, החיפוש מתבצע באופן ידני: המהנדס מקבל את העקבות ומנתח באופן עצמאי את הטווחים בחיפוש אחר משהו מעניין. הגישה של אנשים בוהים בטווחים בעקבות בודדים בתקווה לזהות פעילות חשודה אינה משתנה כלל (במיוחד כאשר עליהם להבין את כל המטא נתונים המקודדים בטווחים שונים, כגון מזהה טווח, שם שיטת RPC, משך טווח 'א, יומנים, תגים וכו').

חלופות ל-traceview

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

אני לא מעצב חזותי או מומחה UX, אבל בסעיף הבא אני רוצה לחלוק כמה רעיונות איך ההדמיות האלה עשויות להיראות.

התמקד בשירותים ספציפיים

בתקופה שבה התעשייה מתגבשת סביב רעיונות SLO (יעדי רמת השירות) ו-SLI (מדדי רמת השירות), נראה הגיוני שצוותים בודדים יתעדיפו להבטיח שהשירותים שלהם מתאימים ליעדים אלה. מכאן נובע מכוון שירות הדמיה מתאימה ביותר לצוותים כאלה.

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

1. דיאגרמות התפלגות חביון רק עבור בקשות בולטות ביותר (בקשות חריגות);
2. דיאגרמות של חלוקת עיכובים למקרים בהם יעדי SLO שירות לא מושגות;
3. התגים הכי "נפוצים", "מעניינים" ו"מוזרים" בשאילתות שלרוב חוזרים על עצמם;
4. פירוט חביון למקרים שבהם תלוי השירותים אינם משיגים את יעדי ה-SLO שלהם;
5. פירוט חביון עבור שירותים שונים במורד הזרם.

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

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

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

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

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

בניית טופולוגיה

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

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

בואו ניקח דוגמה. בואו נדמיין אתר חדשות היפותטי. שירות דף הבית (עמוד ראשי) מחליף נתונים עם Redis, עם שירות המלצות, עם שירות פרסום ושירות וידאו. שירות הווידאו לוקח סרטונים מ-S3 ומטא נתונים מ-DynamoDB. שירות ההמלצות מקבל מטא נתונים מ-DynamoDB, טוען נתונים מ-Redis ו-MySQL וכותב הודעות לקפקא. שירות הפרסום מקבל נתונים מ-MySQL וכותב הודעות לקפקא.

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

דיאגרמת שירות של אתר חדשות היפותטי

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

טופולוגיה דינמית המציגה שירותים "מעניינים" בלבד

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

תצוגה השוואתית

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

השוואה בין שני עקבות אינה דורשת הדמיות חדשות ביסודו. למעשה, מספיק משהו כמו היסטוגרמה המייצגת את אותו מידע כמו Traceview. למרבה ההפתעה, אפילו השיטה הפשוטה הזו יכולה להביא הרבה יותר פירות מאשר לימוד שני עקבות בנפרד. אפילו יותר חזק תהיה האפשרות לַחֲזוֹת השוואה בין עקבות בסך הכל. זה יהיה שימושי ביותר לראות כיצד שינוי בתצורת מסד הנתונים שנפרס לאחרונה כדי לאפשר GC (איסוף אשפה) משפיע על זמן התגובה של שירות במורד הזרם בקנה מידה של מספר שעות. אם מה שאני מתאר כאן נשמע כמו ניתוח A/B של ההשפעה של שינויים בתשתית בשירותים רבים אם תשתמש בתוצאות העקבות, אתה לא רחוק מדי מהאמת.

מסקנה

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

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

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

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

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «תוסף kubectl-debug לניפוי באגים בתרמילים של Kubernetes";
• «שירותי מיקרו: הגודל קובע, גם אם יש לך Kubernetes";
• «ניטור ו-Kubernetes (סקירה ודוח וידאו)".

מקור: www.habr.com