🥇 ليست بقايا جديدة وحدها: نظرة على Datadog وAtatus

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

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

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

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

ونتيجة لذلك، بدأنا بالتفكير في البحث عن بديل أرخص، ووقع اختيارنا على خدمتين: 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 Datadog يبدو أكثر إثارة للاهتمام بشكل ملحوظ من 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، يتم تحديد معاملات الويب على الفور لتطبيق ويب، ويتم الإشارة إلى جميع المكونات في الرسم البياني للأداء، وهناك لوحات لمعدل الخطأ ومعدل الطلب... والأهم من ذلك هو أنه يمكنك التنقل بين هذه اللوحات مباشرة من مختلف أجزاء من التطبيق (على سبيل المثال، الضغط على MySQL سوف يؤدي إلى قسم قاعدة البيانات).

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

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

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

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

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

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

وفي استعلامات قاعدة البيانات - تقييم الاستعلامات إلى قواعد البيانات التي تم تنفيذها أثناء تشغيل التطبيق:

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

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

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

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

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

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

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

1. داتادوج

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

إنه يحاول تقسيم التطبيقات إلى مكونات/خدمات صغيرة، لذا في مثال تطبيق Django، سنرى اتصالين بـ 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 وأمثلة على الاستعلامات البطيئة آثار الجلسة:

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

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

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

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

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

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

النتائج

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

Datadog

الايجابيات:

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

سلبيات:

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

أتاتوس