הגדרת Datadog APM לאפליקציות מובייל: iOS, Android, Flutter

הגדרת Datadog APM: מה נשבר ללא טרייסינג בפרודקשן

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

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

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

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

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

מה נותן טרייסינג מקצה לקצה באפליקציות מובייל

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

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

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

מצבי איסוף נתונים וכיוונון עדין של הדגימה

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

להלן שלושה מצבים שבאמת בוחרים ביניהם בתחילת ההטמעה.

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

איך עוברת ההטמעה: מביקורת ועד מסירה לצוות

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

1. ביקורת מוניטורינג של האפליקציה. מפרקים אילו אירועים, כשלים ומטריקות כבר נאספים, היכן הולך לאיבוד הקשר בין סשן המשתמש לבקשה בשרת, ואילו קריסות בכלל לא נראות.
2. סכמת נקודות מדידה. קובעים אילו פעולות מכסים: הפעלה, מעברים בין מסכים, קריאות רשת, אימות, תשלום. את הרשימה מתאמים עם הצוות שלכם — אירועים מיותרים יוצרים רעש ומנפחים את נפח האחסון.
3. שינויים בלקוח. מגדירים איסוף ב-iOS וב-Android, ובנפרד מטפלים ב-Flutter: חלק מהקריאות עוברות דרך שכבה משותפת, וצריך לקשר אותה נכון לשכבות הפלטפורמה.
4. חיבור חלק השרת. מחברים טרייסים של הלקוח עם אלה של השרת, כך שבקשה איטית אחת נקראת במלואה, ולא כשני רשומים מנותקים.
5. בדיקה בתרחישים אמיתיים. מריצים נתיבים טיפוסיים ותקלות: אובדן קשר, כשל שירות, ביטול פעולה. מוודאים שהכשל נראה ומגיע ללוח הניטור הנכון.
6. מסירת הפרויקט לצוות. משאירים קונפיגורציות, סכמת נקודות מדידה והוראות קצרות, מעבירים הדרכה — מכאן והלאה המפתחים שלכם מוסיפים אירועים חדשים בעצמם.

ארטיפקטים של ההטמעה: לוחות, מדיניות, נהלים

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

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

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

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

מקרה בוחן: איך הסרנו את האזור העיוור בהוצאת גרסאות מובייל

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

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

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

מטריקות לפני ואחרי: שיעור התשלומים המוצלחים עלה מ-88 ל-96%, ואיתור הסיבה לכשל מסוים הצטמצם משני-שלושה ימים ל-25-40 דקות — לפי הטרייסינג רואים באיזה שלב ובאיזו שכבה נשברת השרשרת.

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

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

במה שונה אינסטרומנטציה ידנית מאינסטרומנטציה אוטומטית?

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

אינסטרומנטציה אוטומטית עובדת ברמת הפלטפורמה והספריות: מיירטת קריאות רשת, פניות למסד נתונים, הצגת מסכים, זמן רינדור. הכיסוי מופיע מיד, בלי שינויים בקוד המוצר, אבל שמות הפעולות נוצרים מכנית — ״HTTP GET״, ״מסך נטען״ — ובזרם יש הרבה רעש שירותי. הבסיס ב-Datadog נותן ספאנים, אבל עדיין צריך להרכיב מהם נתיב משתמש משמעותי ביד.

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

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

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

שאלות טכניות נפוצות בנוגע לפריסה ותמיכה

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

איך זה ישפיע על צריכת הסוללה?

אוספים במנות עם באפר מקומי, שולחים במסך פעיל וב-Wi-Fi, מדידות רקע כבויות. משווים יום עבודה לפני ואחרי ההפעלה.

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

כן. iOS או Android מחברים בנפרד — סכמת השמות משותפת, והפלטפורמה השנייה מתיישבת בלי סימון מחדש. שכבת Flutter מכווננת בנפרד מהחלקים הנייטיב.

למי יישארו הגישות אחרי המסירה?

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

האם זה יסתדר עם המוניטורינג הנוכחי?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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