על Performance Monitoring ו New Relic

New Relic (בקיצור NR) הוא כלי ה Application Performance Monitoring (בקיצור APM) מהמוערכים שזמינים בשוק היום.
Relic הוא שריד קדום, והשם New Relic נבחר כמעט כבדרך אגב: היזם (Lew Cirne) השתעשע בתוכנה שמוצאת צמדי-מלים המורכבות מהאותיות של שם המשתמש, ובעת רישום החברה זה השם שנבחר, כמעט באקראיות. מאז הוא נותר.

NR הוא לא יחיד: יש את AppDynamics (שמכוון יותר ל Enterprise), או Nagios (פתרון Open Source) נפוץ למדי - ויש עוד רבים.

NR איננו זול: הוא עולה כ 100-150$ ל host לחודש. אם מנטרים כמה עשרות שרתים יכולים להגיע בקלות לכמה אלפי דולרים בחודש, אבל אנחנו (כמו עוד לקוחות רבים של פתרונות ה Premium) - החלטנו שזו השקעה משתלמת.

אנו ב Gett משתמשים ב NewRelic, ובכלי משלים בשם Graphite, שהוא יותר תשתית ל"הרכבה עצמית" של monitoring. יש גם את StackDriver. דיי נפוץ לראות ארגונים שמשתמשים ביותר מכלי אחד ל APM.

ל APM יש שני שימושים עיקריים:

ניטור בעיות ב production בזמן אמת

הרבה תקלות טכניות ניתן לזהות ע"י מדידת שיוניים בביצועי המערכת.

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

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

שיפור ביצועי המערכת

מדי פעם, מחליטים שהגיע הזמן לשפר ביצועים. אולי בגלל feature חדש שמעמיס על המערכת מעבר לצפוי, ולעתים בגלל שהמערכת כבר "לא סוחבת" כפי שסחבה פעם (או שסתם נמאס לכם לשלם עשרות אלפי דולרים בחודש על Infrastructure).

NR (וכלים דומים) יכולים לספק במהירות ובקלות ניתוחים התחלתיים טובים לצווארי הבקבוק העיקריים במערכת. לפעמים הניתוח של NR כמו שהוא - מספיק בכדי להבין את השיפור המדויק שיש לבצע  (למשל: שאילתת SQL יעילה יותר), לעתים אחרות NR מצביע על אזור הבעיה, ואז מתחילים באיטרציות של ניסויים / הוספת monitors (לעתים ב new relic, ולעתים בכלים קרובים יותר לקוד) - עד לאיתור המדויק של הבעיה ומציאת הפתרון.

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

הטריגר לפוסט, אגב, הוא כוננות "Tier 1" שעשיתי השבוע. זו כוננות ב Gett לקבל טלפון אם יש Crisis במערכת, באחת מהמדינות, לבצע ניטור ראשוני ולהעיר את הצוות שיטפל במשבר. New Relic הוא כנראה המקום הראשון שאבדוק בו, על מה המהומה. בלילות כאלו - זהו חבר קרוב.

צורת העבודה של New Relic

New Relic תומך בסביבות קוד מסוימות:

• רובי
• ג'אווה
• NET.
• פייטון
• PHP
• node.js

בכדי לחבר את השרת שלכם ל new relic יהיה עליכם להטמיע ספרייה קטנה בקוד שתאסוף נתונים מתוך האפליקציה ותשלח אותם לשרתים של NR. NR הוא פתרון SaaS.

על כל שרת שאנו מנטרים בעזרת NR, מתקינים agent. ה agent הזה יודע לאסוף נתונים מתוך מערכת ההפעלה, מתוך הקוד שלנו (שלו הוספנו את הספרייה הקטנה של NR) ועוד סדרה של שרתים - בעזרת מערכת ה Plugins של NR. ישנם Plugins לעשרות אפליקציות מעניינות שנרצה לנטר: שרתי ווב (כמו nginx), בסיסי נתונים, memcached, רדיס, AWS, ועוד

בכדי לצמצם את ההשפעה של ה agent על השרת עצמו, NR מתמקדת באיסוף נתונים בחשיבת עלות (ערך לניתוח ביצועים) / תועלת (ההשפעה על המערכת באיסוף שלהם). כמו כן ה agent מפחית את ההשפעה שלו על השרת בו הוא רץ בכך שהוא אוסף buffer של נתונים ושולח אותם כ batch פעם בדקה (זו החלטה סבירה מכיוון שהניתוח עצמו נעשה כמה דקות אחורה, ולא באמת ב realtime). שליחת Alerts מה Agent, כמובן - מתבצעת בו במקום.

השרתים של NR אוספים את כל הנתונים שה agents שולחים ומבצעים קורולציה (תיאום) ביניהם - לתמונה אחת ואחידה.

מקור: New Relic

חלק מה"קסם" שגרם ל New Relic להיות מאוד פופולארי הוא בהצגת מדדים שימושיים (ולא סתם spam של נתונים) בצורה מאוד נוחה לגישה, ומאוד אינטואטיבית. מרגע שאני מחבר את השרתים שלי ל NR - אני יכול לעבוד מייד, ויש לי סט מסודר והרמוני של כלים ותצוגות לעבוד איתו.

למשל: בצפייה ב Dashboard הראשי, ניתן ללחוץ על כפתור שמציג את הנתונים הנוכחיים, מול נתונים באותה השעה אתמול, ומול נתונים באותה השעה לפני שבוע.

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

זהו Tradeoff בין פשטות ושימושיות, על חשבון יכולת להתאמה אישית.

NR יודע לנטר גם זמן רנדור של אפליקציות ווב בדפדפן ואפילו אפליקציות Native Mobile. יש גם מוצר ל Analytics עמוקים יותר על הנתונים הסטטיסטיים, בשם "Insights". למרות הכל - בפוסט זה אתמקד רק במוצר ה APM לניתוח נתוני ביצועים מהשרת.

על מדד ה Apdex

מדד ה Apdex (קיצור של Application Performance Index), הוא מדד שמזוהה מאוד עם NR, מכיוון שזו עושה בו שימוש אינטנסיבי במוצר.
Apdex לא הומצא ע"י NR, אך בגלל השימוש הנרחב שלו במוצר, כדאי מאוד להבין מה הוא מתאר וכיצד הוא מתנהג.
עצם הרעיון של Apdex נובע מהחסרונות המובנים של מדדים כגון ממוצע או Median. מדדים שכאלו יכולים להסתיר בקלות התנהגויות חריגות ובעייתיות במערכת.

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

כאשר אנו "מסכמים" את ההתנהגות תחת מדדים כמו ממוצע או Variance - אנו מאבדים מידע חשוב.

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

מדוע "Apdex עובד"? - אני לא יודע להסבר. אך הוא נחשב מדד מוצלח.
כמובן שגם הוא לא מושלם.

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

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

מקור: New Relic

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

• כל טרנזקציה שתסתיים בזמן שהוגדר או מהר יותר - תחשב ל"משביעת רצון" מבחינת הביצועים. (בירוק בתרשים למעלה)
• כל טרנזקציה שתסתיים בטווח שהוא בין הזמן שהוגדר כ"משביע רצון", עד לפי-4 מכך - תחשב כ "נסבלת" מבחינת ביצועים (בכתום / ירוק זית - בתרשים למעלה).
• כל טרנזקציה ארוכה מכך, או טרנזקציה שנסתיימה בשגיאה (למשל: HTTP 500) - תחשב ל "מתסכלת".

מדד Apdex הוא אחוז הפעמים בהן הגענו לטרנזקציות "משביעות רצון" ועוד חצי מהפעמים (משקל פחות) בהן הגענו לטרנזקציות "נסבלות". טווחי הערכים של Apdex נעים בין 0.0 (אסון) ל 1.0 (מעולה)

הנה דוגמה:

בשרת הזה אנו מצפים לביצוע טרנזקציה תוך 125ms, ומקבלים זאת ברוב הזמן.
מדד של 0.87 הוא טוב - אך לא מעולה. ניתן לשאוף לקצת יותר.

במדידות הדפדפן (NR מסמלצת גם קריאות מדפדפן לשרת - בכדי לבדוק את זמן התגובה של דף באתר, כולל הרינדור) הגדרנו נקודת ייחוס של 12 שניות (פשוט לא הגדרנו נקודת ייחוס) - ולכן אנו נמצאים ב Apdex 1.0 עגול. מעולה! ;-).

במעבר עם העכבר על הגרף אני נחשף למידע נוסף, ויכול לראות שהתנודות ב Apdex שלנו נעו בין 0.84 ל 0.92 בשש שעות האחרונות (נקודת החיתוך) - יציבות סבירה לכל הדעות.

rpm (קיצור של requests per minutes) הוא המקבילה של tps המקובל יותר (transactions per minute) ואנו כרגע עומדים (אני רואה במעבר עם העכבר) על כ 8.43k rpm 130tps, או כ 140tps, עם מגמה קלה של עליה (יש בד"כ מחזוריות ברורה, יומית ושבועית, לשימוש בשירותים)

מדדים עיקריים ש New Relic מספק

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

הנה ה Dashboard העיקרי של NR:

1. זהו הגרף הראשי המציג "לאן הלך הזמן במערכת". הוא מציג את הממוצע של הזמן שהושקע בבסיס הנתונים, ה Application Server, או קוד האפליקציה שלנו (במקרה הזה - רובי). בגלל ש NR מכיר את ריילס, הוא מסוגל לבצע חיתוך ולהראות לנו כמה זמן הושקע ב ActiveRecords (ספריית ה ORM של Ruby on Rails).
   במבט חטוף ניתן לראות שזהו שירות שמשתמש בתכיפות בבסיס הנתונים (צהוב) - אך יש לו גם הרבה עבודת CPU (תכלת).
2. זהו הגרף שהצגתי קודם לכן, של Apdex ו Throughput.
3. זוהי רשימת הטרנזקציות היקרות ביותר (שקלול של זמן ביצוע הטרנזקציה x שכיחות הטרנזקציה). אם נרצה לבצע שיפורי ביצועים בשרת - זה המקום להתחיל בו.
4. Error rate של השרת - כמות הטרנזקציות שלא הסתיימו כשורה.
5. רשימת ה alerts שעלו מהמערכת.
6. רשימת השרתים שב cluster. ניתן לראות CPU, disk-usage, צריכת זכרון ו Apdex - לכל שרת בנפרד.

כשאנו רוצים לשפר ביצועים, הכי הגיוני יהיה להתמקד בטרנזקציות שגוזלות הכי הרבה זמן (משוקלל). ניתן לבחור טרנזקיות ע"פ מדדים שונים (הכי אטיות, גוזלות הכי הרבה זמן, בעלות Apdex הנמוך ביותר, וכו') - ואך לעשות Drill down לטרנזקציה:

1. אנו יכולים לראות את השונות בזמני התגובה של הטרנזקציות. האם יש הרבה אטיות / מהירות במיוחד - או שיש סוג של זמן קבוע שמסביבו כולן סבות? (צהוב - האחוזון ה 95% האטי, אדום - ה media, ירוק - הממוצע)
2. לאן הולך הזמן בטרנזקציה: GC, קוד, בסיס נתונים, מערכות 3rd Party וכו'.
3. כמה טרנזקציות לדוגמה (לרוב מהאזור הפחות טוב). הנה טרנזקציה שלקחה 1.3 שניות.
4. למרות שמפתה למדוד את הטרנזקציה הגרועה ביותר (#3), לרוב זהו מקרה קצה שעלול להטעות (למשל: בדיוק היה אירוע Full GC).
   אני מעדיף לבחור את השורה השלישית, שהיא קצת יותר נורמטיבית - ולחקור אותה. להזכיר: הזמנים המדוברים הם Wall time clock - וזמן בו הקוד נמצא ב block גם הוא נספר.

והנה כבר ה Trace ש NR אוספת על הטרנזקציה:

לעתים ניתן לזהות מתוך ה trace את הבעיה. בעיות נפוצות הן:

• "בעיית n+1" - בה יש קשר master-detail בבסיס הנתונים, עושים שאילתה אחת לאובייקט האב ועוד n שאילתות - אחת לכל אובייקט בן (במקום שאילתה אחת עם inner join)
• שאילתה בודדת יקרה ביותר - ניתן ללחוץ על שורה ולראות את השאילתה הקונקרטית שבוצעה.
• בעיית קוד (מתאפיינת לעתים קרובות ב GC גבוה).

בתמונה למעלה ניתן לקראות דוגמה שנראית כמו בעיית קוד - 2 פעולות "תשתית" לכאורה, שכל אחת לוקחת יותר מ 300ms. סימן השאלה מסביר ש NR לא עשתה Drill down ומנחה מה לעשות הלאה.

Drill down לתוך הקוד NR בחר במודע לא לעשות - כדי לא להשפיע לרעה על ביצועי האפליקציה. Drill Down שכזה עשוי להיות יקר בצורה מטרידה. במקום זאת, ניתן להוסיף לקוד custom monitors. למשל, הוספת הפקודה הבאה בקוד:

add_method_tracer  :my_method  'Custom/MyClass::my_method'

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

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

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

אם אנו רוצים להיעזר ב NR לבצע ניתוח מקיף יותר וממוקד, אנו יכולים להתחיל "X-Ray session" שעוקב אחר דגימה גדולה יחסית של טרנזקציות (נאמר 50 בשעה), למשך זמן מוגבל (נאמר: חצי שעה). על טרנזקציות אלו יאסף כל המידע האפשרי - והמידע ייתן לנו מידע על מגוון טרנזקציות (ולא דווקא האטיות יותר).

עוד יכולות מעניינות (בקיצור)

Developer Mode

ה Developer Mode הוא גרסה רזה של NR שניתן להפעיל On-Premises - על מכונת הפיתוח, ויכולה לשמש לצורך ניטור ראשוני של הקוד לפני שהוא מגיע ל production. למשל, Queries בעייתיים ניתן לאתר בשלב מוקדם כבר כך - ולפני שמגיעים ל production. כמובן שהתנהגות המערכת ב production ועל מחשב של מפתח היא שונה - ולא כדאי לנסות להסיק יותר מדי מתוך ה Developer Mode.

ניתן להפעיל את ה Developer Mode מתוך קובץ הקונפיגורציה, newrelic.yml, ע"י הפיכת הערך developer_mode ל true - ואז יהיה ניתן לגשת ל dashboard דרך http://localhost:3000/newrelic.
ה Dashboard של ה Developer Mode הוא הרבה פחות אטרקטיבי ועשיר - אבל הוא מכיל את נתוני הבסיס החשובים על הטרנזקציות.


דו"חות מוכנים

ל NR יש סדרה של דוחות מגניבים - חלקם אפילו שימושיים! למשל:

• חישוב ה up-time של המערכת (למשל: 99.9734%) בתקופת זמן נתונה.
• בניית גרף ה Scalability של המערכת - עלייה בזמני התגובה של השרת ככל שמספר הבקשות גדל (ואולי יש עוד nodes ב cluster בכדי לשרת). גרף זה עוזר לזהות צווארי בקבוק פוטנציאליים.
• Speed Index - השוואה של הנתונים של השרת שלנו מול אתרים אחרים בתעשייה (לא ראיתי כיצד זה יכול להיות מועיל)
• מיפוי ויזואלי של התקשורת העיקרית בין השרתים שלכם.

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

Insights

את המידע העצום ש NR אוספת על השרתים שלכם ניתן לתחקר באופן חופשי (יחסית) ובעזרת שפת NRQL (שפה דומה ל SQL) - על מנת לבצע ניתוחים ש NR לא מספקת "Out of the box"

סיכום

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

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

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


שיהיה בהצלחה!



-----

קישורים מעניינים

הפלטפורמה של NR (מתוך הבלוג הרשמי)
NR ב highscalability.com (פוסט מ 2011)

Crash Course ב NR (וידאו של חצי שעה). מוצלח יותר מרוב החומרים שמצאתי בנושא ברשת
New Relic vs. AppDynamics (פוסט מבית טאקיפי)