التتبع والرصد في Istio: الخدمات المصغرة ومبدأ عدم اليقين

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

أما بالنسبة للخدمات المصغرة على منصة Red Hat OpenShift (وتحت إدارة Kubernetes)، فبفضل برنامج المصدر المفتوح المقابل، يمكنها الإبلاغ في وقت واحد عن أدائها وصحتها. لا يعني هذا دحض نظرية هايزنبرغ القديمة، بطبيعة الحال، لكنه يزيل بعض الشكوك عند العمل مع تطبيقات السحابة. يجعل Istio من السهل تتبع هذه التطبيقات ومراقبتها لإبقاء الأمور تحت السيطرة.

دعونا نحدد المصطلحات

تحت التتبع (التتبع) نعني به تسجيل نشاط النظام. يبدو هذا عامًا جدًا، ولكن في الواقع إحدى القواعد الرئيسية هنا هي تفريغ بيانات التتبع في وحدة التخزين المناسبة دون القلق بشأن تنسيقها. وكل عمل البحث وتحليل البيانات يقع على عاتق المستهلك. يستخدم Istio نظام تتبع Jaeger، الذي ينفذ نموذج بيانات OpenTracing.

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

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

رصد - هذا، في الواقع، هو مراقبة نظامك - بعينيك، من خلال واجهة المستخدم أو أدوات الأتمتة. تعتمد المراقبة على بيانات التتبع. في Istio، يتم تنفيذ المراقبة باستخدام Prometheus ولديه واجهة مستخدم مقابلة. يدعم Prometheus المراقبة الآلية باستخدام التنبيهات ومديري التنبيهات.

نترك الشقوق

لجعل التتبع ممكنًا، يجب على التطبيق إنشاء مجموعة من الامتدادات. ثم يجب تصديرها إلى Jaeger، والذي بدوره يقوم بإنشاء تمثيل مرئي للأثر. من بين أمور أخرى، تشير هذه الفواصل إلى اسم العملية، بالإضافة إلى الطوابع الزمنية لبدايتها ونهايتها. يتم إنجاز نقل الامتدادات عن طريق إعادة توجيه رؤوس طلبات HTTP الخاصة بـ Jaeger من الطلبات الواردة إلى الطلبات الصادرة. اعتمادًا على لغة البرمجة المستخدمة، قد يتطلب هذا إجراء تعديلات طفيفة على كود مصدر التطبيق. فيما يلي نموذج لرمز Java (باستخدام إطار عمل Spring Boot) يضيف رؤوس B3 (على غرار Zipkin) إلى طلبك في فئة تكوين Spring:

يتم استخدام إعدادات الرأس التالية:

إذا كنت تستخدم Java، فلن تحتاج إلى لمس الكود، فقط أضف بضعة أسطر إلى ملف Maven POM وقم بتعيين متغيرات البيئة. فيما يلي الأسطر التي يجب إضافتها إلى ملف POM.XML لتنفيذ Jaeger Tracer Resolver:

ويتم تعيين متغيرات البيئة المقابلة في Dockerfile:

هذا كل شيء، الآن تم إعداد كل شيء وستبدأ خدماتنا المصغرة في إنشاء بيانات التتبع.

دعونا نلقي نظرة على المخطط العام

يتضمن Istio لوحة معلومات بسيطة تعتمد على Grafana. بمجرد إعداد كل شيء وتشغيله على منصة Red Hat OpenShift PaaS (في مثالنا، تم نشر Red Hat OpenShift وKubernetes على minishift)، يتم تشغيل هذه اللوحة باستخدام الأمر التالي:

open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"

تتيح لك لوحة معلومات Grafana تقييم أداء نظامك بسرعة. يظهر جزء من هذه اللوحة في الشكل أدناه:

يمكنك هنا أن ترى أن خدمة العميل المصغرة تستدعي خدمة التفضيل v1 المصغرة، والتي بدورها تستدعي خدمة التوصية v1 وv2 المصغرة. تحتوي لوحة Grafana على كتلة صف لوحة معلومات للمقاييس عالية المستوى مثل حجم الطلب العالمي ومعدلات النجاح وأخطاء 4xx. هناك أيضًا عرض Server Mesh مع رسوم بيانية لكل خدمة وكتلة Services Row لعرض معلومات مفصلة لكل حاوية لكل خدمة.

الآن دعونا نبحث بشكل أعمق

بفضل التكوين الصحيح لتتبع Istio، يمكنك التعمق في أداء نظامك. في واجهة مستخدم Jaeger، يمكنك عرض الآثار ومعرفة مدى عمقها ومداها، وتحديد نقاط الاختناق في الأداء بصريًا. عند استخدام Red Hat OpenShift على منصة minishift، قم بتشغيل Jaeger UI باستخدام الأمر التالي:

minishift openshift service jaeger-query --in-browser

ماذا يمكن أن يقال عن التتبع على هذه الشاشة:

• وهي مقسمة إلى 7 أجزاء.
• إجمالي وقت التنفيذ هو 6.99 مللي ثانية.
• تستغرق خدمة التوصية المصغرة، وهي الأخيرة في السلسلة، 0.69 مللي ثانية.

تتيح لك المخططات من هذا النوع فهم الموقف بسرعة عندما يعاني أداء النظام بأكمله بسبب خدمة واحدة لا تعمل بشكل جيد.

الآن دعنا نعقد المهمة ونطلق مثيلين من الخدمة المصغرة التوصية: v2 باستخدام الأمر oc scale --replicas=2deployment/recommendation-v2. وهنا هي القرون التي سوف نحصل عليها بعد هذا:

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

أين وكيف تسير الأمور

الآن ننتقل إلى واجهة Prometheus وكما هو متوقع نرى هناك أن الطلبات بين الإصدارين الثاني والأول من خدمة التوصية مقسمة بنسبة 2:1، وفقًا بدقة لعدد الأوعية قيد التشغيل. علاوة على ذلك، سيتغير هذا الرسم البياني بشكل ديناميكي مع توسع نطاق الكبسولات وتقلصها، وهو ما سيكون مفيدًا بشكل خاص لنشر Canary (سننظر في مخطط النشر هذا بمزيد من التفصيل في المرة القادمة).

إنها البداية فقط

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

وتذكر أن كل هذا مدمج بالفعل في Istio. مع بعض لغات البرمجة (مثل Java) والأطر (مثل Spring Boot)، يمكن القيام بكل هذا دون لمس كود التطبيق نفسه. نعم، سيتعين تعديل الكود قليلاً إذا كنت تستخدم لغات أخرى، في المقام الأول Nodejs أو C#. ولكن بما أن إمكانية التتبع (اقرأ: "التتبع") هي أحد المتطلبات الأساسية لبناء أنظمة سحابية موثوقة، فسوف يتعين عليك تعديل الكود الخاص بك على أي حال، سواء كان لديك Istio أم لا. فلماذا لا تستغل جهودك في شيء أفضل؟

على الأقل للإجابة دائمًا على سؤال "أين؟" و"كم السرعة؟" مع 100٪ من اليقين.

هندسة الفوضى في Istio: كان من المفترض أن تكون كذلك

إن معرفة كيفية كسر الأشياء تساعدك على التأكد من عدم كسرها.

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

الآن سنعرض لك كيف يجعل Istio هذه التحديات سهلة.

كيف يبدو الأمر عندما يكون كل شيء رائعًا

فكر في السيناريو التالي: لدينا جرابان لخدمة التوصية المصغرة التي أخذناها من البرنامج التعليمي Istio. يتم تسمية أحد الجرابين بـ v1 والآخر بـ v2. كما نرى، كل شيء يعمل بشكل جيد حتى الآن:

(بالمناسبة، الرقم الموجود على اليمين هو مجرد عداد المكالمات لكل جراب)

ولكن هذا ليس ما نحتاجه، أليس كذلك؟ حسنًا، دعنا نحاول كسر كل شيء دون لمس الكود المصدر على الإطلاق.

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

فيما يلي ملف yaml لقاعدة توجيه Istio التي ستفشل (تظهر خطأ) في نصف الوقت. الخادم 503):

يرجى ملاحظة أننا نذكر صراحةً أنه في نصف الحالات يجب إرجاع الخطأ 503.

فيما يلي الشكل الذي ستبدو عليه لقطة شاشة لأمر curl الذي يتم تشغيله في حلقة بعد تمكين هذه القاعدة لمحاكاة الفشل. كما نرى، فإن نصف الطلبات تعيد الخطأ 503، بغض النظر عن الكبسولة - v1 أو v2 - التي تنتقل إليها:

لاستعادة التشغيل الطبيعي، يكفي حذف هذه القاعدة، في حالتنا باستخدام الأمر istioctl delete routerule recommend-503 -n tutorial. هنا، Tutorial هو اسم مشروع Red Hat OpenShift الذي يعمل عليه برنامجنا التعليمي Istio.

نحن نقدم تأخيرات اصطناعية

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

يرجى ملاحظة أنه بعد هذا الاختبار قد تحتاج (أو ترغب) في تحسين الكود الخاص بك. والخبر السار هنا هو أنك بهذه الطريقة ستتصرف بشكل استباقي وليس بشكل رد الفعل. هذه هي الطريقة التي يجب أن يتم بها تنظيم دورة التطوير: الترميز - الاختبار - التعليقات - الترميز - الاختبار...

هكذا تبدو القاعدة، والتي... على الرغم من أنك تعرف ماذا؟ Istio بسيط للغاية وملف yaml هذا واضح للغاية لدرجة أن كل شيء في هذا المثال يتحدث عن نفسه، فقط ألق نظرة:

في نصف الوقت سوف نواجه تأخيرًا لمدة 7 ثوانٍ. وهذا ليس كما لو قمنا بإدراج أمر السكون في الكود المصدر، حيث يقوم Istio في الواقع بتأخير الطلب لمدة 7 ثوانٍ. نظرًا لأن Istio يدعم تتبع Jaeger، فإن هذا التأخير مرئي بوضوح في واجهة مستخدم Jaeger، كما هو موضح في لقطة الشاشة أدناه. لاحظ الاستعلام الطويل في الزاوية اليمنى العليا من الرسم البياني - فهو يستمر لمدة 7.02 ثانية:

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

لا تتراجع ولا تستسلم

من الميزات المفيدة الأخرى لـ Istio في هندسة الفوضى هي القدرة على إعادة محاولة الخدمة لعدد محدد من المرات. النقطة هنا هي الاستمرار في المحاولة عندما ينتهي الطلب الأول بخطأ 503 - وربما في المرة رقم N سنكون محظوظين. ربما توقفت الخدمة لفترة من الوقت لسبب أو لآخر. نعم، هذا السبب يحتاج إلى البحث والقضاء عليه. ولكن هذا لاحقًا، أما الآن فلنحاول التأكد من استمرار عمل النظام.

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

توقف، انتظر! لقد فعلناها للتو.

سيؤدي هذا الملف إلى جعل خدمة التوصية v2 تعيد خطأ 503 في نصف الوقت:

من الواضح أن بعض الطلبات سوف تفشل:

الآن دعنا نستخدم وظيفة Retry الخاصة بـ Istio:

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

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

ونعم، لقد فعلنا ذلك مرة أخرى دون لمس الكود على الإطلاق. كل ما نحتاجه هو قاعدتان لتوجيه Istio:

كيف لا تخذل مستخدمًا أو سبعة لا تنتظر واحدًا

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

في Istio، يمكنك تعيين مهلة زمنية لتنفيذ الطلب. إذا تجاوزت الخدمة مهلة الانتظار هذه، فسيتم إرجاع الخطأ 504 (مهلة انتظار البوابة) - مرة أخرى، يتم إجراء كل هذا من خلال تكوين Istio. ولكن سيتعين علينا إضافة أمر السكون إلى كود مصدر الخدمة (ثم إعادة البناء وإعادة النشر بالطبع) لمحاكاة بطء الخدمة. لسوء الحظ، لن يعمل الأمر بأي طريقة أخرى.

لذا، قمنا بإدراج وضع نوم لمدة ثلاث ثوانٍ في كود خدمة التوصية v2، وأعدنا بناء الصورة المقابلة، وأعدنا نشر الحاوية، والآن دعنا نضيف مهلة زمنية باستخدام قاعدة توجيه Istio التالية:

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

نكرر أنفسنا مرة أخرى، ولكن يمكن ضبط مهلة الانتظار دون لمس الكود المصدر بأي شكل من الأشكال. الميزة الإضافية هنا هي أنه يمكنك الآن تعديل الكود الخاص بك للاستجابة لانتهاء المهلة، واختبار هذه التعديلات بسهولة باستخدام Istio.

والآن جميعا معا

إن إضافة القليل من الفوضى باستخدام Istio هي طريقة رائعة لاختبار الكود الخاص بك وموثوقية نظامك ككل. ستكون أنماط الاستعادة والحاجز وقاطع الدائرة، والآليات المستخدمة لإنشاء أعطال وتأخيرات اصطناعية، بالإضافة إلى إعادة المحاولة وإيقاف التشغيل، مفيدة للغاية في إنشاء أنظمة سحابية مقاومة للأخطاء. عند دمجها مع Kubernetes وRed Hat OpenShift، ستساعدك هذه الأدوات على مواجهة المستقبل بثقة.

المصدر: www.habr.com