ضع في اعتبارك مفهوم مراقبة Kubernetes ، وتعرف على أداة Prometheus ، وتحدث عن التنبيه.
موضوع المراقبة ضخم ولا يمكن تفكيكه في مقال واحد. الغرض من هذا النص هو تقديم لمحة عامة عن الأدوات والمفاهيم والأساليب.
مادة المقال عبارة عن ضغط من . إذا كنت ترغب في الحصول على دورة تدريبية كاملة - قم بالتسجيل في دورة تدريبية .
ما يتم رصده في مجموعة Kubernetes
الخوادم المادية. إذا تم نشر مجموعة Kubernetes على خوادمها ، فأنت بحاجة إلى مراقبة صحتها. يتولى Zabbix هذه المهمة ؛ إذا كنت تعمل معه ، فأنت لست بحاجة إلى الرفض ، فلن تكون هناك صراعات. إن Zabbix هو الذي يراقب حالة خوادمنا.
دعنا ننتقل إلى المراقبة على مستوى الكتلة.
مكونات طائرة التحكم: API ، المجدول وغيرها. كحد أدنى ، تحتاج إلى التأكد من أن واجهة برمجة التطبيقات للخوادم أو غيرها أكبر من 0. يمكن لـ Etcd إرجاع الكثير من المقاييس: من خلال الأقراص التي تدور عليها ، من خلال صحة مجموعة إلخ.
عامل في حوض السفن ظهرت منذ وقت طويل والجميع على دراية بمشاكلها: فالكثير من الحاويات تتسبب في تجمد ومشاكل أخرى. لذلك ، يجب أيضًا التحكم في Docker نفسه ، كنظام ، على الأقل من أجل التوفر.
نظام أسماء النطاقات. إذا سقط DNS في المجموعة ، فستتوقف خدمة الاكتشاف بأكملها بعد ذلك ، وستتوقف المكالمات من البودات إلى البودات عن العمل. في ممارستي ، لم تكن هناك مثل هذه المشاكل ، لكن هذا لا يعني أن حالة DNS لا تحتاج إلى المراقبة. يمكن تتبع وقت استجابة الطلب وبعض المقاييس الأخرى على CoreDNS.
دخول. من الضروري التحكم في توفر المدخلات (بما في ذلك مراقب الدخول) كنقاط دخول إلى المشروع.
تم تفكيك المكونات الرئيسية للكتلة - والآن دعنا ننتقل إلى مستوى التجريدات.
يبدو أن التطبيقات تعمل في مجموعات صغيرة ، مما يعني أنها بحاجة إلى التحكم فيها ، لكنها في الواقع ليست كذلك. الكبسولات سريعة الزوال: اليوم تعمل على خادم واحد ، وغدًا على خادم آخر ؛ اليوم هناك 10 منهم ، غدًا 2. لذلك ، لا أحد يراقب القرون. ضمن بنية الخدمات المصغرة ، من الأهمية بمكان التحكم في توفر التطبيق ككل. على وجه الخصوص ، تحقق من توفر نقاط نهاية الخدمة: هل يعمل أي شيء؟ إذا كان التطبيق متاحًا ، فما الذي يحدث خلفه ، وكم عدد النسخ المتماثلة الآن - هذه أسئلة من الدرجة الثانية. ليست هناك حاجة لرصد الحالات الفردية.
في المستوى الأخير ، تحتاج إلى التحكم في تشغيل التطبيق نفسه ، واتخاذ مقاييس العمل: عدد الطلبات وسلوك المستخدم وما إلى ذلك.
محب العمل
أفضل نظام لمراقبة الكتلة هو . لا أعرف أي أداة يمكن أن تضاهي بروميثيوس من حيث الجودة وسهولة الاستخدام. إنه أمر رائع بالنسبة للبنية التحتية المرنة ، لذلك عندما يقولون "مراقبة Kubernetes" ، فإنهم يقصدون عادةً Prometheus.
هناك خياران لبدء استخدام Prometheus: باستخدام Helm ، يمكنك تثبيت Prometheus أو Prometheus Operator عادي.
- بروميثيوس منتظم. كل شيء على ما يرام معه ، لكنك تحتاج إلى تكوين ConfigMap - في الواقع ، كتابة ملفات تكوين تستند إلى نص ، كما فعلنا من قبل ، قبل بنية الخدمات المصغرة.
- يعتبر Prometheus Operator أكثر انتشارًا قليلاً ، وأكثر تعقيدًا قليلاً من حيث المنطق الداخلي ، ولكن من الأسهل التعامل معه: هناك كائنات منفصلة ، تتم إضافة التجريدات إلى المجموعة ، لذا فهي أكثر ملاءمة للتحكم والتهيئة.
لفهم المنتج ، أوصي بتثبيت برنامج Prometheus العادي أولاً. سيتعين عليك تكوين كل شيء من خلال التكوين ، لكن هذا سيكون مفيدًا: ستكتشف ما ينتمي إلى ماذا وكيف يتم تكوينه. في Prometheus Operator ، سترتفع فورًا إلى مستوى أعلى من التجريد ، على الرغم من أنه يمكنك أيضًا الخوض في الأعماق إذا كنت ترغب في ذلك.
تم دمج Prometheus جيدًا مع Kubernetes: يمكنه الوصول إلى خادم API والتفاعل معه.
تحظى بروميثيوس بشعبية كبيرة ، ولهذا السبب يدعمها عدد كبير من التطبيقات ولغات البرمجة. هناك حاجة إلى الدعم ، نظرًا لأن بروميثيوس له تنسيق المقاييس الخاص به ، ولتحويله ، فأنت بحاجة إما إلى مكتبة داخل التطبيق أو مُصدِّر جاهز. وهناك عدد غير قليل من هؤلاء المصدرين. على سبيل المثال ، هناك PostgreSQL Exporter: يأخذ البيانات من PostgreSQL ويحولها إلى تنسيق Prometheus حتى يتمكن Prometheus من العمل معها.
عمارة بروميثيوس
خادم بروميثيوس هي النهاية الخلفية ، عقل بروميثيوس. يتم تخزين المقاييس ومعالجتها هنا.
يتم تخزين المقاييس في قاعدة بيانات السلاسل الزمنية (TSDB). TSDB ليست قاعدة بيانات منفصلة ، ولكنها حزمة في لغة Go المضمنة في بروميثيوس. بشكل تقريبي ، كل شيء في ثنائي واحد.
لا تقم بتخزين البيانات في TSDB لفترة طويلة
البنية التحتية لبروميثيوس ليست مناسبة لتخزين المقاييس على المدى الطويل. فترة الاستبقاء الافتراضية هي 15 يومًا. يمكنك تجاوز هذا الحد ، ولكن ضع في اعتبارك: كلما زادت البيانات التي تخزنها في TSDB وكلما طالت مدة قيامك بذلك ، زادت الموارد التي ستستهلكها. يعتبر تخزين البيانات التاريخية في بروميثيوس ممارسة سيئة.
إذا كان لديك حركة مرور ضخمة ، فإن عدد المقاييس هو مئات الآلاف في الثانية ، فمن الأفضل تحديد مساحة التخزين الخاصة بهم حسب مساحة القرص أو حسب الفترة الزمنية. عادة ، يتم تخزين "البيانات الساخنة" في TSDB ، المقاييس في غضون ساعات قليلة. للتخزين الأطول ، يتم استخدام التخزين الخارجي في قواعد البيانات المناسبة حقًا لهذا ، على سبيل المثال ، InfluxDB و ClickHouse وما إلى ذلك. رأيت المزيد من الآراء الجيدة حول ClickHouse.
يعمل خادم Prometheus على النموذج سحب: يذهب للمقاييس لنقاط النهاية التي قدمناها له. قالوا: "اذهب إلى خادم API" ، ويذهب إلى هناك كل عدد من الثواني ويأخذ المقاييس.
بالنسبة للكائنات ذات العمر القصير (مهمة أو وظيفة cron) التي يمكن أن تظهر بين فترات الكشط ، هناك مكون Pushgateway. يتم دفع المقاييس المأخوذة من الكائنات قصيرة المدى إلى داخلها: فقد ارتفعت المهمة ، ونفذت إجراءً ما ، وأرسلت المقاييس إلى Pushgateway واكتملت. بعد فترة ، سينزل بروميثيوس بوتيرته الخاصة ويلتقط هذه المقاييس من Pushgateway.
لتكوين الإشعارات في بروميثيوس ، يوجد مكون منفصل - أليرت ماناجر. وقواعد التنبيه. على سبيل المثال ، تحتاج إلى إنشاء تنبيه إذا كانت واجهة برمجة تطبيقات الخادم تساوي 0. عندما ينطلق الحدث ، يتم تمرير التنبيه إلى مدير التنبيه لمزيد من الإرسال. يتمتع مدير التنبيه بإعدادات توجيه مرنة للغاية: يمكن إرسال مجموعة واحدة من التنبيهات إلى الدردشة البرقية للمسؤولين ، ومجموعة أخرى إلى دردشة المطورين ، ومجموعة ثالثة إلى محادثة عمال البنية التحتية. يمكن إرسال الإشعارات إلى Slack و Telegram والبريد الإلكتروني والقنوات الأخرى.
وأخيرًا ، سأخبركم عن ميزة قاتل بروميثيوس - اكتشاف. عند العمل مع بروميثيوس ، لا تحتاج إلى تحديد عناوين محددة للأشياء للمراقبة ، يكفي أن تحدد نوعها. أي أنك لست بحاجة إلى كتابة "هنا عنوان IP ، ها هو المنفذ - الشاشة" ، بدلاً من ذلك ، تحتاج إلى تحديد المبادئ التي يمكنك العثور على هذه الكائنات (الأهداف - الأهداف). بروميثيوس نفسه ، اعتمادًا على الكائنات النشطة حاليًا ، يسحب العناصر الضرورية ويضيفها إلى المراقبة.
يتناسب هذا النهج جيدًا مع بنية Kubernetes ، حيث يطفو كل شيء أيضًا: يوجد اليوم 10 خوادم ، وغدًا 3. من أجل عدم تحديد عنوان IP للخادم في كل مرة ، كتبوا مرة واحدة كيفية العثور عليه - وسيقوم Discovering بذلك .
تسمى لغة بروميثيوس برومكل. باستخدام هذه اللغة ، يمكنك الحصول على قيم مقاييس معينة ثم تحويلها ، وبناء حسابات تحليلية بناءً عليها.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)واجهة ويب بروميثيوس
بروميثيوس لديه واجهة ويب بسيطة إلى حد ما. مناسب فقط للتصحيح أو العرض التوضيحي.
في سطر Expression ، يمكنك كتابة استعلام بلغة PromQL.
تحتوي علامة التبويب "التنبيهات" على قواعد التنبيه ، ولها ثلاث حالات:
- غير نشط - إذا لم يكن التنبيه نشطًا في الوقت الحالي ، أي أن كل شيء على ما يرام معه ولم يعمل ؛
- معلق - هذا إذا نجح التنبيه ، لكن الإرسال لم يمر بعد. تم ضبط التأخير لتعويض وميض الشبكة: إذا ارتفعت الخدمة المحددة في غضون دقيقة ، فلا ينبغي أن يصدر الإنذار بعد ؛
- إطلاق النار هو الحالة الثالثة عندما يضيء التنبيه ويرسل الرسائل.
ستجد في قائمة الحالة وصولاً إلى معلومات حول ماهية بروميثيوس. هناك أيضًا انتقال إلى الأهداف (الأهداف) التي تحدثنا عنها أعلاه.
للحصول على نظرة عامة أكثر تفصيلاً عن واجهة بروميثيوس ، انظر .
التكامل مع جرافانا
في واجهة ويب Prometheus ، لن تجد رسومًا بيانية جميلة ومفهومة يمكنك من خلالها استخلاص نتيجة حول حالة الكتلة. لبنائها ، تم دمج Prometheus مع Grafana. نحصل على لوحات القيادة هذه.
إعداد تكامل Prometheus و Grafana ليس بالأمر الصعب على الإطلاق ، يمكنك العثور على التعليمات في الوثائق: حسنًا ، سأنتهي بهذا.
في المقالات التالية ، سنواصل موضوع المراقبة: سنتحدث عن جمع السجلات وتحليلها باستخدام Grafana Loki والأدوات البديلة.
المؤلف: مارسيل إبرايف ، مسؤول Kubernetes المعتمد ، مهندس ممارس في الشركة ، المتحدث ومطور الدورة التدريبية Slurm.
المصدر: www.habr.com