Dynatrace APM: מדוע אפליקציית המובייל "מאטה" בלי ששמים לב
תמונה אופיינית: המשתמשים מתלוננים על תקיעות ונשירות, בעוד שצד השרת מציג גרף יציב — זמן התגובה תקין, אין שגיאות, המשאבים לא מתקרבים לתקרה. הפער מוסבר בפשטות: מדדי השרת רואים רק את הבקשות שהגיעו לשרת.
כל מה שקורה לפני כן — הפעלת האפליקציה, רינדור המסכים, עבודה עם אחסון מקומי, רשת המפעיל — נשאר מחוץ לתצפית. דווקא שם מסתתר צוואר הבקבוק.
Dynatrace APM סוגר את הקטע העיוור הזה: הסוכן מותקן בתוך האפליקציה עצמה ואוסף נתונים מהמכשיר של המשתמש, ולא מהשרת. ניתן לראות באיזה מסך המשתמש קופא, כמה זמן לוקח הפעלה קרה, אילו קריאות לשרת לא מגיעות ומדוע.
כשלים במכשיר מפסיקים להיות אנונימיים — במקום "אצל מישהו זה לא עובד" מופיעים גרסת אפליקציה ספציפית, דגם מכשיר, גרסת מערכת ומפעיל סלולרי.
מכאן התמונה מתגבשת לשרשרת סיבה ותוצאה. אם רק מפעיל אחד מאט — הבעיה ברשת, ולא בקוד. אם הכשל מתרחש בדגם מסוים — העניין בתאימות או במחסור בזיכרון. אם קריאה איטית חוזרת אצל כולם — צוואר הבקבוק הוא באפליקציה עצמה.
ניטור אפליקציית מובייל ב-Dynatrace APM מקשר בין התלונה, הסיבה הטכנית ושיעור המשתמשים שנפגעו, ולכן התיקונים מכוונים למקום שבאמת משפיע על החוויה, ולא לזה שמתלונן הכי בקול.
להלן נפרט כיצד זה מתפתח בפרויקט: מה בדיוק נאסף מהמכשיר, כיצד להפריד בין תקלות רשת לשגיאות קוד וכיצד להגדיר התראות כדי שנלמד על דעיכה לפני המשתמשים.
מה נותן ניטור מקצה לקצה: אפקט בגדלים מדידים
תיעוד מקצה לקצה מקשר בין פעולת המשתמש במכשיר לבין בקשה ספציפית לצד השרת ורשומות במסד הנתונים. בעבר נתונים אלה חיו במערכות שונות: יומן קריסות של המובייל בנפרד, מדדי השרת בנפרד, ואפשר היה להצליב ביניהם רק ידנית לפי זמן. כעת סשן אחד נפרש לשרשרת מלאה של קריאות — מהלחיצה ועד תגובת ה-backend, עם זמן בכל קטע.
זמן התגובה מפסיק להיות מספר ממוצע. ניתן לראות ש�Percentile ה-90 נשמר בטווח התקין, בעוד שהזנב גדל בגלל בקשה ספציפית לשירות ההזדהות. זה משנה סדרי עדיפויות: מייעלים לא את מה שנתקע לעתים קרובות יותר, אלא את מה שקובע את החוויה הגרועה ביותר.
שיעור הסשנים הכושלים נמדד לפי משתמשים, ולא לפי בקשות. סשן שבו אדם סגר את האפליקציה לאחר שלוש שגיאות רצופות נכנס לסטטיסטיקה פעם אחת — וזה הוגן יותר מאלף ניסיונות חוזרים של לקוח אחד.
סוג התקלה נקבע אוטומטית: רשת, שגיאת שרת, קריסה במכשיר או פסק זמן של אינטגרציה. המהנדס מקבל לא "משהו נשבר", אלא קטגוריה מדויקת עם שיוך לגרסת האפליקציה, לדגם המכשיר ולספק הסלולר.
ערך נפרד — שליטה בשחרורים. השוואת מדדים לפני ואחרי העלאה מראה אם שיעור הסשנים הכושלים עלה בגרסה החדשה, והחזרה לאחור מתקבלת לפי נתונים, ולא לפי תלונות בתמיכה.
דרכים לאיסוף נתונים: השוואת גישות לאינסטרומנטציה
אופן חיבור הניטור קובע אילו נתונים תראו בכלל. אינסטרומנטציה מלאה באמצעות סוכן על המכשיר מספקת טרייסים מבוזרים לכל קריאה, כולל מתודות פנימיות, אך דורשת בנייה מחדש של האפליקציה והתחשבות במדיניות פרטיות.
יירוט תעבורה ברשת (פרוקסי או פרופיל VPN) אינו נוגע בקוד, אך מאבד הקשר בתוך התהליך ואינו רואה משימות רקע ועבודה עם מטמון מקומי.
להלן — אפשרויות אמיתיות שבוחרים ביניהן בהתחלה, והמגבלות שלהן. ניתן לשלב ביניהן: הסוכן מכסה את העומק, היירוט — התחלה מהירה ללא שחרור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן על המכשיר (אינסטרומנטציה מלאה) | נדרשים טרייסים מבוזרים, מדדי קריסות וקפיאות UI, קשר עם ה-backend | בנייה מחדש ושחרור, גידול בגודל הבנייה, הגדרת פרטיות נתונים |
| מדדים ידניים דרך SDK | שליטה ממוקדת בתרחישי מפתח (תשלום, התחברות, השלמת רכישה) | מכסה רק נתיבים מסומנים, השאר — שטח עיוור |
| יירוט תעבורה (פרוקסי) | ביקורת רשת מהירה ללא שינוי האפליקציה, ניתוח בעיות אינטגרציות | אין הקשר בתוך התהליך, אינו רואה משימות רקע ומטמון מקומי |
| בדיקות סינתטיות | שליטה בזמינות ובזמן תגובה של תרחישים קריטיים מבחוץ | אינן משקפות התנהגות ומכשירים אמיתיים של משתמשים |
| לוגים ודוחות קריסה | אבחון בסיסי של קריסות וחריגות | אין קשר מקצה לקצה עם בקשות, קורלציה ידנית של אירועים |
בפועל, לרוב מוסיפים לסוכן על המכשיר יירוט בשלב ההטמעה: תחילה מצלמים את תמונת הרשת ללא שחרור, ואחר כך מוסיפים טרייסים עמוקים. כך הצוות מקבל נתונים מיד, ולא ממתין לבנייה הבאה.
איך מתבצעת ההטמעה: שלבי העבודה ההנדסית
את ההטמעה מתחילים בביקורת טלמטריה: בודקים אילו אירועים האפליקציה כבר שולחת, היכן הולך לאיבוד ההקשר בין סשן המשתמש לבקשה בצד השרת, ואילו תקלות נשארות בלתי נראות. בסיום מתעדים רשימת אותות שצריך לאסוף ונקודות שבהן אין כיום נתונים לניתוח תקלות.
- ביקורת הטלמטריה הקיימת. מנתחים לוגים קיימים, דוחות קריסה ומטריקות, ומסמנים פערים: קריאות רשת אינן נעקבות, אין הצמדה לגרסת הבילד, ומזהה הסשן הולך לאיבוד בעת הפעלה מחדש.
- תכנון סכמת האיסוף. מגדירים אילו אירועים, מטריקות וטראסים נאספים מהלקוח, מה נצבר בצד השירותים, וכיצד מקשרים את הסשן המובייל ל-backend — מזהה אחיד עובר דרך כל השכבות.
- סימון האפליקציה והשירותים. משתילים את האיסוף בתרחישי המפתח: הפעלה, התחברות, תשלום, עבודה עם נתונים. בנפרד מסמנים פעולות משתמש, כדי שירידת ההמרה תיקרא לפי שלבים ולא "איפשהו באפליקציה".
- הגדרת דשבורדים והתראות. בונים מסכים סביב שאלות אמיתיות: שיעור התרחישים המוצלחים, זמן התגובה של שירותים חיצוניים, תדירות התקלות לפי גרסאות. ספי ההתראות נקבעים כך שהתורן יקבל אות לפני שהמשתמשים יכתבו על הבעיה.
- בדיקה בסביבת בדיקות. מריצים תרחישים עם תקלות והשהיות מלאכותיות, ומוודאים שהאות מגיע למערכת, מקובץ כראוי ומגיע להתראה הנכונה. בנפרד בודקים את ההתנהגות ברשת גרועה ובמצב לא מקוון.
- מסירה לתפעול. מוסרים מערכת מוגדרת עם נוהל תורנות, תיאור של תקלות אופייניות וסדר פעולות, ומלמדים את הצוות לקרוא דשבורדים ולנתח תקלות לפי טראס.
לאחר המסירה המערכת ממשיכה לחיות: כללי האיסוף וספי ההתראות נבחנים מחדש ככל שהאפליקציה גדלה, כדי שהניטור לא יהפוך לרעש.
תוצרי פלט: תצורות, תרשימים ונהלים
אינטגרציה של Dynatrace אינה מסתיימת בסוכן מופעל, אלא בסט של תוצרי פלט שלפיהם ניתן לתחזק את המערכת בלעדינו. כל פריט מועבר למאגר של הלקוח ומנוהל בגרסאות יחד עם קוד האפליקציה — בשחרור הבא רואים מה ולמה השתנה בתצורה.
- תצורת ניטור — קבצים עם הגדרות לאיסוף מדדים, כללי תיוג בקשות וספי הפעלה. בנפרד מתעדים אילו אירועים נחשבים לתקלה ואילו לרעש רקע.
- תרשים זרימות נתונים — מאיפה נאספים המדדים, דרך אילו צמתים הם עוברים, היכן נשמרים וכמה זמן. לפיו מהנדס חדש מבין בתוך שעה היכן לחפש את סיבת הירידה בביצועים.
- מדיניות גישה — מטריצת תפקידים: מי רואה לוחות בקרה, מי משנה ספים, מי מקבל התראות. הרשאות ניתנות לפי עקרון המינימום ההכרחי.
- נוהל תורנות — סדר הפעולות בעת הפעלה: למי נשלח האות, תוך כמה זמן יש לאשר, מתי להסלים. עם תחומי אחריות מוגדרים בין צוות האפליקציה לתשתית.
- הוראות לתקלות אופייניות — תרחישים שלב-אחר-שלב לתקריות שכיחות: עלייה בשיעור הבקשות השגויות, ירידה בזמן התגובה במסך מסוים, נפילת אינטגרציה עם ה-backend.
- מפת לוחות בקרה — אילו פאנלים נצפים מדי יום, ואילו נפתחים רק בעת טיפול בתקרית. בלי זה התורן טובע בגרפים.
- נוהל rollback — כיצד להסיר או להחליש כללי איסוף אם הם מפריעים לשחרור, ומה הולך לאיבוד בכך ביכולת הנראות.
כל זה מוגש כתיעוד עבודה, ולא כדוח «למען הוי»: מתקנים אותו בכל שינוי באפליקציה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית, אילו תוצרי פלט נדרשים דווקא לכם.
מקרה בוחן: כיצד קוצר זמן איתור סיבת הכשלים
הפרויקט — בנק נייד עם קהל של מיליונים ב-iOS וב-Android. תלונות על "תקיעות בעת תשלום" הגיעו לתמיכה, אך לא ניתן היה לשחזר אותן: הלוגים מפוזרים בין הלקוח ל-backend, והקורלציה בין סשן המשתמש לבקשה לשירות לא הייתה קיימת. המהנדסים השקיעו באיתור הסיבה בממוצע 6-8 שעות, ובמחצית מהמקרים האירוע נסגר כ"לא משוחזר".
מה שינו
הטמיעו Dynatrace כמערכת מוניטורינג אחודה לביצועי האפליקציה: קישרו סשנים בצד הלקוח לטרנזקציות בשרת באמצעות מזהה מקצה לקצה, הפעילו מעקב אוטומטי אחר קריאות רשת, קריסות ומסכים "תקועים".
הגדירו התראות לפי תרחישי עסק מרכזיים — כניסה, תשלום, העברה — עם שיוך לגרסת אפליקציה ספציפית ולדגם מכשיר.
מה השתנה
זמן איתור סיבת הכשל הצטמצם מ-6-8 שעות ל-20-40 דקות: המהנדס פותח סשן בעייתי, רואה את כל השרשרת — מלחיצת הכפתור ועד תגובת השירות — ומיד מבין היכן צוואר הבקבוק. שיעור האירועים שנסגרו כ"לא משוחזר" ירד מ-50% ל-8%.
בנוסף הרוויחו בשחרורים: לפני הפצה משווים מדדים של הגרסה החדשה לקודמת ותופסים רגרסיה לפני שהמשתמשים מבחינים בה.
חודשיים לאחר ההשקה הצוות הפסיק לכנס ישיבות על כל תקלה — הנתונים כבר נאספו ומשויכים לתרחיש. ניתוח האירוע הפך מחקירה לקריאה של תמונה מוכנה.
במה שונה ניטור מכשיר מניטור שרת?
מדדי שרת מתארים את מצב ה-backend: עומס המעבד, זמן תגובת ה-API, עומק התורים, שיעור השגיאות בצד השירות. כל עוד מדדים אלה בטווח התקין, נחשב שהאפליקציה פועלת. אך בין השרת לבין מסך הטלפון משתרע נתיב ארוך — רשת המפעיל, מודול הרדיו, מערכת ההפעלה של המכשיר, תהליכי רקע, גרסת הבנייה. הבעיה נוצרת בכל אחד מהקטעים הללו, והשרת פשוט אינו יודע עליה.
פער הנראות הוא מצב שבו חלק השרת מגיב תוך 200 מילישניות, בעוד המשתמש רואה מסך קפוא. הסיבות שונות ומגוונות: אות חלש ברכבת התחתית, חיסכון אגרסיבי בסוללה שמפסיק את הסנכרון ברקע, התנגשות עם תוכנה אחרת, דליפת זיכרון בדגם מכשיר מסוים.
אף אחת מהן אינה באה לידי ביטוי במדדי השרת, מפני שהבקשה לשרת או שלא הגיעה כלל, או שהגיעה וטופלה כשורה.
ניטור מכשיר בוחן את המתרחש מנקודת מבט אחרת — מנקודת המבט של חוויית המשתמש. הוא מתעד את זמן האתחול הקר, את החלקלקות של הגלילה, את שיעור הקפיאות של הממשק, את קריסות האפליקציה, את משך פעולות הרשת בערוץ תקשורת מסוים, וכן פילוח לפי דגמי מכשירים וגרסאות מערכת הפעלה. דווקא נתונים אלה מראים שהתקלה משוחזרת בקרב חלק מהקהל עם תצורה מסוימת, ולא אצל כולם כאחד.
ההבדל המרכזי הוא בנקודת המדידה ובשאלה את חווייתו של מי היא מתארת. מדדי שרת עונים על השאלה "האם התשתית מתמודדת", ניטור מכשיר — "האם האדם שמחזיק את הטלפון בידיו מרוצה".
שתי התמונות נחוצות בו-זמנית: הראשונה מציגה את המשאבים ואת צווארי הבקבוק של ה-backend, השנייה — את תנאי ההפעלה בפועל, שאי אפשר לשחזר בסביבת בדיקות.
Dynatrace APM מקשר בין שתי השכבות הללו לשרשרת אחת: מנגיעה במסך ועד תגובת השרת ובחזרה. כאשר משתמש מתלונן על טעינה איטית, המהנדס רואה באיזה קטע אבד הזמן — ברשת, במכשיר או בשירות — ואינו מבזבז ימים על חיפוש הסיבה בעיוורון. בלי קישור כזה, הצוות מתקן שרת שממילא עבד, בעוד חוויית המשתמש ממשיכה להידרדר.
ספקות טכניים נפוצים לפני ההתחלה
לפני תחילת האינטגרציה כמעט תמיד עולים אותם שאלות: האם האפליקציה תיחלש, האם יהיה צורך לכתוב מחדש מודולים, האם איסוף הטלמטריה יהפוך לסעיף הוצאה נפרד על אחסון. להלן — תשובות ענייניות, בלי שיווק.
האם הניטור יאט את האפליקציה עצמה?
התקורה של הסוכן — שברי אחוז מזמן רינדור הפריים ומפעולות הרשת. המדידות ושליחת הטלמטריה מתבצעות בתהליכון רקע, במנות, ולא בכל קריאה. בפועל המשתמש לא מבחין בהבדל: זמן ההפעלה הקרה והמגיבוּת של הממשק נשארים בגבולות טעות המדידה.
אם האפליקציה כבר על גבול הזיכרון, הסוכן מוגדר למצב פירוט מופחת — תחילה נלקחות מדידות בסיסיות, וניתוח מעמיק מופעל נקודתית.
האם זה תואם לסטאק שלנו ולגרסאות מערכת ההפעלה?
הסוכן תומך באפליקציות נייטיביות וחוצות-פלטפורמות, בענפי מערכות ההפעלה לנייד העדכניים ובגרסאות המייג'ור הקודמות שלהן. אם חלק מהקוד מבוסס על פריימוורק מיושן, זה לא חסם: הניטור מתחבר לשכבת האפליקציה, ולא לכל מודול בנפרד.
בשלב הסקר אנו משווים את מטריצת המכשירים והגרסאות שלכם לרשימה הנתמכת ואומרים ישירות היכן יהיו פערים בנתונים.
כמה נתונים ייצאו ואיך לשלוט בזה?
הנפח תלוי במה שהחלטתם לאסוף. כברירת מחדל — מדדים מצטברים וטראסות נדגמים, ולא נכתבים במלואם. כללי האחסון נקבעים מראש: משך החיים של נתוני הגלם, שיעור הדגימה, חיתוך אירועים רועשים. כך הנפח נשאר צפוי, ואיתור תקלה ספציפית — אפשרי, כי הטראסות הדרושות נשמרות.
האם הטלמטריה בטוחה — האם נתוני משתמשים ידלפו?
הטלמטריה אינה כוללת נתונים אישיים: מיסוך שדות ואיסור על העברת ערכים רגישים מוגדרים כבר בהתחלה. ההעברה מתבצעת בערוץ מאובטח, והגישה ללוחות מופרדת לפי תפקידים. מדיניות האחסון והמחיקה מתואמת עם הדרישות שלכם — זה חלק מהעבודה, ולא אופציה לאחר ההשקה.
אם נשארו ספקות לגבי סעיף כלשהו — תארו את התצורה שלכם, ונחזור עם הערכה ותוכנית אינטגרציה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכת לוחות זמנים ותוכנית הטמעה, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה: פלטפורמה וגרסאות מערכות הפעלה שהאפליקציה תומכת בהן, אופן הבנייה ומחזור השחרור הנוכחיים, רשימת שירותים חיצוניים ומודולים פנימיים, גישה למאגרי הקוד ולסביבת הבדיקות. אם כבר קיים APM-סוכן או איסוף מדדים — הראו מה בדיוק נאסף כעת והיכן הנתונים הולכים לאיבוד.
מצד הלקוח מספיק להקצות אדם אחד שמאשר עדיפויות ועונה על שאלות בנוגע לארכיטקטורה. השאר — העבודה שלנו. בתגובה אנחנו מכינים:
- תוכנית הטמעה לפי שלבים: הכנת הסביבה, חיבור הסוכן, הגדרת איסוף הנתונים, סימון תרחישי המפתח, הוצאה לדשבורדים;
- היקף העבודה עם גבולות אחריות — מה אנחנו עושים, מה נשאר בצד הלקוח;
- הערכת לוחות זמנים לכל שלב ונקודות שבהן נדרשת הקבלה שלכם;
- סכמת סימון מסלולי משתמש קריטיים: כניסה, תשלום, ביצוע הזמנה, סנכרון;
- רשימת מדדים והתראות שהצוות יקבל בסיום, עם ספי הפעלה;
- דרישות לגישות, סביבות וחשבונות בדיקה;
- תוכנית נסיגה, אם הסוכן משפיע על יציבות הבנייה או על התנהגות האפליקציה;
- תקנון תמיכה: מי ואיך מגיב לאירועים לאחר ההשקה.
תארו את המשימה — אילו תקלות מטרידות כעת, באילו פלטפורמות ובאילו תרחישים, ואיזו תוצאה נחשבת בעיניכם להצלחה. אנחנו נחזור עם הערכת לוחות זמנים, היקף עבודה ותוכנית הטמעה שאפשר לקבל לפיה החלטה.