Sentry או Datadog: אותה שגיאה יכולה לדרוש שני כלים, לא מנצח אחד

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

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

קריסת גרסה: כמה אירועים שייכים לאותה בעיית קוד?

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

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

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

עומס תשתית: האם האיטיות מתחילה מחוץ לקוד שנכשל?

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

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

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

תקלה מבוזרת: שגיאת הקצה אינה מספרת היכן הבקשה נכשלה

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

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

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

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

המחיר: מה כל כלי סופר בזמן שגרה ובזמן תקלה?

מחירון Datadog מציג APM עצמאי ב־36 דולר ל־host לחודש בחיוב שנתי, בלי חובה לרכוש לצדו Infrastructure Monitoring; שכבות APM Pro ו־APM Enterprise יקרות יותר. host לחיוב APM הוא host שמייצר traces שנשלחים לשירות. המחיר כולל הקצאות לקליטת spans ולאחסון spans באינדקס, וחריגה מהן עשויה ליצור חיוב נוסף. בלוגים יש להבחין בין נפח הקליטה לבין אירועים שנשמרים באינדקס; לכן מחיר ה־host לבדו אינו מתאר חשבון שכולל גם שימוש נרחב ב־traces ובלוגים.

ב־Sentry האומדן מתחיל מנפח אירועי השגיאה ומהנתונים הנוספים שהיישום ישלח, ולא ממספר ה־hosts. הנחיית התמחור של Sentry מפנה רוכשים במסלולי שירות עצמי לאומדן באתר, ואילו תמחור לנפחים גדולים דורש שיחה עם נציג מכירות. משום כך השוואה ישירה בין מחיר APM ל־host לבין מחיר Sentry אינה מספיקה בלי להגדיר מראש את נפח האירועים ואת סוגי הנתונים שייכללו.

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

מתי שילוב מוגבל עדיף על פלטפורמה רחבה?

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

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

קראו גם:

• 2FA ב־GitHub עלול לנעול אתכם בחוץ: שמרו יותר מנתיב שחזור אחד
• n8n באחסון עצמי: audit אחד חושף webhooks לא מוגנים