مراجعة الكود - الممارسة الهندسية من حيث منهجية التطوير المرنة. هذا تحليل (فحص) للشفرة من أجل تحديد الأخطاء ، وأوجه القصور ، والتناقضات في أسلوب كتابة التعليمات البرمجية وفهم ما إذا كان الكود يحل المهمة.
سأتحدث اليوم عن كيفية تنظيم عملية المراجعة لمراقبة التكوين في Zabbix. ستكون هذه المقالة مفيدة لأولئك الذين يعملون مع نظام المراقبة Zabbix ، سواء في فريق كبير ، أو بمفردهم ، حتى لو كان لديك "عشرة مضيفين ، فما الذي يمكن مراجعته".
ما هي المشاكل التي نحلها؟
لمراقبة خدماتنا الداخلية وبناء البنية التحتية ، نستخدم Zabbix. لدينا اصطلاحات تسمية - اصطلاح الأسماء ( نستخدم نموذجًا يحتذى به مع تسليط الضوء على الأدوار ، وقوالب الملف الشخصي للمراقبة) ، ولكن لا يوجد فريق مراقبة مخصص (يوجد كبار المهندسين الذين "أكلوا الكلب" في مسائل المراقبة) ، وهناك مهندسون ومهندسون مبتدئون ، ~ 500 مضيف ، حوالي 150 قالبًا (بنية أساسية صغيرة ، لكنها ديناميكية للغاية).
تُستخدم هذه البنية التحتية لدعم وأتمتة عمليات التطوير في الشركة ، بالإضافة إلى دعمها ، نقوم أيضًا بتطوير أدوات الأتمتة والتكامل ، وبالتالي لدينا القليل من الخبرة وفهم عمليات التطوير من الداخل.
مع ازدياد عدد الموظفين والتغييرات التي أدخلت على نظام المراقبة ، بدأت تحدث أخطاء أكثر وأكثر يصعب تتبعها:
- عنصر ملزم ، يتم تشغيله مباشرة على الأجهزة المضيفة ، خارج القوالب (وتظل بعض الأجهزة المضيفة غير خاضعة للمراقبة).
- قيمة غير صحيحة للمشغلات (نوع من المساحة المتفق عليها 3 غيغابايت ، ولكن خطأ مطبعي ، نحصل على المشغل لا يعمل أبدا من 34 جيجابايت).
- عدم الامتثال لاتفاقية الاصطلاح - وحصلنا على الاسم غير المفهوم لمشغل فشل البرنامج النصي (على الرغم من أن هذا يعني أن نظام تسليم التحديث لا يعمل) أو قالب قوالب Gitlab (مراقبة أي خادم أو وكيل؟).
- تعطيل الزناد ، مؤقت ، للاختبارات. نتيجة لذلك ، فاتنا التحذير على البنية التحتية وقفت.
في عالم المبرمجين ، يتم حل كل هذه المشكلات بكل بساطة: linter ، codereview. فلماذا لا تأخذ هذه bestpractices لمراجعة التكوين Zabbix؟ خذها!
لقد سبق أن كتبنا سابقًا عن إيجابيات وأمثلة مراجعة التعليمات البرمجية: تنفيذ عمليات فحص التعليمات البرمجية في عملية التطوير ، مثال عملي لتطبيق فحص التعليمات البرمجية ، فحص التعليمات البرمجية . ملخص
لماذا قد تحتاج إلى مراجعة تكوينات Zabbix:
- تحقق من تسمية المضيفين والقوالب على أنها مقبولة في الأمر ( اصطلاح الأسماء ).
- تدريب الموظفين الجدد والتحقق من أنهم قاموا بالمهمة كما تمت مناقشتها.
- نقل المعرفة بين الموظفين ذوي الخبرة.
- لاحظ مشغلات عن طريق الخطأ أو مؤقتا قبالة.
- لاحظ قيمًا غير صحيحة في العنصر أو المشغل - أخيرًا (0) بدلاً من دقيقة (5 أمتار) .
أضف مشاكلك في التعليقات ، وحاول معرفة كيفية حلها مع المراجعة.
مثل Zabbix مع تتبع التغيير
لدى Zabbix نظام فرعي لتدقيق الحسابات ، بمساعدته ، نلقي نظرة على من قام بالتغييرات في التكوين. العيب الكبير هو العدد الكبير للأحداث المحفوظة ، لأنه يحفظ كل حدث مستخدم.
تخيل أن أي تغيير في الكود يظل في سجل git ، وحاولت اختيار اسم المتغير لمدة ساعة ، وحاولت 40 خيارًا ، وكلها محفوظة الآن ، وكل تغيير هو التزام منفصل ، ثم قدم محفوظات هذه الالتزامات إلى المراجعة ، دون القدرة على مقارنة البداية والنهاية نسخة. فظيعة ، أليس كذلك؟
وفي Zabbix Audit ، هذا صحيح. يمكن استخدامه لتتبع التغييرات ، لكنه لا يسمح لك بمشاهدة الفرق (الفرق) بين حالتين من النظام (في بداية الأسبوع وفي النهاية) بسرعة. بالإضافة إلى ذلك ، يتم تقسيم كل تصرفاتها حسب النوع: إضافة ، تغيير ، حذف يجب أن يتم عرضها في نوافذ مختلفة. يمكن العثور على مثال في Zabbix في علامة التبويب التدوين (أو إلقاء نظرة على لقطة الشاشة). من الصعب فهم الحالة الأولية ، ما هي الحالة الحالية ، ما هي التغييرات التي حدثت خلال الأسبوع. الوضع معقد عندما يكون لدينا عشرات التغييرات في الأسبوع.
أريد آلية تسمح بما يلي:
- مرة واحدة في الأسبوع أو بعد الانتهاء من مهمة تغيير منطق المراقبة ، قم بتكوين حالة النظام.
- قارن كتلة التكوين الحالية مع الكتلة السابقة (فرق).
- تحقق تلقائيا اسم الاتفاقية.
- تحقق من جودة المهمة ، وقدم التوصيات ، والمشورة ، وناقش الحلول.
- تحقق من أن التغييرات مشروعة - كلها مصنوعة وفقًا للمهمة.
- استخدم أدوات مألوفة للمطورين - git، diff، mergerequest.
- استرجع إلى حالة النظام ، لكن لا تفقد البيانات (لذلك ، النسخ الاحتياطي غير مناسب).
- السيطرة على الكيانات Zabbix - المضيف ، والقوالب ، والعمل ، وحدات الماكرو ، الشاشة ، خريطة.
الآن دعنا نتحدث عن كيفية تطبيقنا للآلية وكيف يمكن أن تكون مفيدة لك لبنية Zabbix الأساسية الخاصة بك.
إجراء مراجعة التكوين Zabbix
لتخزين تكوين Zabbix ، نستخدم التنسيقات التالية:
- XML الأصلي - تم تصديره باستخدام تصدير Zabbix الأصلي. استخدام للمضيف ، قالب ، كائنات الشاشة. هناك ميزات:
- من الصعب قراءة التغييرات وعرضها في XML ؛
- تحتوي على جميع الحقول ، بما في ذلك الحقول الفارغة ؛
- يحتوي على تاريخ الحقل - تاريخ التصدير ، نحن نقطعها.
- Raw JSON - بعض أنواع الكائنات Zabbix غير قادرة على التصدير (الإجراءات ، أنواع الوسائط) ، لكنها مهمة وأريد أن أرى التغييرات ، لذلك نحن نأخذ البيانات الأولية من ZabbixAPI ونحفظها في JSON.
- ReadY YAML - نقوم بمعالجة XML المصدر وخام JSON الخام وحفظه في YAML مقروء من قبل الإنسان ، ومريح. مع ذلك ، من السهل التعامل مع كميات كبيرة من التغيير مع عينيك. إضافة معالجة صغيرة هناك:
- تعتبر إزالة الحقول بدون قيم نقطة نقاش ، حتى نتمكن من تخطي حقل فارغ ، على الرغم من أنه يجب ملؤه ، على سبيل المثال ، حقل مع وصف للمشكلة في المشغل (trigger.description). بعد المناقشة ، تقرر أنه من الأفضل إزالة الحقول الفارغة ، فهناك الكثير منها. إذا كنت ترغب في ذلك ، يمكنك وضع استثناء في بعض الحقول الفارغة وعدم حذفها.
- نقوم بحذف التواريخ - تتغير في كل مرة وعندما تظهر طلبات الدمج كتغييرات لكل مضيف.
- يمكنك اختياريًا إضافة عمليات أخرى لملء المعلومات - تتم كتابة معرف المستخدم في إجراء بدلاً من المستخدمين ، على سبيل المثال.
نميز بين ثلاثة مستودعات git (نستخدم gitlab للتخزين ، ولكن أي VCS سيفعل):
- zabbix-review-export - سيؤدي هذا إلى تخزين رمز التصدير (نصوص Python) والمعلمات الخاصة بوظائف gitlab-ci.
- zabbix-xml - نقوم بتخزين XML + JSON ، كل ذلك في فرع واحد. مراجعة هذه الأعمال صعبة وتستغرق وقتًا طويلاً. يستخدم لاستعادة حالة تكوين Zabbix لفترة محددة.
- zabbix-yaml هو مستودعنا الرئيسي ، وهنا نقوم بدمج الطلبات ، راجع التغييرات ، وناقش القرارات المتخذة ، ودمج برنامج الماجستير في حالة عدم وجود تعليقات.
في مستودعات التخزين هذه ، نحفظ بيانات التكوين ، والقواعد هناك كما يلي:
الآن نرى بوضوح نوع الكائن الذي تغير ، ومن الواضح أي كائن قد تغير ؛ في المثال أدناه ، تم تغيير قالب ملف التعريف. سكمديف. FlusContinuousTest .
عرض على الأمثلة
لعرض التغييرات ، نستخدم آلية طلب الدمج في gitlab.
تم تغيير قالب ملف التعريف. DevOps. اختبار - تغيير التعبير الزناد. القالب ، كما هو الحال في مجلد القوالب :
تم تغيير التعبير في المشغل والأولوية:
رابط لقالب آخر:
تم تغيير الإجراء - أضف سطرًا جديدًا إلى نهاية النص افتراضيًا:
مثال للمناقشات في طلبات الدمج (كل شيء يشبه المبرمجين!) - يمكن ملاحظة أنهم ربطوا القالب القياسي مباشرةً بالمضيف ، لكن الأمر يستحق إبراز دور منفصل للمستقبل. لقطة شاشة من المراجعة القديمة ، ثم استخدام تمثيل XML للتكوين.
بشكل عام ، كل شيء بسيط:
- تمت إضافة مضيف جديد أو كائن آخر - تم إنشاء ملف جديد.
- تغيير المضيف أو كائن آخر - بدا الفرق.
- تم الحذف - تم حذف الملف.
لنفترض أنك أكملت مهمة وتريد أن تطلب من أحد الزملاء معرفة ما إذا كنت قد نسيت أي شيء. نطلب مراجعة: لهذا ، في مستودع zabbix-review-export ، قم بتشغيل مهمة gitlab-ci مع بداية يدوية.
نقوم بتعيين طلب دمج إلى زميل يبحث في البنية التحتية لرصد الكود ومناقشتها وتصحيحها.
مرة واحدة في الأسبوع ، يتم بدء مراجعة جديدة لتتبع التغييرات الصغيرة ، ولهذا ، وفقًا للجدول ( الجدول ) ، يتم تصدير التكوين وحفظه في مستودع git (مع التزام جديد) ، ويقوم مراقب المراقبة بمراجعة التغييرات.
أنت تنتشر بلطف ، ولكن عليك أن تجرب
سنخبرك الآن بكيفية تكوين هذا النظام لمراجعة تكوين Zabbix ( نحب المصدر المفتوح ونحاول مشاركة أفضل ممارساتنا مع المجتمع).
هناك نوعان من الاستخدامات الممكنة:
- ما عليك سوى تشغيل البرنامج النصي للتصدير يدويًا - تشغيل البرنامج النصي ، راجع التغييرات ، وجعل
git add * && git commit && git push . هذا الخيار مناسب للتغييرات النادرة أو عند العمل مع نظام المراقبة وحده. - استخدم gitlab-ci للتشغيل الآلي - ثم تحتاج فقط إلى النقر على زر البدء (انظر الصورة أعلاه). الخيار هو أكثر ملاءمة للكبير
كسول فرق أو مع التغييرات المتكررة.
يتم وصف كلا الخيارين في مستودع https://gitlab.com/devopshq/zabbix-review-export ، يتم تخزين كل ما تحتاجه هناك - البرامج النصية و gitlab-ci وإعدادات README.md ، وكيفية وضع البنية الأساسية الخاصة بك.
أولاً ، جرِّب الخيار الأول (أو إذا لم يكن لديك البنية التحتية لـ gitlab-ci): استخدم الوضع اليدوي - قم بتشغيل البرنامج النصي zabbix-export.py لتصدير التكوين (النسخ الاحتياطي) ، قم git add * && git commit && git push g & g git add * && git commit && git push على جهاز العمل الخاص بك. عندما تتعب ، انتقل إلى الخيار الثاني - أتمتة التشغيل الآلي!
المشاكل والتحسينات الممكنة
الآن يتم تغيير الطابع الشخصي للتغييرات ومعرفة من قام بالتغييرات ، فأنت بحاجة إلى استخدام نظام Audit الذي يسبب الألم والمعاناة. ولكن ليس كل شيء مخيفًا جدًا ، ونادراً ما تكون هناك حاجة إلى التدقيق ، فعادة ما تكون رسالة في الدردشة الجماعية كافية للعثور على الموظف المناسب.
مشكلة أخرى: عندما يتغير مضيف أو عنصر في مضيف ، فلا يتم تضمينه في XML. وهذا يعني أنه يمكننا إيقاف تشغيل جميع المشغلات على مضيف معين أو تغيير أولوياتها إلى واحدة أقل - ولن يعرف أي شخص عنها ويصححنا! نحن في انتظار حل لهذا في https://support.zabbix.com/browse/ZBX-15175
حتى جاءوا مع آلية لاسترداد التلقائي. افترض أنه تم تغيير قالب أو مضيف بشكل كبير ، نحن نفهم أن التغييرات غير صحيحة وتحتاج إلى إرجاع كل شيء كما كان. الآن نحن نبحث عن XML الضروري للمضيف المناسب ، واستيراده يدويًا في واجهة المستخدم ، لكننا أردنا فقط النقر فوق الزر "استرجاع قالب TemplateName إلى حالة التزام الالتزام".
يمكنك تنفيذ التزامن ثنائي الاتجاه - عند إجراء تغييرات على تكوين Zabbix عند إجراء تغييرات على YAML ، فلن تحتاج إلى الانتقال إلى واجهة الويب الخاصة بنظام Zabbix. على جيثب التقوا بمشروع مشابه ، لكن بطريقة ما تلاشى بسرعة ولم يقبل المجتمع الفكرة ؛ على ما يبدو ، ليس من السهل في YAML تنفيذ ما يمكنك النقر فوقه بالماوس في واجهة الويب. لذلك ، استقرنا على التفاعل في اتجاه واحد.
الخيار المثالي هو تضمين هذا النظام لحفظ التكوين كرمز ، حتى لو كان بتنسيق XML فقط ، في Zabbix. كيف يتم ذلك في خادم TeamCity CI : التكوينات التي يتم تكوينها من خلال واجهة المستخدم تجعل من يرتكبها نيابة عن المستخدم الذي قام بتغيير التكوين. لقد تحولت إلى أداة ملائمة جدًا لعرض التغييرات ، كما تعمل أيضًا على إزالة مشكلة إزالة الطابع الشخصي عن التغييرات.
جرب
ابدأ في تصدير تهيئة Zabbix الخاصة بك ، والالتزام بمستودع (محلي بما فيه الكفاية) ، وانتظر أسبوعًا ثم قم بتشغيله مرة أخرى. الآن التغييرات في سيطرتك! https://gitlab.com/devopshq/zabbix-review-export
من سيكون مهتمًا بهذه الوظيفة في مربع Zabbix - يرجى التصويت لصالح المشكلة https://support.zabbix.com/browse/ZBXNEXT-4862
كل 100 ٪ الجهوزية!