مراقبة Kubernetes باستخدام بروميثيوس [مع حالات الاستخدام والمراقبة]

أين ولماذا يستخدم بروميثيوس؟

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

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

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

بعض حالات الاستخدام لاستخدام مراقبة بروميثيوس

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

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

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

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

قراءة: أسئلة مقابلة Kubernetes

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

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

تعلم: Openshift مقابل Kubernetes: الفرق بين Openshift و Kubernetes

مصدر

اكتشافات خدمة Kubernetes تتعرض لبروميثيوس

المكون الرئيسي: خادم بروميثيوس

عمارة بروميثيوس

مصدر

هندسة بروميثيوس كوبيرنيتيس

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

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

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

يمكنك رفع مستوى معرفتك في مثل هذه الموضوعات عن طريق إجراء دورات الحوسبة السحابية على منصات مثل upGrad و Udemy و Coursera وما إلى ذلك حيث يمكن نشر أداة المراقبة هذه على السحابة. خاصة مع upGrad ، تم تصميم الدورات من قبل إحدى المؤسسات ذات السمعة الطيبة في بلدنا IIIT-B. سيعطيك هذا خبرة عملية وجانبًا معرفيًا أوسع.

تحقق من: Kubernetes Vs. عامل ميناء: الاختلافات الأساسية التي يجب أن تعرفها

خاتمة

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

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

إذا كنت ترغب في تعلم وإتقان Kubernetes و DevOps والمزيد ، فراجع IIIT-B & upGrad's دبلوم PG في برنامج تطوير برامج المكدس الكامل.