לא שריד חדש לבדו: מבט על Datadog ו-Atatus

בסביבת מהנדסי SRE/DevOps, לא יפתיע אף אחד שיום אחד יופיע לקוח (או מערכת ניטור) וידווח ש"הכל אבוד": האתר לא עובד, התשלומים לא עוברים, החיים מתכלים. ... לא משנה כמה תרצו לעזור במצב כזה, זה יכול להיות מאוד קשה לעשות זאת ללא כלי פשוט ומובן. לעתים קרובות הבעיה מוסתרת בקוד היישום עצמו; אתה רק צריך להתאים אותו.

ובצער ובשמחה...

כך קרה שהתאהבנו זמן רב ועמוק ב-New Relic. זה היה ונשאר כלי מצוין לניטור ביצועי יישומים, וגם מאפשר לך להכשיר את ארכיטקטורת המיקרו-שירות (באמצעות הסוכן שלה) ועוד הרבה הרבה יותר. והכל היה יכול להיות נהדר אלמלא שינויים במדיניות המחירים של השירות: זה עלות מ 2013 שנה גדל פי 3+. בנוסף, מאז שנה שעברה קבלת חשבון ניסיון מצריכה תקשורת עם מנהל אישי, מה שמקשה על הצגת המוצר בפני לקוח פוטנציאלי.

המצב הרגיל: אין צורך בשריד חדש על "בסיס קבוע"; הם זוכרים אותו רק ברגע שמתחילות בעיות. אבל אתה עדיין צריך לשלם באופן קבוע (140 דולר לשרת לחודש), ובתשתית ענן בקנה מידה אוטומטי, הסכומים מסתכמים למדי. למרות שקיימת אפשרות Pay-As-You-Go, הפעלת New Relic תחייב אותך להפעיל מחדש את האפליקציה, מה שעלול להוביל לאובדן המצב הבעייתי שבגללו הכל התחיל. לפני זמן לא רב, New Relic הציגה תוכנית תעריפים חדשה - 要点,- שבמבט ראשון נראה כמו אלטרנטיבה סבירה למקצוען... אבל בבדיקה מעמיקה התברר שחסרות כמה פונקציות חשובות (בפרט, אין לה עסקאות מפתח, מעקב אחר יישומים, מעקב מבוזר).

כתוצאה מכך, התחלנו לחשוב על חיפוש אלטרנטיבה זולה יותר, והבחירה שלנו נפלה על שני שירותים: Datadog ו-Atatus. למה עליהם?

לגבי מתחרים

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

• תמיכה מובנית ומפותחת עבור יישומי PHP (המחסנית של הלקוחות שלנו מגוונת מאוד, אבל זה מוביל ברור בהקשר של חיפוש חלופה ל-New Relic);
• עלות משתלמת (פחות מ-100 דולר לחודש למארח);
• מכשור אוטומטי;
• אינטגרציה עם Kubernetes;
• הדמיון לממשק New Relic הוא יתרון בולט (כי המהנדסים שלנו רגילים לזה).

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

• Tideways, AppDynamics ו-Dynatrace - תמורת עלות;
• Stackify חסומה בפדרציה הרוסית ומציגה מעט מדי נתונים.

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

הצגת מתחרים נבחרים

על ניו שריד, כנראה שכולם שמעו? שירות זה החל את פיתוחו לפני יותר מ-10 שנים, בשנת 2008. אנחנו משתמשים בו באופן פעיל מאז 2012 ולא היו לנו בעיות באינטגרציה של מספר גדול באמת של יישומים ב-PHP, Ruby ו-Python, והיה לנו גם ניסיון באינטגרציה עם C# ו-Go. למחברי השירות יש פתרונות לניטור אפליקציות, תשתיות, מעקב אחר תשתיות מיקרו-שירות, יצרו אפליקציות נוחות למכשירי משתמש ועוד ועוד.

עם זאת, הסוכן New Relic פועל על פרוטוקולים קנייניים ואינו תומך ב-OpenTracing. מכשור מתקדם דורש עריכות במיוחד עבור New Relic. לבסוף, תמיכת Kubernetes עדיין ניסיונית.

החל את פיתוחו ב-2010 דאטהדוג נראה מעניין יותר באופן ניכר מ-New Relic, בדיוק מבחינת השימוש בסביבות Kubernetes. בפרט, הוא תומך באינטגרציה עם NGINX Ingress, איסוף יומנים, פרוטוקולי statsd ו-OpenTracing, המאפשר לך לעקוב אחר בקשת משתמש מרגע חיבורה להשלמה, כמו גם למצוא יומנים לבקשה זו (שניהם בצד שרת האינטרנט ועל זה של הצרכן).

בעת השימוש ב-Datadog, נתקלנו בכך שהוא לפעמים בנה את מפת המיקרו-שירות בצורה שגויה, וכמה חסרונות טכניים. לדוגמה, הוא זיהה בטעות את סוג השירות (טעות ש-Django הוא שירות מטמון) וגרם ל-500 שגיאות ביישום PHP באמצעות ספריית Predis הפופולרית.

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

חיסרון משמעותי הוא שהוא תומך רק ב-Node.js וב-PHP. מצד שני, הוא מיושם בצורה ניכרת טוב יותר מ-Datadog. שלא כמו האחרון, Atatus אינו דורש מאפליקציות לבצע שינויים או להוסיף תוויות נוספות לקוד.

איך אנחנו עובדים עם New Relic

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

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

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

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

• בקר היישומים הטעון ביותר;
• הבקר המבוקש ביותר;
• האיטי ביותר מבין הבקרים.

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

לבסוף, האפליקציה מאחסנת דוגמאות לעקבות של בקשות ארוכות (כאלה שלוקחות יותר מ-2 שניות). הנה הפאנל לעסקה ארוכה:

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

וב שאילתות מסד נתונים - להעריך שאילתות לבסיסי נתונים שהופעלו בזמן שהיישום פעל:

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

• ארוך PDO::Construct הוביל אותנו לתפקוד המוזר של pgpoll;
• חוסר יציבות לאורך זמן Memcache::Get הציע שהמכונה הוירטואלית הוגדרה בצורה שגויה;
• זמן מוגבר באופן חשוד לעיבוד תבניות הוביל ללולאה מקוננת הבודקת את נוכחותם של 500 אווטרים באחסון האובייקטים;
• וכן הלאה ...

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

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

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

מתחרים: הזדמנויות ורשמים

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

1. דאטהדוג

Datadog מקבל את פנינו עם פאנל עם קיר של שירותים:

הוא מנסה לפרק יישומים לרכיבים/מיקרו-שירותים, אז ביישום Django לדוגמה נראה 2 חיבורים ל- PostgreSQL (defaultdb и postgres), כמו גם סלרי, רדיס. עבודה עם Datadog דורשת ממך ידע מינימלי בעקרונות MVC: אתה צריך להבין מאיפה מגיעות בדרך כלל בקשות משתמשים. זה בדרך כלל עוזר מפת שירותים:

אגב, יש משהו דומה ב-New Relic:

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

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

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

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

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

מתחת לגרפים יש עסקאות דומות לחלוטין ל-New Relic:

ב-Datadog, טרנזקציות נקראות אֶמְצָעִי. ניתן למיין את הבקרים לפי מספר הבקשות, לפי זמן תגובה ממוצע ולפי הזמן המקסימלי שהושקע במשך פרק זמן נבחר.

אתה יכול להרחיב את המשאב ולראות את כל מה שכבר צפינו ב-New Relic:

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

ניתן לפתוח וללמוד כל משאב לדוגמה ב-Datadog:

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

והדבר המעניין ביותר הוא צפייה בעומס של המארח עליו בוצעה הבקשה וצפייה ביומני הבקשות.

אינטגרציה מעולה!

אתה עשוי לתהות איפה הכרטיסיות מאגרי מידע и שירותים חיצוניים, כמו בשריד חדש. אין כאן כאלה: מכיוון ש-Datadog מפרק את האפליקציה לרכיבים, PostgreSQL ייחשב שירות נפרד, ובמקום שירותים חיצוניים כדאי לחפש aws.storage (זה יהיה דומה עבור כל שירות חיצוני אחר שהאפליקציה יכולה לגשת אליו).

הנה דוגמה עם postgres:

בעצם יש את כל מה שרצינו:

אתה יכול לראות מאיזה "שירות" הגיעה הבקשה.

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

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

2.אטטוס

צוות Atatus טוען שהשירות שלהם "זהה לזה של New Relic, אבל טוב יותר." בוא נראה אם ​​זה באמת כך.

הפאנל הראשי אכן נראה דומה, אך לא ניתן היה לקבוע את ה-Redis וה-memcached המשמשים באפליקציה.

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

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

הרשימה הרגילה של הבקרים זמינה בכרטיסייה חקור:

במובנים מסוימים, הטבלה הזו מזכירה את Datadog ואני אוהב אותה יותר מהדומה ב-New Relic.

אתה יכול להרחיב כל עסקה ולראות מה האפליקציה עשתה:

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

אם אתה הולך לעסקה, אתה יכול לראות דוגמה ל-trace, אתה יכול לקבל רשימה של בקשות למסד הנתונים ולהסתכל על כותרות הבקשות. הכל דומה לשריד חדש:

באופן כללי, Atatus מרוצה מהעקבות המפורטות - ללא הדבקה טיפוסית של New Relic של שיחות לבלוק תזכורות:

עם זאת, חסר לו מסנן ש(כמו New Relic) ינתק בקשות מהירות במיוחד (<5ms). מצד שני, אהבתי את התצוגה של תגובת העסקה הסופית (הצלחה או שגיאה).

Панель מאגרי מידע יעזור לך ללמוד את הבקשות למאגרי מידע חיצוניים שהאפליקציה עושה. הרשו לי להזכיר לכם שאטאטוס מצא רק PostgreSQL ו-MySQL, למרות שגם Redis ו-memcached מעורבים בפרויקט.

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

הַבלָעָה בקשות חיצוניות זהה לחלוטין למאגרי מידע.

ממצאים

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

דאטהדוג

יתרונות:

• לוח תעריפים נוח (APM עולה 31 דולר למארח);
• עבד היטב עם Python;
• אפשרות אינטגרציה עם OpenTracing
• אינטגרציה עם Kubernetes;
• אינטגרציה עם NGINX Ingress.

חסרונות:

• ה-APM היחיד שגרם לאפליקציה להיות בלתי זמינה עקב שגיאת מודול (predis);
• מכשור אוטומטי של PHP חלש;
• הגדרה מוזרה בחלקה של שירותים ומטרתם.

אטאטוס

יתרונות:

• מכשור PHP עמוק;
• ממשק משתמש דומה ל-New Relic.

חסרונות:

• לא עובד על מערכות הפעלה ישנות יותר (Ubuntu 12.05, CentOS 5);
• מכשור אוטומטי חלש;
• תמיכה בשתי שפות בלבד (Node.js ו-PHP);
• ממשק איטי.

בהתחשב במחיר של Atatus של 69 דולר לחודש לשרת, נעדיף להשתמש ב-Datadog, שמשתלב היטב עם הצרכים שלנו (יישומי אינטרנט ב-K8s) ובעל תכונות שימושיות רבות.

נ.ב.

קרא גם בבלוג שלנו:

• «כלים למפתחי אפליקציות הפועלות על Kubernetes";
• «תוסף kubectl-debug לניפוי באגים בתרמילים של Kubernetes";
• «שירותי מיקרו: הגודל קובע, גם אם יש לך Kubernetes".

מקור: www.habr.com