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

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

startup by cc0

מאת יוני לינדנפלד, מנהל פיתוח, Any.do

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

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

ELK הוא אחד הפתרונות שהולכים ותופסים תאוצה בשנים האחרונות. מדובר למעשה ב-3 כלים שונים (המרכיבים ביחד את ראשי התיבות ELK):

1. ElasticSearch – מנוע חיפוש המאפשר חיפוש מהיר על כמויות גדולות של טקסט.
2. Logstash – זהו למעשה ה"צינור" שדרכו מוזרם המידע אל ElasticSearch. הוא מאפשר לבצע מניפולציות שונות על המידע (למשל פרסור של מידע לפי פורמטים שונים, הוספה של מידע, המרה של מידע, מחיקה של מידע ועוד).
3. Kibana – כלי ויזואליזציה עשיר המאפשר לייצר מהמידע ב-ElasticSearch תצוגה ויזואלית עד לרמת ה-dashboard.

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

באוקטובר האחרון, שיחררה אמאזון את Amazon ElasticSearch Service במסגרת שירותי הענן שלה למפתחים. היות ומדובר עדיין בשירות צעיר יש בו הרבה מקום לשיפור, אולם הוא מהווה כלי נוח כדי לקבל בתוך כמה דקות setup סקלבילי של ElasticSearch ו-Kibana. השירות לא כולל את רכיב ה-Logstash אותו יש להרים בנפרד (למשל על מכונה נפרדת ב-EC2).

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

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

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

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

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

3. מעקב אחר אנומליות – ברגע שמתרגלים לעקוב אחר המידע באופן שוטף (מומלץ מאד לבנות dashboard ולמקם אותו במקום מרכזי) קל מאד להבחין באנומליות ולחקור אותן. בצורה זו הרבה פעמים אפשר לעלות על באגים או מימושים לא יעילים של התקשורת בין הלקוח לשרת.

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

Screen Shot 2016-03-10 at 15.49.30

כמה סוגים של מידע שכדאי לשמור

1. מזהה של המשתמש – אימייל, מזהה מספרי או כל דבר בו אתם משתמשים בשביל לזהות את היוזרים שלכם.

2. מה הפעולה אותה המשתמש עשה – למשל, אם יש לכם שרת שחושף restful api, פשוט לשמור את שם ה-endpoint שאליו פנה המשתמש.

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

4. מה הסטטוס קוד שחזר מהבקשה – חשוב במידה ואתם רוצים לראות כמה מהבקשות לשרת מצליחות וכמה נכשלות (ומה הסיבות השונות לכישלון).

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

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

בנוסף יש כמה נקודות חשובות לשים לב אליהן

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

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

כתב אורח

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

הגב

2 Comments on "כיצד לנטר באגים אצל מיליוני משתמשים במהירות וביעילות? [אורח]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
איתמר
Guest

כתבה איכותית! תודה

מתן ביטנר
Guest

כתבה טובה. תודה. האם יש מידע שמנסינכם אסור לשמור?

wpDiscuz

תגיות לכתבה: