كيفية مراقبة الإشارات الذهبية SRE

في الواقع الحصول على المقاييس من الخدمات المشتركة

(ملاحظة: يتوفر هنا نسخة مجانية من PDF مؤلفة من 6 أجزاء كاملة هنا)

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

يبدو أن الجميع يتفقون على أن هذه الإشارات مهمة ، لكن كيف تراقبها فعليًا؟ لا أحد يبدو يتحدث كثيرا عن هذا.

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

تجعل Microservices والحاويات و Serverless الحصول على إشارات أكثر صعوبة ، ولكن لا تزال جديرة بالاهتمام ، لأننا نحتاج إلى هذه الإشارات - لتفادي ضوضاء التنبيه التقليدية واستكشاف أنظمتنا الموزعة التي تزداد تعقيدًا بشكل فعال.

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

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

أولاً ، ما هي إشارات SRE؟

هناك ثلاث قوائم أو منهجيات مشتركة:

  • من كتاب Google SRE: زمن الانتقال وحركة المرور والأخطاء والتشبع
  • طريقة الاستخدام (من بريندان جريج): الاستخدام ، التشبع ، والأخطاء
  • الطريقة الحمراء (من توم ويلكي): معدل ، أخطاء ، والمدة

يمكنك رؤية التداخل ، وكما يلاحظ بارون شوارتز في كتابه للرصد والملاحظة باستخدام USE و RED ، تختلف كل طريقة في التركيز. يقترح استخدام USE حول الموارد ذات الرؤية الداخلية ، في حين أن RED تتعلق بالطلبات ، والعمل الحقيقي ، وبالتالي وجهة نظر خارجية (من وجهة نظر مستهلك الخدمة). من الواضح أنها مرتبطة ومكملة ، حيث أن كل خدمة تستهلك موارد للقيام بالعمل.

لأغراضنا ، سنركز على مجموعة بسيطة من خمس إشارات:

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

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

كل هذه القياسات يمكن تقسيمها و / أو تجميعها بواسطة أشياء مختلفة. على سبيل المثال ، يمكن تقسيم HTTP إلى أخطاء 4xx و 5xx ، تمامًا مثلما يمكن تقسيم Latency أو Rate عن طريق عنوان URL.

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

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

الآن لدينا إشاراتنا ، ماذا نفعل بها؟

يمكنك الانتقال إلى أدلة جمع البيانات الفعلية في نهاية هذا المنشور إذا كنت ترغب في ذلك ، ولكن يجب أن نتحدث عن ما يجب فعله بهذه الإشارات بمجرد أن نمتلكها.

أحد الأسباب الرئيسية لهذه الإشارات "الذهبية" هي أنها تحاول قياس الأشياء التي تؤثر مباشرة على المستخدم النهائي والأجزاء المنتجة للعمل في النظام - إنها قياسات مباشرة للأشياء المهمة.

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

نقوم بجمع الإشارات الذهبية لعدة أسباب:

  • تنبيه - أخبرنا عندما يكون هناك خطأ ما
  • استكشاف الأخطاء وإصلاحها - ساعدنا في العثور على المشكلة وحلها
  • الضبط وتخطيط القدرات - ساعدنا في تحسين الأمور بمرور الوقت

ينصب تركيزنا هنا على التنبيه وكيفية تنبيه هذه الإشارات. ما تفعله بعد ذلك هو بينك وبين إشاراتك.

يستخدم التنبيه في العادة عتبات ثابتة ، في أنظمةنا الحبيبة (ها!) Nagios و Zabbix و DataDog وغيرها. يعمل ذلك ، ولكن من الصعب ضبطه جيدًا ويولد الكثير من ضوضاء التنبيه ، لأنك (وأي شخص تعيش معه) من المحتمل أن تكون مدركًا تمامًا.

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

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

هل أنت متوسط ​​أم نسبي؟

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

المتوسطات لها مشاكل أخرى ، أيضًا ، كما يشير Optimizely في مدونتها. ومع ذلك ، يمكن بسهولة فهم المتوسطات / المتوسطات ، ويمكن الوصول إليها ، وهي مفيدة تمامًا كإشارة ، طالما أن نافذة القياس الخاصة بك قصيرة (على سبيل المثال 1-5 دقائق).

حتى الأفضل هو البدء في التفكير في النسب المئوية. على سبيل المثال ، يمكنك التنبيه على زمن الوصول المئوي 95 ، وهو مقياس أفضل بكثير لمدى سوء الأشياء بالنسبة للمستخدمين.

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

هل أنت شذوذ ، أو غريب فقط؟

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

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

لحسن الحظ ، يمكن لأحدث حلول مراقبة SaaS / Cloud مثل DataDog و SignalFX وما إلى ذلك القيام بذلك ، كما يمكن للأنظمة المحلية الجديدة مثل Prometheus & InfluxDB.

بغض النظر عن الأدوات الشاذة الخاصة بك ، لدى Baron Schwartz كتاب جيد حول هذا الموضوع ، يجب عليك قراءته لفهم الخيارات والخوارزميات والتحديات المختلفة بشكل أفضل: اكتشاف الشذوذ للمراقبة.

هل استطيع رؤيتك؟

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

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

إصلاح لي ، إصلاح لك

كملاحظة أخيرة بشأن التنبيه ، وجدنا أن تنبيهات SRE Golden Signal أكثر صعوبة في الاستجابة لها ، لأنها في الواقع أعراض لمشكلة أساسية نادراً ما يتم كشفها مباشرة بواسطة التنبيه.

هذا يعني غالبًا أنه يجب أن يتمتع المهندسون بمعرفة أكثر بالنظام وأن يكونوا أكثر مهارة في البحث في المشكلة ، والتي يمكن أن تكمن بسهولة في أي من الخدمات أو الموارد العشرات.

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

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

هذا هو. استمتع بإشاراتك ، حيث إنها صعبة ومثيرة للاهتمام للعثور عليها ومراقبتها وتنبيهها.

الحصول على البيانات من كل خدمة

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

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

لاحظ أيضًا أنه يتعين عليك القيام بالمعالجة الخاصة بك في بعض الحالات ، مثل القيام بحسابات دلتا عندما تقوم باختبار قياسات مضادة (ستقوم معظم الأنظمة بهذا تلقائيًا نيابة عنك).

يرجى الاطلاع على هذه الروابط للحصول على مقالات متابعة حول كيفية جمع البيانات لكل خدمة:

  • موازن التحميل - AWS ALB / ELB ، HAProxy
  • خوادم الويب - أباتشي و Nginx
  • خوادم التطبيقات - PHP و FPM و Java و Ruby و Node و Go و Python
  • خوادم قواعد البيانات - MySQL & AWS RDS
  • خوادم قاعدة البيانات - AWS أورورا
  • خوادم لينكس - كموارد أساسية

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

(ملاحظة: يتوفر هنا كتاب PDF مجاني لهذه السلسلة بأكملها)

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

ستيف Mushero هو تقني عالمي مقره في شنغهاي وسان فرانسيسكو. إنه الرئيس التنفيذي لشركة Siglos.io & ChinaNetCloud ، مع التركيز على عمليات نظام الإنترنت على نظام كبير. تواصل معه على LinkedIn أو قل مرحبا على Twitter.

انضم إلى مجتمعنا Slack وقراءة موضوعات Faun الأسبوعية الخاصة بنا ⬇

إذا كانت هذه المشاركة مفيدة ، فالرجاء النقر على زر التصفيق أدناه عدة مرات لإظهار دعمك للمؤلف! ⬇