ניטור AI של אפליקציית מובייל: תיעוד ועלות

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

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

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

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

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

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

מה נותנת טלמטריה מנוהלת של פניות למודלים

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

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

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

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

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

שיטות איסוף לוגים: במכשיר, בשרת, היברידי

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

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

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

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

שלבי הטמעת תיעוד באפליקציית מובייל

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

1. ביקורת תיעוד. עורכים מלאי של נקודות הפנייה ל-AI: מסכים, משימות רקע, תרחישי אופליין; עבור כל אחת מתעדים סט שדות — מזהה סשן, סוג בקשה, זמן תגובה, קוד שגיאה, גרסת האפליקציה.
2. תוכנית אחסון לוגים. מחלקים את הרשומות למקומיות ולשרתיות: חוצץ במכשיר עם הגבלת נפח ורוטציה, תקופת שמירה, מיסוך נתונים אישיים לפני השליחה.
3. הגדרת שליחת הלוגים. העברה במקבצים לפי אירוע וטיימר, השלמת כתיבה לאחר ניתוק רשת, כללים נפרדים לרומינג ולערוץ חלש — הלוגים לא מתחרים בתעבורה הראשית.
4. בדיקה בעומס אמיתי. הרצה על תעבורה חיה: שיעור הרשומות שאבדו, השהיית האספקה, ההשפעה על זמן העלייה וצריכת הסוללה.
5. קבלת יכולת הצפייה (observability). בודקים שמסלול הבקשה משוחזר מהלחיצה ועד התשובה, ושעל זינוק בשגיאות ועלייה בזמן התגובה מופעלות התראות.
6. העברה ותמיכה. מוסרים תיאור של פורמט הרשומות, נהלים להוספת שדות חדשים וסדר תורנות להתראות.

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

מה נשאר בפרויקט: תוכנית הלוגים, כללים, נהלים

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

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

מקרה בוחן: חקירת הכישלונות התקצרה, נפח הלוגים קטן

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

מה שינינו

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

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

מה היה לתוצאה

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

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

מה עושים אם הלוגים כבר נשלחים לשירות חיצוני?

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

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

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

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

אחסון, גישה ועומס: ספקות טכניים של צוותים

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

אנחנו מכניסים את זה לתוכנית האיסוף כבר מההתחלה: חוצץ על הדיסק, שליחה במקבצים, מיסוך בצד הלקוח, מדיניות שמירה עם תקופה קבועה. הפורמט תואם ל-OpenTelemetry — אפשר להקים קולט (collector) בצד שלכם.

איך ממוסכים נתונים אישיים?

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

מה יקרה אם האוסף אינו זמין?

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

איך לחשב את נפח האחסון ומתי לנקות את הלוגים?

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

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

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

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

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