ملحوظة. ترجمة.: نلفت انتباهكم إلى التفاصيل الفنية حول أسباب التوقف الأخير في الخدمة السحابية التي يديرها منشئو Grafana. هذا مثال كلاسيكي على كيف يمكن لميزة جديدة تبدو مفيدة للغاية مصممة لتحسين جودة البنية التحتية... أن تسبب ضررًا إذا لم توفر الفروق الدقيقة العديدة في تطبيقها في واقع الإنتاج. إنه لأمر رائع أن تظهر مثل هذه المواد التي تسمح لك بالتعلم ليس فقط من أخطائك. التفاصيل موجودة في ترجمة هذا النص من نائب رئيس المنتج في Grafana Labs.
في يوم الجمعة الموافق 19 يوليو، توقفت خدمة Prometheus المستضافة في Grafana Cloud عن العمل لمدة 30 دقيقة تقريبًا. وأعتذر لجميع العملاء المتضررين من الانقطاع. مهمتنا هي توفير أدوات المراقبة التي تحتاجها، ونحن ندرك أن عدم توفرها يمكن أن يجعل حياتك أكثر صعوبة. نحن نأخذ هذا الحادث على محمل الجد. تشرح هذه المذكرة ما حدث وكيف استجبنا وما الذي نفعله لضمان عدم حدوث ذلك مرة أخرى.
قبل التاريخ
تعتمد خدمة Grafana Cloud Hosted Prometheus على — مشروع CNCF لإنشاء خدمة Prometheus قابلة للتطوير أفقيًا ومتاحة للغاية ومتعددة المستأجرين. تتكون بنية Cortex من مجموعة من الخدمات الصغيرة الفردية، تؤدي كل منها وظيفتها الخاصة: النسخ المتماثل، والتخزين، والاستعلامات، وما إلى ذلك. Cortex قيد التطوير النشط ويقوم باستمرار بإضافة ميزات جديدة وتحسين الأداء. نقوم بانتظام بنشر إصدارات Cortex الجديدة إلى المجموعات حتى يتمكن العملاء من الاستفادة من هذه الميزات - ولحسن الحظ، يمكن تحديث Cortex دون توقف.
للحصول على تحديثات سلسة، تتطلب خدمة Ingester Cortex نسخة متماثلة إضافية من Ingester أثناء عملية التحديث. (ملحوظة. ترجمة.: - المكون الأساسي للقشرة . وتتمثل مهمتها في جمع دفق مستمر من العينات، وتجميعها في أجزاء Prometheus وتخزينها في قاعدة بيانات مثل DynamoDB، أو BigTable، أو Cassandra.) يسمح ذلك للمُنتجين القدامى بإعادة توجيه البيانات الحالية إلى المُنتجين الجدد. ومن الجدير بالذكر أن Ingesters تتطلب موارد كبيرة. لكي تعمل، يجب أن يكون لديك 4 مراكز و15 جيجابايت من الذاكرة لكل حجرة، أي. 25% من قوة المعالجة والذاكرة للجهاز الأساسي في حالة مجموعات Kubernetes الخاصة بنا. بشكل عام، لدينا عادةً موارد غير مستخدمة في المجموعة أكثر بكثير من 4 نوى و15 جيجابايت من الذاكرة، لذلك يمكننا بسهولة تدوير هذه المستوعبات الإضافية أثناء الترقيات.
ومع ذلك، غالبًا ما يحدث أنه أثناء التشغيل العادي، لا تمتلك أي من الأجهزة نسبة 25% من الموارد غير المستخدمة. نعم، نحن لا نجتهد حتى: ستكون وحدة المعالجة المركزية والذاكرة مفيدة دائمًا للعمليات الأخرى. لحل هذه المشكلة قررنا استخدام . تتمثل الفكرة في إعطاء Ingesters أولوية أعلى من الخدمات الصغيرة الأخرى (عديمة الحالة). عندما نحتاج إلى تشغيل Ingester إضافي (N+1)، نقوم مؤقتًا بإزاحة البودات الأخرى الأصغر حجمًا. يتم نقل هذه القرون إلى موارد مجانية على أجهزة أخرى، مما يترك "فجوة" كبيرة بما يكفي لتشغيل Ingester إضافي.
في يوم الخميس الموافق 18 يوليو، طرحنا أربعة مستويات جديدة للأولوية في مجموعاتنا: حرج, ارتفاع, متوسط и منخفض. تم اختبارها على مجموعة داخلية بدون حركة مرور للعملاء لمدة أسبوع تقريبًا. بشكل افتراضي، يتم استلام البودات بدون أولوية محددة متوسط الأولوية، تم تعيين فئة لIngesters مع ارتفاع الأولوية. حرج تم حجزه للمراقبة (Prometheus، وAlertmanager، وnode-exporter، وkube-state-metrics، وما إلى ذلك). التكوين لدينا مفتوح، ويمكنك عرض العلاقات العامة .
حادث
في يوم الجمعة الموافق 19 يوليو، أطلق أحد المهندسين مجموعة Cortex مخصصة جديدة لعميل كبير. لم يتضمن تكوين هذه المجموعة أولويات البودات الجديدة، لذلك تم تعيين أولوية افتراضية لجميع البودات الجديدة - متوسط.
لم يكن لدى مجموعة Kubernetes موارد كافية لمجموعة Cortex الجديدة، ولم يتم تحديث مجموعة Cortex الإنتاجية الحالية (تم ترك Ingesters بدون высокого أولوية). منذ أن تم استيعاب المجموعة الجديدة بشكل افتراضي متوسط الأولوية، وعملت البودات الموجودة في الإنتاج دون أولوية على الإطلاق، فاستبدلت أجهزة استيعاب المجموعة الجديدة أجهزة Ingesters من مجموعة إنتاج Cortex الحالية.
اكتشفت مجموعة النسخ المتماثلة الخاصة بـ Ingester التي تم إخلاؤها في مجموعة الإنتاج الكبسولة التي تم إخلاؤها وأنشأت واحدة جديدة للحفاظ على العدد المحدد من النسخ. تم تعيين الكبسولة الجديدة بشكل افتراضي متوسط الأولوية، وفقدت شركة "قديمة" أخرى في الإنتاج مواردها. وكانت النتيجة عملية الانهيار الجليديمما أدى إلى إزاحة جميع البودات من مجموعات إنتاج Ingester for Cortex.
تعتبر عمليات استيعاب البيانات ذات حالة وتخزن البيانات خلال الـ 12 ساعة الماضية. يتيح لنا ذلك ضغطها بشكل أكثر كفاءة قبل كتابتها للتخزين طويل المدى. ولتحقيق ذلك، تقوم Cortex بتقسيم البيانات عبر السلسلة باستخدام جدول التجزئة الموزع (DHT) وتكرار كل سلسلة عبر ثلاثة أجهزة استيعاب باستخدام تناسق النصاب على نمط دينامو. لا تقوم Cortex بكتابة البيانات إلى أجهزة Ingesters التي تم تعطيلها. وبالتالي، عندما يغادر عدد كبير من المُدخلين DHT، لا تتمكن Cortex من توفير النسخ المتماثل الكافي للإدخالات، وتتعطل.
الكشف والعلاج
إشعارات بروميثيوس الجديدة بناءً على "ميزانية الخطأ" (على أساس الخطأ في الميزانية - التفاصيل ستظهر في مقال قادم) بدأ دق ناقوس الخطر بعد 4 دقائق من بدء الإغلاق. على مدى الدقائق الخمس التالية أو نحو ذلك، أجرينا بعض التشخيصات وقمنا بتوسيع نطاق مجموعة Kubernetes الأساسية لاستضافة كل من مجموعات الإنتاج الجديدة والحالية.
وبعد خمس دقائق أخرى، نجحت أجهزة Ingesters القديمة في كتابة بياناتها، وبدأت البيانات الجديدة في العمل، وأصبحت مجموعات Cortex متاحة مرة أخرى.
تم قضاء 10 دقائق أخرى في تشخيص وتصحيح أخطاء نفاد الذاكرة (OOM) من الوكلاء العكسيين للمصادقة الموجود أمام Cortex. كانت أخطاء OOM ناجمة عن زيادة عشرة أضعاف في QPS (نعتقد أن ذلك يرجع إلى الطلبات المفرطة في القوة من خوادم Prometheus الخاصة بالعميل).
الآثار
كان إجمالي وقت التوقف 26 دقيقة. لم يتم فقدان أية بيانات. لقد نجح المستوعبون في تحميل كافة البيانات الموجودة في الذاكرة إلى وحدة تخزين طويلة المدى. أثناء إيقاف التشغيل، تم حذف خوادم Prometheus العميلة المخزنة مؤقتًا (بعيد) التسجيلات باستخدام استنادا إلى وول (تأليف من Grafana Labs) وكرر عمليات الكتابة الفاشلة بعد التعطل.
عمليات كتابة مجموعة الإنتاج
النتائج
ومن المهم التعلم من هذه الحادثة واتخاذ الخطوات اللازمة لتجنب تكرارها.
بعد فوات الأوان، لم يكن علينا تعيين الإعداد الافتراضي متوسط الأولوية حتى يتم استلام جميع المستوعبات في الإنتاج ارتفاع أولوية. وبالإضافة إلى ذلك، كان من الضروري الاعتناء بهم مقدما ارتفاع أولوية. تم إصلاح كل شيء الآن. نأمل أن تساعد تجربتنا المؤسسات الأخرى التي تفكر في استخدام أولويات البودات في Kubernetes.
سنضيف مستوى إضافيًا من التحكم في نشر أي كائنات إضافية تكون تكويناتها عامة على المجموعة. من الآن فصاعدا، سيتم تقييم هذه التغييرات بоالمزيد من الناس. بالإضافة إلى ذلك، تم اعتبار التعديل الذي تسبب في التعطل بسيطًا جدًا بالنسبة لمستند مشروع منفصل - تمت مناقشته فقط في مشكلة GitHub. من الآن فصاعدا، ستكون كل هذه التغييرات في التكوينات مصحوبة بوثائق المشروع المناسبة.
أخيرًا، سنقوم بأتمتة تغيير حجم الوكيل العكسي للمصادقة لمنع الحمل الزائد OOM الذي شهدناه، وسنراجع إعدادات Prometheus الافتراضية المتعلقة بالرجوع والقياس لمنع حدوث مشكلات مماثلة في المستقبل.
كان للفشل أيضًا بعض العواقب الإيجابية: بعد تلقي الموارد اللازمة، تعافت Cortex تلقائيًا دون تدخل إضافي. لقد اكتسبنا أيضًا خبرة قيمة في العمل مع - نظام تجميع السجلات الجديد الخاص بنا - والذي ساعد في ضمان تصرف جميع المُدخلين بشكل صحيح أثناء الفشل وبعده.
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com