🌙 💄 🤐 ليست واحدة من بقايا جديدة: نظرة على Datadog و Atatus 🛰️ 🥠 🦗

في بيئة SRE- / DevOps- المهندسين ، لن تتفاجأ من ظهور عميل (أو نظام مراقبة) في أحد الأيام ويقول: "كل شيء ضائع": الموقع لا يعمل ، المدفوعات لا تمر ، الحياة قابلة للتلف ... بغض النظر عن الطريقة التي أرغب في المساعدة في هذا الموقف قد يكون من الصعب للغاية القيام بذلك بدون أداة بسيطة ومفهومة. غالبًا ما يتم إخفاء المشكلة في رمز التطبيق نفسه - تحتاج فقط إلى توطينها.

وفي الحزن والفرح ...

لقد حدث ذلك منذ فترة طويلة كنا مغرمين جدا من بقايا جديدة. لقد كانت ولا تزال أداة ممتازة لمراقبة أداء التطبيقات ، كما تتيح لك استخدام بنية الخدمة الميكروية (باستخدام وكيلك) وأكثر من ذلك بكثير. وقد يكون كل شيء رائعًا ، إن لم يكن للتغيرات التي تطرأ على سياسة التسعير الخاصة بالخدمة: لقد زادت تكلفتها ثلاث مرات أو أكثر منذ عام 2013 . بالإضافة إلى ذلك ، منذ العام الماضي ، يتطلب الحصول على حساب تجريبي التواصل مع مدير شخصي ، مما يجعل من الصعب تقديم المنتج إلى عميل محتمل.

الوضع المعتاد: ليست هناك حاجة إلى Relic New "على أساس مستمر" ، ولا يتم تذكره إلا في الوقت الذي بدأت فيه المشكلات. ولكن لا يزال يتعين عليك الدفع بانتظام (140 دولارًا أمريكيًا لكل خادم شهريًا) ، وفي البنية التحتية السحابية القابلة للتطوير تلقائيًا ، تكون المبالغ كبيرة إلى حد ما. على الرغم من وجود إمكانية "الدفع أثناء الاستخدام" ، ولكن لتمكين ميزة New Relic ، فستحتاج إلى إعادة تشغيل التطبيق ، مما قد يؤدي إلى فقدان موقف المشكلة الذي بدأ كل شيء من أجله. منذ وقت ليس ببعيد ، قدمت New Relic خطة تعريفة جديدة - Essentials ، والتي تبدو للوهلة الأولى بديلاً معقولًا عن Professional ... ولكن بعد الفحص الدقيق ، تبين أن بعض الوظائف المهمة مفقودة (على وجه الخصوص ، ليس لديها معاملات أساسية ، تتبُّع التطبيقات المتقاطعة ، التتبع الموزع ) .

نتيجة لذلك ، فكرنا في إيجاد بديل أرخص ، ووقع خيارنا على خدمتين Datadog و Atatus. لماذا بالضبط عليهم؟

عن المنافسين

يجب أن أقول على الفور أن هناك حلول أخرى في السوق. لقد درسنا حتى خيارات Open Source ، لكن ليس لكل عميل القدرة المجانية على استضافة حلول ذاتية الاستضافة ... - بالإضافة إلى ذلك ، سوف يحتاجون إلى صيانة إضافية. تبين أن الزوجين اللذين اخترناهما قريبان من احتياجاتنا :

دعم مدمج ومطور لتطبيقات PHP (مجموعة عملاءنا متنوعة للغاية ، لكنها رائدة بشكل واضح في سياق إيجاد بديل للآثار الجديدة) ؛
التكلفة المعقولة (أقل من 100 دولار شهريًا لكل مضيف) ؛
الأجهزة الآلية.
التكامل Kubernetes
تشابه واجهة New Relic هو علامة ملحوظة (لأن مهندسينا معتادون عليها).

لذلك ، في مرحلة الاختيار الأولي ، قمنا بإلغاء العديد من الحلول الشائعة الأخرى ، وعلى وجه الخصوص:

Tideways ، AppDynamics و Dynatrace - للحصول على السعر ؛
Stackify - محظور في الاتحاد الروسي ويظهر القليل جدًا من البيانات.

تم تصميم المقالة التالية بطريقة تعرض الحلول قيد النظر لفترة وجيزة ، وبعد ذلك سأتحدث عن تفاعلنا النموذجي مع New Relic وتجربة / انطباعات أداء عمليات مماثلة في خدمات أخرى.

عرض المنافسين المختارين

ربما سمع الجميع عن بقايا جديدة ؟ بدأت هذه الخدمة في تطويرها منذ أكثر من 10 سنوات ، في عام 2008. لقد استخدمناها بنشاط منذ عام 2012 ولم نواجه مشكلات تكامل مع عدد كبير من التطبيقات في PHP و Ruby و Python ، كما كانت لدينا تجربة في الدمج مع C # و Go. يمتلك مؤلفو الخدمة حلولًا لمراقبة التطبيق والبنية التحتية وتتبع البنية التحتية للخدمات الدقيقة والتطبيقات الملائمة لأجهزة المستخدمين التي تم إنشاؤها والمزيد.

ومع ذلك ، فإن وكيل New Relic يعمل على بروتوكولات الملكية ، وليس لديه دعم OpenTracing. تتطلب الأجهزة المتقدمة تعديلات خاصة بـ New Relic. أخيرًا ، دعم Kubernetes له حالة تجريبية حتى الآن.

تبدو Datadog ، التي بدأت تطويرها في عام 2010 ، أكثر إثارة للاهتمام بشكل ملحوظ من New Relic من حيث استخدامها في بيئات Kubernetes. على وجه الخصوص ، يدعم التكامل مع بروتوكولات NGINX Ingress وجمع السجلات و statsd و OpenTracing ، مما يسمح لك بتتبع طلب المستخدم من لحظة اتصاله بنهاية العمل ، وكذلك البحث عن سجلات لهذا الطلب (سواء على جانب خادم الويب أو على جانبه consumer'ov).

عند استخدام Datadog ، واجهنا حقيقة أنه في بعض الأحيان قد صمم بشكل غير صحيح خريطة خدمة دقيقة وبعض العيوب الفنية. على سبيل المثال ، قام بتحديد نوع الخدمة بشكل غير صحيح (أخذ جانغو لخدمة تخزين مؤقت) وتسبب في حدوث الأخطاء رقم 500 في تطبيق PHP باستخدام مكتبة Predis الشائعة.

Atatus هو أصغر أداة ؛ أطلقت الخدمة في عام 2014. من الواضح أن ميزانية التسويق أقل شأناً من المنافسين المدرجين في القائمة ، ويذكر أنها أقل شيوعًا. ومع ذلك ، فإن الأداة نفسها تشبه إلى حد بعيد New Relic ، وليس فقط في الميزات (APM ، مراقبة المتصفح ، وما إلى ذلك) ، ولكن أيضًا في المظهر.

عيب كبير هو دعم فقط ل Node.js و PHP. من ناحية أخرى ، يتم تنفيذه أفضل بكثير من Datadog. على عكس الأخير ، لا يتطلب Atatus من التطبيقات تعديل أو تعيين علامات إضافية في التعليمات البرمجية.

كيف نعمل مع بقايا جديدة

الآن دعونا نتعرف على الطريقة التي نستخدم بها بقايا جديدة. لنفترض أن لدينا مشكلة تحتاج إلى حل:

من السهل ملاحظة زيادة في الرسم البياني - نحللها. في New Relic ، يتم تحديد المعاملات على شبكة الإنترنت فورًا لتطبيق الويب ، وتتم الإشارة إلى جميع المكونات في الرسم البياني للأداء ، وهناك لوحات معدل الخطأ ، وطلب معدل ... والأهم من ذلك ، يمكنك الانتقال مباشرة بين هذه اللوحات من أجزاء مختلفة من التطبيق (على سبيل المثال ، يؤدي النقر فوق MySQL إلى إلى قسم قاعدة البيانات).

نظرًا لأننا في هذا المثال ، نرى طفرة في نشاط PHP ، انقر على هذا المخطط وانتقل تلقائيًا إلى المعاملات :

يتم فرز قائمة المعاملات ، والتي هي أساسًا وحدات تحكم من طراز MVC ، بالفعل وفقًا لمعظم الوقت الذي يستغرق وقتًا طويلًا ، وهو مريح للغاية: نرى على الفور ما يفعله التطبيق. فيما يلي أمثلة على الاستعلامات الطويلة التي يتم جمعها تلقائيًا بواسطة New Relic. من السهل العثور على التبديل بين الفرز:

وحدة تحكم التطبيق الأكثر تحميلا.
وحدة التحكم الأكثر طلبا
أبطأ من وحدات التحكم.

بالإضافة إلى ذلك ، يمكنك توسيع كل معاملة ومعرفة ما كان يقوم به التطبيق في وقت تنفيذ التعليمات البرمجية:

أخيرًا ، يتم حفظ أمثلة تتبعات الاستعلام الطويلة (والتي تعمل لأكثر من ثانيتين) في التطبيق. هنا هي لوحة لمعاملة طويلة:

يمكن ملاحظة أن طريقتين تستغرقان الكثير من الوقت ، ومعه الوقت الذي تم فيه تنفيذ الطلب ، يتم عرض URI ونطاقه أيضًا. في كثير من الأحيان هذا يساعد على العثور على الاستعلام في السجلات. بالانتقال إلى تفاصيل التتبع ، يمكنك معرفة أين يتم استدعاء هذه الطرق من:

وفي استعلامات قاعدة البيانات - تقييم استعلامات قاعدة البيانات التي تم تنفيذها في وقت التطبيق:

مسلحين بهذه المعرفة ، يمكننا تقييم سبب تباطؤ التطبيق ، ومع المطور ، وضع إستراتيجية لحل المشكلة. في الواقع ، لا تقدم New Relic دائمًا صورة واضحة ، ولكنها تساعد في اختيار متجه التحقيق:

PDO::Construct الطويلة أدت بنا إلى الأداء الغريب لـ pgpoll ؛
عدم الاستقرار في الوقت Memcache::Get التكوين غير الصحيح المقترح للجهاز الظاهري ؛
أدى الوقت المتزايد بشكل مثير للريبة لمعالجة القالب إلى حلقة متداخلة مع التحقق من وجود 500 تجسيدات في تخزين العنصر ؛
وهلم جرا ...

يحدث أيضًا أنه بدلاً من تنفيذ التعليمات البرمجية على الشاشة الرئيسية ، ينمو شيء متعلق بتخزين البيانات الخارجي - ولا يهم ما سيكون عليه: Redis أو PostgreSQL - جميعها مخفية في علامة تبويب قواعد البيانات .

يمكنك تحديد قاعدة محددة للبحث وفرز الاستعلامات - على غرار الطريقة التي يتم بها ذلك في المعاملات. وبالانتقال إلى علامة التبويب "الطلب" ، يمكنك معرفة مقدار العثور على هذا الطلب في كل من وحدات التحكم في التطبيق ، وكذلك تقييم عدد مرات استدعاء هذا الطلب. هذا مريح جدا:

تحتوي علامة تبويب الخدمات الخارجية على بيانات متشابهة تخفي طلبات خدمات HTTP الخارجية ، مثل الوصول إلى ملف تخزين العناصر أو إرسال الأحداث إلى الحراسة أو ما شابه ذلك. من خلال محتواها ، تشبه علامة التبويب قواعد البيانات تمامًا:

المنافسون: الفرص والانطباعات

الآن الشيء الأكثر إثارة للاهتمام هو مقارنة قدرات New Relic مع ما يقدمه المنافسون. لسوء الحظ ، لم نتمكن من اختبار الأدوات الثلاثة على نفس الإصدار من تطبيق واحد قيد التشغيل. ومع ذلك ، حاولنا مقارنة الحالات / التكوينات الأكثر متطابقة.

1. Datadog

يرحب بنا Datadog بلوحة مع جدار من الخدمات:

إنه يحاول تقسيم التطبيقات إلى مكونات / خدمات microservices ، لذلك في تطبيق Django المثال ، نرى defaultdb بـ PostgreSQL ( defaultdb و postgres ) ، بالإضافة إلى Celery و defaultdb . يتطلب العمل مع Datadog أن يكون لديك الحد الأدنى من المعرفة بمبادئ MVC: عليك أن تفهم من أين تأتي طلبات المستخدمين. عادةً ما تساعد خريطة الخدمة في هذا:

بالمناسبة ، هناك شيء مماثل في New Relic:

... وخريطتهم ، في رأيي ، أصبحت أبسط وأكثر قابلية للفهم: فهي لا تعرض مكونات تطبيق واحد (مما يجعله مفصلاً بشكل غير ضروري ، كما هو الحال في Datadog) ، ولكن فقط خدمات أو خدمات ميكروية محددة.

رجوع إلى Datadog: يتضح من خريطة الخدمة أن طلبات المستخدمين تأتي إلى Django. دعنا نذهب إلى خدمة Django وأخيرا نرى ما توقعناه:

لسوء الحظ ، لا يوجد افتراضيًا أي مخطط زمني لصفقات الويب يشبه ما نراه على اللوحة New New Relic. ومع ذلك ، يمكن تكوينه بدلاً من الرسم البياني ٪ Time Time . يكفي تحويله إلى متوسط الوقت لكل طلب حسب النوع ... والآن يظهر المخطط المألوف لنا!

لماذا اختار Datadog لجدول زمني مختلف هو لغز بالنسبة لنا. كان من المحبط أيضًا أن النظام لا يتذكر اختيار المستخدم (على عكس المنافسين) ، وبالتالي فإن حفظ اللوحات المخصصة فقط هو الذي يحفظ.

لكنني سررت بالفرصة المتاحة في Datadog للتبديل من هذه الرسوم البيانية إلى مقاييس الخوادم ذات الصلة ، وقراءة السجلات وتقييم حمل معالجات خادم الويب (Gunicorn). كل شيء هو نفسه تقريبا كما هو الحال في بقايا جديدة ... وحتى عدد قليل (سجلات)!

أدناه المخططات هي المعاملات التي تشبه تماما بقايا جديدة:

في Datadog ، تسمى المعاملات الموارد . يمكنك فرز وحدات التحكم حسب عدد الطلبات ، حسب متوسط وقت الاستجابة ، حسب الحد الأقصى للوقت المنقضي لفترة زمنية محددة.

يمكنك توسيع المورد ورؤية كل ما لاحظناه بالفعل في New Relic:

هناك إحصاءات حول المورد ، وقائمة معممة للمكالمات الداخلية ، وأمثلة على الطلبات التي يمكن فرزها بواسطة رمز الاستجابة ... بالمناسبة ، أحب مهندسونا هذا التصنيف حقًا.

يمكن توسيع نطاق أي مصدر مثال في Datadog واستكشافه:

يتم تقديم معلمات الاستعلام ، ومخطط تلخيصي للوقت المنقضي لكل مكون ، ومخطط شلال ، حيث يكون تسلسل المكالمات مرئيًا. أيضًا ، يتوفر أيضًا التبديل إلى طريقة العرض الشجري لمخطط الشلال:

والشيء الأكثر إثارة للاهتمام هو عرض حمل المضيف الذي تم تنفيذ الطلب عليه ، وعرض سجلات الطلب.

تكامل رائع!

قد تتساءل أين توجد علامات التبويب قواعد البيانات والخدمات الخارجية ، كما هو الحال في New Relic. إنهم ليسوا هنا: نظرًا لأن Datadog يوزع التطبيق على مكونات ، سيتم اعتبار PostgreSQL خدمة منفصلة ، وبدلاً من الخدمات الخارجية ، يجدر البحث عن aws.storage (ستكون هي نفسها بالنسبة لأي خدمة خارجية أخرى يمكن للتطبيق الوصول إليها).

وهنا مثال على postgres :

في الواقع ، هناك كل ما أردناه:

يمكن أن نرى من "الخدمة" جاء الطلب.

لن يكون من الضروري أن نتذكر أن Datadog يتكامل تمامًا مع NGINX Ingress ويسمح بالتتبع من طرف إلى طرف منذ اللحظة التي يصل فيها الطلب إلى الكتلة ، ويسمح لك أيضًا بقبول قياسات statsd وجمع السجلات ومقاييس المضيف.

هناك إضافة ضخمة من Datadog وهي أن سعرها يتكون من مراقبة البنية التحتية و APM و Log Management و Synthetics ، أي يمكنك اختيار خطة بمرونة.

2. اتاتوس

يدعي فريق Atatus أن خدمتهم "هي نفس خدمة New Relic ، ولكنها أفضل". دعونا نرى ما اذا كان هذا هو حقا كذلك.

يبدو شريط العنوان نفسه تمامًا ، لكن لم يكن من الممكن تحديد Redis و memcached المستخدم في التطبيق.

تحدد APM جميع المعاملات افتراضيًا ، على الرغم من أن الويب مطلوبًا في العادة فقط. كما هو الحال في Datadog ، لا توجد وسيلة للذهاب إلى الخدمة المطلوبة من اللوحة الرئيسية. علاوة على ذلك ، يتم سرد المعاملات بعد الأخطاء ، والتي لا تبدو منطقية للغاية بالنسبة لـ APM.

في معاملات Atatus ، كل شيء يشبه New Relic قدر الإمكان. ناقص - لا يمكنك رؤية ديناميكيات كل وحدة تحكم على الفور. عليك أن تبحث عنها في جدول التحكم ، مرتبة حسب معظم الوقت المستهلك :

تتوفر قائمة وحدات التحكم المعتادة في علامة التبويب استكشاف :

في بعض النواحي ، يشبه هذا الجدول Datadog وهو أشبه بالجدول الموجود في New Relic.

يمكن نشر كل معاملة ومعرفة ما قام به التطبيق:

تشبه اللوحة أيضًا على الأرجح Datadog: هناك عدد من الطلبات ، صورة شاملة للمكالمات. يوفر الجزء العلوي علامة تبويب تحتوي على أخطاء فشل HTTP وأمثلة لطلبات تتبع جلسة العمل البطيئة:

إذا دخلت في معاملة ، يمكنك رؤية مثال على تتبع ، يمكنك الحصول على قائمة من الاستعلامات إلى قاعدة البيانات ورؤية رؤوس الطلبات. كل شيء يشبه بقايا جديدة:

بشكل عام ، كان Atatus مسرورًا بتتبعات مفصلة - دون الإلتصاق الجديد Relic للمكالمات في كتلة التذكير:

ومع ذلك ، لا يوجد مرشح كافي من شأنه (كما في New Relic) قطع طلبات فائق السرعة (<5ms). من ناحية أخرى ، كان عرض الاستجابة النهائية للمعاملة (نجاح أو خطأ) لطيفًا.

ستساعدك لوحة قواعد البيانات في فحص الطلبات إلى قواعد البيانات الخارجية التي يقدمها التطبيق. دعني أذكرك بأن Atatus عثر على PostgreSQL و MySQL فقط ، على الرغم من مشاركة Redis و memcached أيضًا في المشروع.

يتم فرز الطلبات وفقًا للمعايير المعتادة: تكرار الاستجابة ، متوسط وقت الاستجابة ، وما إلى ذلك. أود أيضًا أن أشير إلى علامة التبويب التي تحتوي على أبطأ الاستفسارات - هذا مناسب جدًا. علاوة على ذلك ، تزامنت البيانات الموجودة في علامة التبويب هذه في PostgreSQL مع البيانات من ملحق pg_stat_statements - وهي نتيجة ممتازة!

علامة التبويب " الطلبات الخارجية" مطابقة لقواعد البيانات.

النتائج

أداء كل من الأدوات المقدمة بشكل جيد في دور APM. يمكن لأي منهم تقديم الحد الأدنى الضروري. لخص بإيجاز انطباعاتنا على النحو التالي:

Datadog

الايجابيات:

جدول تعريفة مناسب (تكاليف APM 31 دولار لكل مضيف) ؛
أداء جيد مع بيثون.
القدرة على الاندماج مع OpenTracing
التكامل Kubernetes
التكامل مع NGINX دخول.

سلبيات:

APM الوحيد الذي تسبب في عدم إمكانية الوصول إلى التطبيق بسبب خطأ في الوحدة النمطية (predis)
أدوات PHP الضعيفة ؛
تعريف غريب جزئيًا للخدمات والغرض منها.

Atatus