مراقبة مجموعة Kubernetes باستخدام بروميثيوس

مرحبا زملائي.

لقد ترجمنا للتو كتابًا مثيرًا للاهتمام من تأليف Brendan Burns ، يتحدث عن أنماط التصميم للأنظمة الموزعة

بالإضافة إلى ذلك ، فإن ترجمة كتاب " Mastering Kubernetes " (الإصدار الثاني) على قدم وساق بالفعل وكتاب المؤلف عن Docker على وشك النشر في سبتمبر ، وسيكون هناك منشور منفصل حوله.

نعتقد أن المحطة التالية على هذا المسار هي كتاب عن Prometheus ، لذلك نلفت انتباهكم اليوم إلى ترجمة لمقال قصير بقلم Björn Wenzel حول التفاعل الوثيق بين Prometheus و Kubernetes. يرجى تذكر المشاركة في الاستطلاع.

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

واحدة من الأدوات المحتفظ بها لمثل هذا العمل تسمى بروميثيوس. وهو مدعوم من مؤسسة الحوسبة السحابية الأصلية ، التي تم تطويرها في الأصل من قبل بروميثيوس بواسطة SoundCloud. من الناحية النظرية ، بروميثيوس بسيط للغاية:

العمارة

يمكن لخادم Prometheus العمل ، على سبيل المثال ، في مجموعة Kubernetes وتلقي التكوين من خلال ملف خاص. يحتوي هذا التكوين ، على وجه الخصوص ، على معلومات حول مكان المحطة الطرفية التي يتم من خلالها جمع البيانات بعد الفاصل الزمني المحدد. يطلب خادم Prometheus بعد ذلك مقاييس من هذه المحطات بتنسيق خاص (عادة ما تكون متاحة على /metrics ) ويخزنها في قاعدة بيانات سلاسل زمنية. فيما يلي مثال موجز: ملف تكوين صغير يطلب مقاييس من وحدة node_exporter تم نشرها كوكيل في كل عقدة:

 scrape_configs: - job_name: "node_exporter" scrape_interval: "15s" target_groups: - targets: ['<ip>:9100'] 

أولاً ، نحدد اسم الوظيفة job_name ، وبعد ذلك يمكن استخدام هذا الاسم لطلب المقاييس في Prometheus ، ثم scrape_interval البيانات scrape_interval ومجموعة الخوادم التي تشغل node_exporter . الآن سوف يطلب Prometheus كل 15 ثانية من الخادم path /metrics إلى المقاييس الحالية. يبدو شيء مثل هذا:

 # HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 1.4852e-05 go_gc_duration_seconds{quantile="0.25"} 2.0702e-05 go_gc_duration_seconds{quantile="0.5"} 2.2059e-05 ... 

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

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

مكون اختياري آخر في هندسة بروميثيوس هو مدير alertmanager . يسمح alertmanager مكون alertmanager بتعيين حدود ، وفي حالة تجاوزها ، يمكنك إرسال إشعارات عبر البريد الإلكتروني أو الركود أو opsgenie.

بالإضافة إلى ذلك ، يحتوي خادم Prometheus على العديد من الميزات المتكاملة ، على سبيل المثال ، يمكنه طلب أمثلة ec2 على واجهة برمجة تطبيقات Amazon أو طلب منصات وعُقد وخدمات من Kubernetes. كما أن لديها العديد من المصدرين ، على سبيل المثال ، node_exporter المذكور أعلاه. يمكن لمثل هؤلاء المصدرين أن يعملوا ، على سبيل المثال ، على العقدة حيث تم تثبيت تطبيق مثل MySQL وفي فترة زمنية محددة لاستطلاع طلب المقاييس وتوفيرها على الطرفية / المقاييس ، ويمكن لخادم Prometheus جمع هذه المقاييس من هناك.

بالإضافة إلى ذلك ، ليس من الصعب كتابة المصدر الخاص بك - على سبيل المثال ، لتطبيق يوفر مقاييس مثل معلومات jvm. هناك ، على سبيل المثال ، مثل هذه المكتبة التي طورتها بروميثيوس لتصدير مثل هذه المقاييس. يمكن استخدام هذه المكتبة جنبًا إلى جنب مع Spring ، كما تتيح لك تحديد المقاييس الخاصة بك. هنا مثال من صفحة client_java :

 @Controller public class MyController { @RequestMapping("/") @PrometheusTimeMethod(name = "my_controller_path_duration_seconds", help = "Some helpful info here") public Object handleMain() { //  - } } 

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

الاستخدام في مجموعة Kubernetes

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

في هذا المثال ، بالنسبة للمبتدئين ، أستخدم مخطط الدفة الرسمي.

بنفسي ، قمت بتغيير تكوين مخطط الدفة الافتراضي قليلاً. أولاً ، كنت بحاجة إلى تنشيط rbac في تثبيت Prometheus ، وإلا لم يكن Prometheus قادرًا على جمع المعلومات من kube-apiserver . لذلك ، كتبت ملف القيم. yaml الخاص بي ، الذي يصف كيفية عرض مخطط الدفة.

لقد أجريت أبسط التغييرات:

1. alertmanager.enabled: false ، أي إلغاء نشر Alertmanager في المجموعة (لم أكن أستخدم Alertmanager ، أعتقد أنه من الأسهل تكوين التنبيهات باستخدام Grafana)
2. kubeStateMetrics.enabled: false أعتقد أن هذه المقاييس تُرجع فقط بعض المعلومات حول الحد الأقصى لعدد المداخن. عند بدء تشغيل النظام لأول مرة ، هذه المعلومات ليست مهمة بالنسبة لي
3. server.persistentVolume.enabled: false حتى يتم تكوين وحدة تخزين دائمة بشكل افتراضي
4. لقد غيرت تكوين جمع المعلومات في Prometheus ، حيث تم ذلك في طلب السحب على github . والحقيقة هي أنه في Kubernetes v1.7 ، تعمل مقاييس citations على منفذ مختلف.

بعد ذلك ، يمكنك بدء Prometheus باستخدام الدفة:

helm install stable/prometheus --name prometheus-monitoring -f prometheus-values.yaml

لذلك نقوم بتثبيت خادم Prometheus ، وعلى كل عقدة - التثبيت تحت node_exporter. يمكنك الآن الانتقال إلى واجهة المستخدم الرسومية Prometheus على الويب والاطلاع على بعض المعلومات:

kubectl port-forward <prometheus-server-pod> 9090

توضح لقطة الشاشة التالية الأغراض التي يجمعها Prometheus المعلومات (الحالة / الأهداف) ، ومتى تم تصوير المعلومات عدة مرات في الماضي:



هنا يمكنك أن ترى كيف يطلب Prometheus مقاييس من apiserver ، والعقد ، و cadvisor التي تعمل على نقاط نهاية خدمة kubernetes ونقاطها. يمكنك مشاهدة المقاييس بالتفصيل بالانتقال إلى الرسم البياني وكتابة استعلام لعرض المعلومات التي نهتم بها:



هنا ، على سبيل المثال ، نرى مساحة تخزين مجانية عند نقطة التحميل "/". في الجزء السفلي من الرسم البياني ، تتم إضافة التوقيعات التي تمت إضافتها بواسطة Prometheus أو متوفرة بالفعل في node_exporter. نستخدم هذه التوقيعات لطلب نقطة التحميل فقط "/".

مقاييس مخصصة مع التعليقات التوضيحية

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

 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-ingress-controller namespace: ingress-nginx spec: replicas: 1 selector: matchLabels: app: ingress-nginx template: metadata: labels: app: ingress-nginx annotations: prometheus.io/port: '10254' prometheus.io/scrape: 'true' ... 

نرى هنا أن قالب النشر يأتي مع شرحي بروميثيوس. يصف الأول المنفذ الذي من خلاله يطلب Prometheus مقاييس ، وينشط الثاني وظيفة جمع البيانات. الآن ، يطلب Prometheus Kubernetes Api-Server المشروحة لجمع المعلومات ويحاول جمع المعلومات من المحطة / المقاييس.

العمل الموحد

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