استخدام العناصر التابعة في Zabbix 4.0 باستخدام HPE MSA 2040/2050 كمثال

مقدمة

كل من يستخدم نظام مراقبة Zabbix ويراقب تطوره يعرف أنه مع إصدار Zabbix 3.4 لدينا ميزة رائعة - العناصر التابعة (عناصر البيانات التابعة) ، والتي كانت هناك بالفعل مشاركة مدونة مقابلة على Zabbix. ومع ذلك ، في الشكل الذي تم تقديمه به في 3.4 ، كان استخدامه "على أكمل وجه" مشكلة بسبب حقيقة أن وحدات ماكرو LLD غير مدعومة للاستخدام في قواعد المعالجة المسبقة ( ZBXNEXT-4109 ) ، بالإضافة إلى "الوالد" يمكن تحديد واحد فقط تم إنشاؤه بواسطة قاعدة LLD نفسها ( ZBXNEXT-4200 ) من عنصر البيانات. باختصار ، كان علي أن أفعل كل شيء تمامًا كما هو موضح في الرابط أعلاه - للعمل بيديك ، والذي تسبب ، مع عدد كبير من المقاييس ، في الكثير من الإزعاج. ومع ذلك ، مع إصدار Zabbix 4.0alpha9 ، تغير كل شيء.

القليل من التاريخ

بالنسبة لي ، كانت الوظيفة الموصوفة مهمة بسبب حقيقة أن شركتنا تستخدم العديد من أنظمة التخزين من HP ، وهي HP MSA 2040/2050 ، والتي تتم إزالة مقاييسها عن طريق الطلبات إلى XML API باستخدام برنامج نصي Python .



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

• طلب رمز المصادقة (مفتاح الجلسة) ؛
• الطلب نفسه ، بإرجاع معلومات عن المكون.

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

كان أول قرار اتخذته لتفريغ واجهة برمجة التطبيقات ، حتى قبل إصدار الإصدار 3.4 من Zabbix ، هو إنشاء ذاكرة تخزين مؤقت للرمز المميز المستلم ، والذي تمت كتابته إلى الملف وتخزينه لمدة N-minutes. سمح هذا بتقليل عدد المكالمات إلى واجهة برمجة التطبيقات (API) مرتين بالضبط ، ومع ذلك ، لم يتغير الوضع كثيرًا - كان من الصعب الحصول على شيء آخر غير الحالة الصحية. في هذا الوقت ، زرت Zabbix Moscow Meetup 2017 ، الذي استضافته Badoo ، حيث تعرفت على وظائف عناصر البيانات التابعة المذكورة أعلاه.

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

{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... } 

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

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

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

كيف تبدو الآن

لإظهار الميزات الجديدة لـ Zabbix ، نأخذ:

• تخزين HPE MSA 2040 متاح عبر HTTP / HTTPS ؛
• خادم Zabbix 4.0alpha9 مثبت من المستودع الرسمي على CentOS 7.5.1804 ؛
• نص برمجي مكتوب في Python من الإصدار الثالث ويزودنا بالقدرة على اكتشاف مكونات التخزين (LLD) وإرجاع البيانات بتنسيق JSON للتحليل على جانب خادم Zabbix باستخدام مسار JSON.

سيكون عنصر البيانات الأصل "فحصًا خارجيًا" يستدعي النص البرمجي بالحجج اللازمة ويخزن البيانات المستلمة كنص.

تحضير

يتم تثبيت نص Python النصي وفقًا للتوثيق ولديه مكتبة "طلبات" في تبعيات Python. إذا كان لديك توزيع قائم على RHEL ، يمكنك تثبيته باستخدام yum package manager:

 [root@zabbix]# yum install python3-requests 

أو باستخدام النقطة:

 [root@zabbix]# pip install requests 

يمكنك اختبار البرنامج النصي من shell عن طريق طلب ، على سبيل المثال ، بيانات LLD حول الأقراص:

 [root@zabbix]# ./zbx-hpmsa.py -m MSA_DNS_NAME_OR_IP -d -c disks {"data":[{"{#DISK.ID}":"1.1","{#DISK.SN}":"KFGY7LVF"},{"{#DISK.ID}":"1.2","{#DISK.SN}":"Z0K02QVG0000C4297CH3"},{"{#DISK.ID}":"1.3","{#DISK.SN}":"KLK7XG0F"}, ... } 

إعداد المضيف

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



الاسم - حدد بشكل تعسفي ؛
النوع - التحقق الخارجي ؛
المفتاح هو استدعاء البرنامج النصي بالمعلمات الضرورية (انظر وثائق البرنامج النصي على GitHub) ؛
نوع المعلومات - نص
الفاصل الزمني للتحديث - يستخدم المثال ماكرو مخصص {$ UPDATE} يتوسع إلى القيمة "1 م" ؛
فترة تخزين التاريخ هي يوم واحد. أعتقد أن تخزين عنصر البيانات الرئيسي لم يعد له معنى.
تحقق من أحدث البيانات للعنصر الذي تم إنشاؤه:



يأتي JSON ، ثم يتم كل شيء بشكل صحيح.

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



بعد إنشاء قاعدة LLD ، ستحتاج إلى وضع نماذج لعناصر البيانات. لنقم بإنشاء مثل هذا النموذج الأولي ، باستخدام بيانات درجة الحرارة كمثال:



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

أضفت أيضًا نموذجًا أوليًا لـ "التطبيق" - يمكنك بسهولة ربط المقاييس المتعلقة بمكون واحد إليه.

في علامة التبويب "المعالجة المسبقة" ، أنشئ خطوة من نوع "مسار JSON" بقاعدة تسترد قراءات درجة الحرارة:



يبدو تعبير الخطوة كما يلي: $['{#DISK.ID}']['temperature']

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

بعد ذلك ، عن طريق القياس مع درجة الحرارة ، قم بإنشاء النماذج الأولية المتبقية لعناصر البيانات:



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



نحن في انتظار تحديث ذاكرة التخزين المؤقت للتكوين أو الضغط عليها يدويًا للتحديث:

 [root@zabbix]# zabbix_server -R config_cache_reload 

بعد ذلك ، يمكنك استخدام "خدعة" أخرى رائعة من الإصدار 4.0 - زر "التحقق الآن" لتشغيل قواعد LLD التي تم إنشاؤها:



حصلت على النتيجة التالية:

الخلاصة

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

شكرا للقراءة ، الروابط إلى المواد المستخدمة ، وكذلك إلى النموذج الحالي لـ HPE MSA P2000G3 / 2040/2050 يمكن العثور عليها أدناه.

PS بالمناسبة ، في الإصدار 4.0 يتم أيضًا تقديم نوع جديد من الفحوصات - وكيل HTTP ، الذي ، إلى جانب المعالجة المسبقة ومسار XML ، يمكن أن ينقذنا من استخدام البرامج النصية الخارجية - ما عليك سوى حل مشكلة الحصول على رمز مصادقة مميز ، والذي لا يزال بحاجة إلى تحديث دوري. أحد الخيارات التي أراها هو استخدام ماكرو عالمي مع هذا الرمز المميز ، والذي يمكن تحديثه عبر واجهة برمجة تطبيقات Zabbix بواسطة التاج ، بما في ذلك. يمكن للأشخاص المهتمين تطوير هذه الفكرة. =)

البرنامج النصي
قالب حصة Zabbix
عناصر البيانات التابعة
مسار Json
Zabbix 4.0alpha9