سيعقد مؤتمر HighLoad ++ القادم في 6 و 7 أبريل 2020 في سان بطرسبرج التفاصيل والتذاكر . HighLoad ++ موسكو 2018. قاعة موسكو. 9 نوفمبر ، 15:00. الملخصات و .
* المراقبة - عبر الإنترنت والتحليلات.
* القيود الرئيسية لمنصة ZABBIX.
* حل لتوسيع نطاق تخزين التحليلات.
* تحسين خادم ZABBIX.
* تحسين واجهة المستخدم.
* خبرة في تشغيل النظام بأحمال تزيد عن 40 ألف NVPS.
* استنتاجات موجزة.
ميخائيل ماكوروف (يُشار إليه فيما بعد - MM): - أهلاً بكم!
مكسيم تشيرنيتسوف (يشار إليه فيما يلي بـ MCH): - مساء الخير!
مم: اسمحوا لي أن أقدم مكسيم. ماكس مهندس موهوب ، أفضل مسوق شبكي أعرفه. مكسيم يتعامل مع الشبكات والخدمات وتطويرها وتشغيلها.
صحة الأم والطفل: - وأود أن أخبركم عن مايكل. مايكل هو مطور سي. كتب العديد من حلول معالجة حركة المرور عالية الحمل لشركتنا. نحن نعيش ونعمل في جبال الأورال ، في مدينة الرجال الأقوياء تشيليابينسك ، في شركة Intersvyaz. شركتنا هي مزود خدمة الإنترنت والتلفزيون الكبلي لمليون شخص في 16 مدينة.
مم: - ومن الجدير بالذكر أن Intersvyaz هي أكثر بكثير من مجرد مزود ، إنها شركة تكنولوجيا معلومات. يتم إجراء معظم حلولنا بواسطة قسم تكنولوجيا المعلومات لدينا.
أ: من الخوادم التي تعالج حركة المرور إلى مركز الاتصال وتطبيق الهاتف المحمول. يضم قسم تكنولوجيا المعلومات الآن حوالي 80 شخصًا يتمتعون بكفاءات متنوعة للغاية.
حول Zabbix وهندستها المعمارية
صحة الأم والطفل: - والآن سأحاول أن أسجل رقمًا قياسيًا شخصيًا وفي دقيقة واحدة أقول ما هو Zabbix (المشار إليه فيما يلي بـ "Zabbiks").
Zabbix يضع نفسه كنظام مراقبة مستوى المؤسسة خارج الصندوق. يحتوي على العديد من الميزات التي تجعل الحياة أسهل: قواعد التصعيد المتقدمة وواجهة برمجة التطبيقات للتكامل والتجميع والاكتشاف التلقائي للمضيفين والمقاييس. لدى Zabbix ما يسمى بأدوات التحجيم - الوكلاء. Zabbix هو نظام مفتوح المصدر.
باختصار عن العمارة. يمكننا القول أنه يتكون من ثلاثة مكونات:
- الخادم. مكتوب في C. مع معالجة معقدة نوعًا ما ونقل المعلومات بين الخيوط. تتم جميع عمليات المعالجة فيه: من الاستلام إلى الحفظ في قاعدة البيانات.
- يتم تخزين جميع البيانات في قاعدة البيانات. يدعم Zabbix MySQL و PostreSQL و Oracle.
- واجهة الويب مكتوبة بلغة PHP. في معظم الأنظمة ، يأتي مع خادم Apache ، لكنه يعمل بكفاءة أكبر مع nginx + php.
اليوم نود أن نحكي قصة واحدة تتعلق بـ Zabbix من حياة شركتنا ...
قصة من حياة شركة Intersvyaz. ماذا لدينا وماذا نحتاج؟
قبل 5 أو 6 أشهر. يوم واحد بعد العمل ...
صحة الأم والطفل: - ميشا ، مرحبا! أنا سعيد لأنني تمكنت من اللحاق بك - هناك محادثة. مرة أخرى لدينا مشاكل في المراقبة. خلال حادث كبير ، تباطأ كل شيء ، ولم تكن هناك معلومات عن حالة الشبكة. لسوء الحظ ، هذه ليست المرة الأولى التي يحدث فيها هذا. انا بحاجة الى مساعدتكم. دعونا نجعل أعمال المراقبة لدينا تحت أي ظرف من الظروف!
مم: لكن دعنا نتزامن أولاً. لم أبحث هناك منذ عامين. بقدر ما أتذكر ، تخلينا عن Nagios وانتقلنا إلى Zabbix منذ حوالي 8 سنوات. والآن يبدو أن لدينا 6 خوادم قوية وعشرات من الوكلاء. هل أنا في حيرة من أمري؟
صحة الأم والطفل: - بالكاد. 15 خادمًا ، بعضها عبارة عن أجهزة افتراضية. والأهم من ذلك ، أنه لا ينقذنا في الوقت الذي نحن في أمس الحاجة إليه. مثل حادث - تتباطأ الخوادم ولا يظهر أي شيء. لقد حاولنا تحسين التكوين ، لكن هذا لا يعطي تحسينًا مثاليًا للأداء.
مم: - انها واضحة. هل نظرت إلى شيء ما ، هل سبق لك أن استخرجت شيئًا من التشخيص؟
صحة الأم والطفل: - أول شيء عليك التعامل معه هو مجرد قاعدة البيانات. يتم تحميل MySQL باستمرار ، مما يوفر مقاييس جديدة ، وعندما يبدأ Zabbix في إنشاء مجموعة من الأحداث ، تنتقل قاعدة البيانات إلى نفسها حرفيًا لبضع ساعات. لقد أخبرتك بالفعل عن تحسين التكوين ، لكنهم قاموا بتحديث الأجهزة حرفيًا هذا العام: تحتوي الخوادم على أكثر من مائة غيغابايت من الذاكرة وصفيفات القرص على SSD RAIDs - لا فائدة من تنميتها خطيًا. ماذا نفعل؟
مم: - انها واضحة. بشكل عام ، تعد MySQL قاعدة بيانات LTP. على ما يبدو ، لم يعد مناسبًا لتخزين أرشيف المقاييس بحجمنا. دعونا نفهم ذلك.
صحة الأم والطفل: - دعونا!
تكامل Zabbix و Clickhouse نتيجة الهاكاثون
بعد مرور بعض الوقت ، تلقينا بيانات مثيرة للاهتمام:
شغل أرشيف المقاييس معظم المساحة الموجودة في قاعدة البيانات الخاصة بنا وتم استخدام أقل من 1٪ للتكوين والقوالب والإعدادات. بحلول ذلك الوقت ، كنا نشغل حلًا للبيانات الضخمة يعتمد على Clickhouse لأكثر من عام. كان اتجاه الحركة بالنسبة لنا واضحًا. في Hackathon الربيعي ، كتبت دمج Zabbix مع Clickhouse للخادم والواجهة الأمامية. في ذلك الوقت ، كان Zabbix يدعم بالفعل ElasticSearch ، وقررنا مقارنته.
مقارنة بين Clickhouse و Elasticsearch
مم: - للمقارنة ، قمنا بإنشاء الحمل نفسه الذي يوفره خادم Zabbix وفحصنا كيف ستتصرف الأنظمة. كتبنا البيانات على دفعات من 1000 سطر باستخدام CURL. افترضنا مقدمًا أن Clickhouse سيكون أكثر كفاءة لملف تعريف التحميل الذي يقوم به Zabbix. النتائج فاقت توقعاتنا:
في ظل ظروف الاختبار نفسها ، كتب Clickhouse ثلاثة أضعاف البيانات. في الوقت نفسه ، يستهلك كلا النظامين بكفاءة عالية (كمية صغيرة من الموارد) عند قراءة البيانات. لكن المطاطية تطلبت كمية كبيرة من المعالج عند التسجيل:
في المجموع ، تفوق Clickhouse بشكل كبير على Elastics من حيث استهلاك المعالج وسرعته. في الوقت نفسه ، وبسبب ضغط البيانات ، يستخدم Clickhouse 11 مرة أقل على القرص الصلب ويقوم بعمليات أقل بحوالي 30 مرة:
صحة الأم والطفل: - نعم ، يتم تنفيذ عمل Clickhouse مع نظام القرص الفرعي بكفاءة عالية. يمكنك استخدام محركات أقراص SATA ضخمة لقواعد البيانات والحصول على سرعات كتابة تصل إلى مئات الآلاف من الأسطر في الثانية. يدعم النظام الجاهز للتجزئة ، والنسخ المتماثل ، كما أنه سهل الإعداد. نحن أكثر من راضين عن عملها خلال العام.
لتحسين الموارد ، يمكنك تثبيت Clickhouse بجوار القاعدة الرئيسية الحالية وبالتالي توفير الكثير من وقت وحدة المعالجة المركزية وعمليات القرص. نقلنا أرشيف المقاييس إلى مجموعات Clickhouse الحالية:
قمنا بتفريغ قاعدة بيانات MySQL الرئيسية كثيرًا حتى نتمكن من دمجها على نفس الجهاز مع خادم Zabbix والتخلي عن الخادم المخصص لـ MySQL.
كيف يعمل الاقتراع في Zabbix؟
منذ أشهر 4
مم: - حسنًا ، هل يمكنك نسيان مشاكل القاعدة؟
صحة الأم والطفل: - بالتأكيد! التحدي الآخر الذي نحتاج إلى حله هو بطء جمع البيانات. الآن جميع الخوادم الوكيلة الـ 15 لدينا محملة فوق طاقتها بعمليات SNMP والاستقصاء. ولا توجد طريقة أخرى سوى تثبيت خوادم جديدة وجديدة.
مم: - عظيم. لكن أولاً ، كيف يعمل الاقتراع في Zabbix؟
صحة الأم والطفل: - باختصار ، هناك 20 نوعًا من المقاييس وعشرات الطرق للحصول عليها. يمكن لـ Zabbix جمع البيانات إما في وضع "استجابة الطلب" ، أو الانتظار للحصول على بيانات جديدة من خلال "واجهة Trapper".
تجدر الإشارة إلى أن هذه الطريقة (Trapper) في Zabbix الأصلية هي الأسرع.
هناك خوادم بروكسي لموازنة التحميل:
يمكن للوكلاء أداء نفس وظائف المجموعة مثل خادم Zabbix ، وتلقي المهام منه وإرسال المقاييس المجمعة فقط من خلال واجهة Trapper. هذه هي الطريقة الموصى بها رسميًا لتوزيع الحمل. تعد الخوادم الوكيلة مفيدة أيضًا لمراقبة البنية التحتية البعيدة التي تعمل عبر NAT أو ارتباط بطيء:
مم: كل شيء واضح مع الهندسة المعمارية. أحتاج إلى إلقاء نظرة على المصدر ...
بعد يومين
قصة كيف فاز nmap fping
مم: "يبدو أنني بحثت عن شيء ما.
صحة الأم والطفل: - أخبرني!
مم: - وجدت أنه عند التحقق من التوفر ، يتحقق Zabbix بحد أقصى 128 مضيفًا في نفس الوقت. حاولت زيادة هذا الرقم إلى 500 وأزلت الفاصل الزمني بين الحزم في اختبار ping (ping) - ضاعف هذا الأداء. لكني أريد أرقامًا كبيرة.
صحة الأم والطفل: - في ممارستي ، يتعين علي أحيانًا التحقق من توفر الآلاف من المضيفين ، ولم أر أي شيء أسرع من nmap لهذا الغرض. أنا متأكد من أن هذه هي أسرع طريقة. دعنا نحاول! تحتاج إلى زيادة عدد المضيفين بشكل كبير في تكرار واحد.
مم: - تحقق أكثر من خمسمائة؟ 600؟
صحة الأم والطفل: "ما لا يقل عن بضعة آلاف.
مم: - نعم. أهم شيء أردت قوله هو أنني وجدت أن معظم الاستطلاعات في Zabbix تتم بشكل متزامن. يجب علينا تغييره إلى الوضع غير المتزامن. ثم يمكننا زيادة عدد المقاييس التي تم جمعها من قبل المستطلعين بشكل كبير ، خاصة إذا قمنا بزيادة عدد المقاييس لكل تكرار.
صحة الأم والطفل: - عظيم! وعندما؟
مم: - كالعادة أمس.
صحة الأم والطفل: - قارنا كلا الإصدارين من fping و nmap:
على عدد كبير من المضيفين ، كان من المتوقع أن يكون nmap أكثر كفاءة بخمس مرات. نظرًا لأن nmap يتحقق فقط من التوافر ووقت الاستجابة ، فقد نقلنا حساب الخسارة إلى المشغلات وقللنا بشكل كبير فترات فحص الإتاحة. وجدنا أن العدد الأمثل للمضيفين لـ nmap هو حوالي 4 آلاف لكل تكرار. سمح لنا Nmap بتقليل تكلفة وحدة المعالجة المركزية لعمليات التحقق من التوفر بمعامل ثلاثة وتقليل الفاصل الزمني من 120 ثانية إلى 10.
تحسين الاقتراع
مم: "ثم دخلنا في استطلاعات الرأي. كنا مهتمين بشكل أساسي بالتقاط SNMP والوكلاء. في Zabbix ، يتم إجراء الاستقصاء بشكل متزامن ويتم اتخاذ تدابير خاصة لزيادة كفاءة النظام. في الوضع المتزامن ، يؤدي عدم توفر المضيفين إلى تدهور كبير في الاقتراع. هناك نظام كامل من الدول ، وهناك عمليات خاصة - ما يسمى بأصوات الاقتراع التي لا يمكن الوصول إليها ، والتي تعمل فقط مع مضيفين لا يمكن الوصول إليهم:
هذا تعليق يوضح مصفوفة الحالة ، وتعقيد نظام الانتقال المطلوب حتى يظل النظام فعالاً. بالإضافة إلى ذلك ، فإن الاستقصاء المتزامن نفسه بطيء جدًا:
هذا هو السبب في أن الآلاف من خيوط الاستقصاء على عشرات الوكلاء لم يتمكنوا من جمع الكمية المطلوبة من البيانات لنا. لم يحل التطبيق غير المتزامن مشاكل عدد سلاسل الرسائل فحسب ، بل أدى أيضًا إلى تبسيط نظام حالة المضيفين غير المتاحين إلى حد كبير ، لأنه بالنسبة لأي رقم تم تسجيله في تكرار استقصاء واحد ، كان الحد الأقصى لوقت الانتظار هو مهلة واحدة:
بالإضافة إلى ذلك ، قمنا بتعديل وتحسين نظام الاقتراع لطلبات SNMP. الحقيقة هي أن معظمهم لا يستطيع الاستجابة لطلبات SNMP المتعددة في نفس الوقت. لذلك ، قمنا بعمل وضع مختلط ، عندما يتم استقصاء SNMP لنفس المضيف بشكل غير متزامن:
يتم ذلك لحزمة المضيفين بأكملها. هذا الوضع في النهاية ليس أبطأ من غير المتزامن تمامًا ، نظرًا لأن استقصاء مائة ونصف من قيم SNMP لا يزال أسرع بكثير من مهلة واحدة.
أظهرت تجاربنا أن العدد الأمثل للطلبات في تكرار واحد هو حوالي 8 آلاف مع استقصاء SNMP. في المجموع ، أتاح لنا الانتقال إلى الوضع غير المتزامن تسريع أداء الاستقصاء بمقدار 200 مرة ، عدة مئات من المرات.
صحة الأم والطفل: - أظهرت تحسينات الاقتراع الناتجة أنه لا يمكننا فقط التخلص من جميع الوكلاء ، ولكن أيضًا تقليل الفترات الفاصلة للعديد من عمليات التحقق ، ولن تكون هناك حاجة إلى الوكلاء كوسيلة لمشاركة الحمل.
منذ حوالي ثلاثة أشهر
تغيير الهيكل - زيادة الحمل!
مم: - حسنًا ، ماكس ، حان الوقت لتكون منتجًا؟ أحتاج إلى خادم قوي ومهندس جيد.
صحة الأم والطفل: - حسنًا ، دعنا نخطط. لقد حان الوقت للانتقال من النقطة الميتة في 5 آلاف مقياس في الثانية.
الصباح بعد الترقية
صحة الأم والطفل: - ميشا ، قمنا بالترقية ، لكننا تراجعنا في الصباح ... خمن ما هي السرعة التي تمكنت من تحقيقها؟
مم: - 20 ألف كحد أقصى.
صحة الأم والطفل: - نعم ، 25! لسوء الحظ ، نحن على حق حيث بدأنا.
مم: - لماذا؟ هل قمت بإجراء أي تشخيص؟
صحة الأم والطفل: - نعم بالتأكيد! هنا ، على سبيل المثال ، قمة مثيرة للاهتمام:
مم: - دعنا نشاهد. أرى أننا جربنا عددًا كبيرًا من خيوط الاقتراع:
لكن في الوقت نفسه ، لم يتمكنوا من استخدام النظام حتى بمقدار النصف:
والأداء العام صغير جدًا ، حوالي 4 آلاف مقياس في الثانية:
هل هناك شيء آخر؟
صحة الأم والطفل: - نعم استقامة احد المستطلعين:
مم: - هنا يمكنك أن ترى بوضوح أن عملية الاقتراع تنتظر "إشارات". هذه هي الأقفال:
صحة الأم والطفل: - غير واضح.
مم: - انظر ، إنه مثل الموقف الذي تحاول فيه مجموعة من سلاسل الرسائل العمل مع الموارد التي يمكن لشخص واحد فقط العمل معها في نفس الوقت. ثم كل ما يمكنهم فعله هو تقسيم هذا المورد على الوقت:
والأداء الكلي للعمل مع مثل هذا المورد مقيد بسرعة نواة واحدة:
هناك طريقتان لحل هذه المشكلة.
قم بترقية أجهزة الماكينة ، وانتقل إلى النوى الأسرع:
أو تغيير البنية وبالتوازي - الحمل:
صحة الأم والطفل: - بالمناسبة ، في آلة الاختبار ، سنستخدم عددًا أقل من النوى مقارنةً بالجهاز القتالي ، لكنها أسرع بمقدار 1,5 مرة من حيث التردد لكل نواة!
مم: - واضح؟ من الضروري إلقاء نظرة على رمز الخادم.
مسار البيانات في خادم Zabbix
صحة الأم والطفل: - لفهم ذلك ، بدأنا في تحليل كيفية نقل البيانات داخل خادم Zabbix:
صورة رائعة ، أليس كذلك؟ دعنا نمر بها خطوة بخطوة لتوضيح أكثر أو أقل. هناك سلاسل رسائل وخدمات مسؤولة عن جمع البيانات:
يمررون المقاييس التي تم جمعها عبر المقبس إلى مدير Preprocessor ، حيث يتم تخزينها في قائمة الانتظار:
يقوم مدير ما قبل المعالج "بتمرير البيانات إلى عامليها ، الذين يقومون بتنفيذ تعليمات ما قبل المعالجة وإعادتها مرة أخرى من خلال نفس المقبس:
يقوم مدير المعالج المسبق بعد ذلك بتخزينها في ذاكرة التخزين المؤقت للتاريخ:
من هناك ، يتم أخذها بواسطة أدوات قياس التاريخ التي تؤدي عددًا قليلاً من الوظائف: على سبيل المثال ، حساب المشغلات ، وملء ذاكرة التخزين المؤقت للقيمة ، والأهم من ذلك ، حفظ المقاييس في مخزن المحفوظات. بشكل عام ، العملية معقدة ومربكة للغاية.
مم: - أول شيء رأيناه هو أن معظم الخيوط تتنافس على ما يسمى ب "ذاكرة التخزين المؤقت للتهيئة" (منطقة الذاكرة حيث يتم تخزين جميع تكوينات الخادم). يتم إجراء الكثير من الأقفال بشكل خاص بواسطة الخيوط المسؤولة عن استرداد البيانات:
... نظرًا لأن التكوين لا يخزن المقاييس مع معلماتها فحسب ، بل يخزن أيضًا قوائم الانتظار التي يأخذ منها المستطلعون معلومات حول ما يجب القيام به بعد ذلك. عندما يكون هناك العديد من أدوات الاقتراع ، ويقوم أحدهم بحظر التكوين ، فإن الباقي ينتظر الطلبات:
لا ينبغي أن يتعارض المستطلعون
لذلك ، كان أول شيء فعلناه هو تقسيم قائمة الانتظار إلى 4 أجزاء والسماح للقائمين بالاستقصاء بحظر قوائم الانتظار هذه بأمان ، وهذه الأجزاء في نفس الوقت:
أدى ذلك إلى إزالة المنافسة على ذاكرة التخزين المؤقت للتهيئة ، وزادت سرعة أدوات الاقتراع بشكل كبير. ولكن بعد ذلك واجهنا حقيقة أن مدير المعالج المسبق بدأ في تجميع قائمة انتظار الوظائف:
يجب أن يكون مدير المعالج السابق قادرًا على تحديد الأولويات
حدث هذا في الحالات التي تفتقر فيها إلى الأداء. ثم كل ما يمكن فعله هو تجميع الطلبات من عمليات جمع البيانات وإضافة المخزن المؤقت الخاص بهم حتى يلتهم كل الذاكرة ويتعطل:
لحل هذه المشكلة ، أضفنا مقبسًا ثانيًا مخصصًا خصيصًا للعمال:
وبالتالي ، أتيحت الفرصة لمدير المعالج المسبق لتحديد أولويات عمله ، وفي حالة نمو المخزن المؤقت ، تتمثل المهمة في إبطاء عملية الإزالة ، مما يمنح العمال الفرصة لالتقاط هذا المخزن المؤقت:
ثم اكتشفنا أن أحد أسباب التباطؤ كان العمال أنفسهم ، حيث تنافسوا على مورد غير مهم على الإطلاق لعملهم. لقد أصدرنا إصلاحًا للأخطاء لهذه المشكلة ، وقد تم حلها بالفعل في الإصدارات الجديدة من Zabbix:
نزيد عدد المقابس - نحصل على النتيجة
علاوة على ذلك ، أصبح مدير المعالج المسبق نفسه عنق الزجاجة ، لأنه خيط واحد. لقد استند على سرعة النواة ، مما أعطى سرعة قصوى تبلغ حوالي 70 ألف مقياس في الثانية:
لذلك صنعنا أربعة ، بأربع مجموعات مقابس ، عمال:
وهذا سمح لنا بزيادة السرعة إلى حوالي 130 ألف مقياس:
يفسر النمو اللاخطي بحقيقة وجود منافسة على ذاكرة التخزين المؤقت للتاريخ. تنافس 4 من مديري المعالجات المسبقة ومغولي التاريخ على ذلك. بحلول هذه المرحلة ، كنا نحصل على حوالي 130 ألف مقياس في الثانية على جهاز الاختبار ، مستخدمينها بحوالي 95٪ من المعالج:
منذ حوالي 2,5 شهر
أدى رفض مجتمع snmp إلى زيادة NVPs بمقدار مرة ونصف
مم: ماكس ، أحتاج سيارة اختبارية جديدة! لم نعد ننسجم مع الوضع الحالي.
صحة الأم والطفل: - ماذا لديك الآن؟
مم: - الآن - 130 ألف NVPs ومعالج الرف.
صحة الأم والطفل: - رائع! رائع! انتظر ، لدي سؤالان. وفقًا لحساباتي ، فإن حاجتنا تتراوح بين 15 و 20 ألف مقياس في الثانية. لماذا نحتاج المزيد؟
مم: - اريد ان انهي العمل. أريد أن أرى مقدار ما يمكننا الضغط عليه للخروج من هذا النظام.
صحة الأم والطفل: - ولكن…
مم: لكنها غير مجدية للأعمال.
صحة الأم والطفل: - انها واضحة. والسؤال الثاني: هل سنتمكن من دعم ما لدينا الآن بمفردنا ، دون مساعدة مطور؟
مم: - لا اعتقد. يعد تغيير كيفية عمل ذاكرة التخزين المؤقت للتكوين مشكلة. إنه يتعامل مع التغييرات في معظم التدفقات ويصعب الحفاظ عليه. على الأرجح ، سيكون من الصعب جدًا الحفاظ عليها.
صحة الأم والطفل: "إذن نحن بحاجة إلى بديل."
مم: - يوجد مثل هذا الخيار. يمكننا التبديل إلى النوى السريعة ، مع التخلي عن نظام الحجب الجديد. سنظل نحصل على أداء يتراوح بين 60 و 80 ألف مقياس. في هذه الحالة ، يمكننا ترك باقي الكود. Clickhouse ، سيعمل الاقتراع غير المتزامن. وسيكون من السهل صيانته.
صحة الأم والطفل: - مدهش! أقترح التوقف هناك.
بعد تحسين جانب الخادم ، تمكنا أخيرًا من تشغيل الكود الجديد في الإنتاج. لقد تخلينا عن بعض التغييرات لصالح الانتقال إلى آلة ذات نوى سريعة وتقليل عدد التغييرات في الكود. لقد قمنا أيضًا بتبسيط التكوين وتجنبنا وحدات الماكرو في العناصر حيثما أمكن ذلك ، لأنها مصدر أقفال إضافية.
على سبيل المثال ، سمح لنا رفض ماكرو المجتمع snmp ، والذي يوجد غالبًا في الوثائق والأمثلة ، في حالتنا بتسريع NVPs بحوالي 1,5 مرة.
بعد يومين في الإنتاج
إزالة النوافذ المنبثقة لتاريخ الحادث
صحة الأم والطفل: - ميشا ، نحن نستخدم النظام منذ يومين ، وكل شيء يعمل. ولكن فقط عندما يعمل كل شيء! لقد خططنا للعمل مع نقل جزء كبير إلى حد ما من الشبكة ، وفحصنا مرة أخرى بأيدينا ما حدث وما لم يحدث.
مم: - لا يمكن أن يكون! فحصنا كل شيء 10 مرات. يتعامل الخادم مع عدم توفر الشبكة بالكامل على الفور.
صحة الأم والطفل: - نعم ، أفهم كل شيء: الخادم ، وقاعدة البيانات ، والجزء العلوي ، والأوستات ، والسجلات - كل شيء سريع ... لكننا ننظر إلى واجهة الويب ، ويوجد معالج "في الرف" على الخادم وهذا:
مم: - انها واضحة. دعنا نشاهد الويب. وجدنا أنه في حالة وجود عدد كبير من الحوادث النشطة ، بدأت معظم عناصر واجهة المستخدم التشغيلية في العمل ببطء شديد:
كان السبب في ذلك هو إنشاء النوافذ المنبثقة لسجل الأحداث التي تم إنشاؤها لكل عنصر في القائمة. لذلك ، رفضنا إنشاء هذه النوافذ (علقنا على 5 أسطر في الكود) ، وهذا حل مشاكلنا.
تم تقليل وقت تحميل الأداة ، حتى في حالة عدم توفرها تمامًا ، من عدة دقائق إلى 10-15 ثانية ، وهو أمر مقبول بالنسبة لنا ، ولا يزال بإمكانك مشاهدة السجل من خلال النقر على الوقت:
بعد العمل. منذ شهرين
صحة الأم والطفل: ميشا ، هل سترحل؟ يجب أن نتحدث.
مم: - لم أقصد ذلك. شيء ما مع Zabbix مرة أخرى؟
صحة الأم والطفل: - لا ، استرخ! أردت فقط أن أقول: كل شيء يعمل ، شكرًا! بيرة مني.
Zabbix فعال
Zabbix هو نظام ووظيفة متعددة الاستخدامات وغنية إلى حد ما. يمكن استخدامه للتركيبات الصغيرة خارج الصندوق ، ولكن مع نمو الاحتياجات ، يجب تحسينه. لتخزين أرشيف كبير من المقاييس ، استخدم مساحة تخزين مناسبة:
- يمكنك استخدام الأدوات المدمجة في شكل تكامل مع Elasticsearch أو تحميل المحفوظات إلى ملفات نصية (متوفرة من الإصدار الرابع) ؛
- يمكنك استخدام خبرتنا والتكامل مع Clickhouse.
لزيادة سرعة جمع المقاييس بشكل كبير ، قم بتجميعها باستخدام طرق غير متزامنة ونقلها من خلال واجهة trapper إلى خادم Zabbix ؛ أو يمكنك استخدام التصحيح لأجهزة الاقتراع غير المتزامنة لـ Zabbix نفسها.
Zabbix مكتوب بلغة C وهو فعال للغاية. يسمح حل العديد من الاختناقات المعمارية بزيادة أدائها ، ومن واقع خبرتنا ، الحصول على أكثر من 100 مقياس على جهاز معالج واحد.
نفس التصحيح Zabbix
مم: - اريد اضافة بضع نقاط. يتم تقديم التقرير الحالي بالكامل ، وجميع الاختبارات ، والأرقام للتكوين الذي نستخدمه. نحن الآن نأخذ منه حوالي 20 ألف مقياس في الثانية. إذا كنت تحاول فهم ما إذا كان سيعمل من أجلك - يمكنك المقارنة. ما تحدثنا عنه اليوم تم نشره على GitHub كتصحيح:
يشمل التصحيح:
- التكامل الكامل مع Clickhouse (كل من خادم Zabbix والواجهة الأمامية) ؛
- حل المشكلات مع مدير المعالج المسبق ؛
- الاقتراع غير المتزامن.
التصحيح متوافق مع جميع الإصدارات 4 ، بما في ذلك lts. على الأرجح ، مع الحد الأدنى من التغييرات ، سيعمل على الإصدار 3.4.
شكرا لكم على اهتمامكم.
الأسئلة
سؤال من الحضور (فيما يلي - أ): - مساء الخير! أخبرني من فضلك ، هل لديك خطط للتفاعل المكثف مع فريق Zabbix أم لديهم معك ، حتى لا يكون هذا تصحيحًا ، بل هو سلوك Zabbix الطبيعي؟
مم: - نعم ، سنقوم بالتأكيد ببعض التغييرات. سيحدث شيء ما ، سيبقى شيء ما في الرقعة.
أ: - شكرا جزيلا على التقرير الممتاز! أخبرني ، من فضلك ، بعد تطبيق التصحيح ، سيبقى الدعم من Zabbix وكيفية الترقية إلى الإصدارات الأعلى؟ هل سيكون من الممكن تحديث Zabbix بعد التصحيح الخاص بك إلى 4.2 ، 5.0؟
مم: لا أستطيع التحدث للحصول على الدعم. إذا كنت من عملاء Zabbix الفني ، إذن ، على ما يبدو ، سأقول لا ، لأن هذا هو رمز شخص آخر. أما بالنسبة لقاعدة الشفرة 4.2 ، فإن موقفنا هو: "سنمضي مع الوقت ، وسنقوم بتحديث أنفسنا في الإصدار التالي." لذلك ، سنقوم لبعض الوقت بتحميل تصحيح للإصدارات المحدثة. لقد قلت بالفعل في التقرير: لا يزال عدد التغييرات مع الإصدارات صغيرًا جدًا. أعتقد أن الانتقال من 3.4 إلى 4 استغرق منا ، على ما يبدو ، حوالي 15 دقيقة. شيء ما قد تغير هناك ، لكنه ليس مهمًا للغاية.
أ: - إذن أنت تخطط لدعم التصحيح الخاص بك ويمكنك وضعه في الإنتاج بأمان ، وتلقي التحديثات في المستقبل بطريقة ما؟
مم: - نوصي به بشدة. إنه يحل الكثير من المشاكل بالنسبة لنا.
صحة الأم والطفل: - مرة أخرى ، أود التأكيد على أن التغييرات التي لا تتعلق بالعمارة ولا تتعلق بالأقفال وقوائم الانتظار - فهي معيارية ، وهي في وحدات منفصلة. حتى لو كانت بمفردها مع تغييرات طفيفة ، يمكن صيانتها بسهولة تامة.
مم: - إذا كنت مهتمًا بالتفاصيل ، فإن Clickhouse تستخدم مكتبة التاريخ المزعومة. إنه غير مقيد - هذه نسخة من دعم Elastics ، أي أنها قابلة للتكوين. الاقتراع يغير فقط المستطلعين. نعتقد أن هذا سوف يعمل لفترة طويلة.
أ: - شكرًا جزيلاً. وأخبرني ، هل هناك أي توثيق للتغييرات التي تم إجراؤها؟
مم: - التوثيق رقعة. من الواضح ، مع إدخال Clickhouse ، مع إدخال أنواع جديدة من أدوات الاقتراع ، تظهر خيارات تكوين جديدة. يحتوي الارتباط من الشريحة الأخيرة على وصف موجز لكيفية استخدامه.
حول استبدال fping بـ nmap
أ: - كيف انتهى بك الأمر بفعل ذلك؟ هل يمكنك إعطاء أمثلة محددة: هل لديك شرائط ونص خارجي؟ ما الذي ينتهي بفحص العديد من المضيفين بهذه السرعة؟ كيف تقوم بتعدين هؤلاء المضيفين؟ هل يجب أن يقوم nmap بإطعامهم بطريقة ما ، أو الحصول عليهم من مكان ما ، أو إدخالهم ، أو تشغيل شيء ما؟ ..
مم: - رائع. سؤال وجيه جدا! هذه هي النقطة. لقد قمنا بتعديل المكتبة (ICMP ping ، جزء لا يتجزأ من Zabbix) لفحص ICMP ، والتي تشير إلى عدد الحزم - واحد (1) ، ويحاول الكود استخدام nmap. أي ، هذا هو العمل الداخلي لـ Zabbix ، لقد أصبح العمل الداخلي لجهاز pinger. وفقًا لذلك ، لا يلزم إجراء مزامنة أو استخدام للصيد. تم القيام بذلك عن عمد من أجل الحفاظ على النظام سليمًا وليس لمزامنة النظامين الأساسيين: ما الذي يجب التحقق منه ، والتحميل من خلال أداة الاقتراع ، وما إذا كان التحميل معطلاً؟ .. إنه أسهل بكثير.
أ: - هل تعمل مع الوكلاء أيضًا؟
مم: نعم ، لكننا لم نتحقق. رمز الاقتراع هو نفسه في كل من Zabbix والخادم. يجب أن تعمل. أؤكد مرة أخرى: أداء النظام لا نحتاج إلى وكيل.
صحة الأم والطفل: - الإجابة الصحيحة على السؤال هي: "لماذا تحتاج إلى وكيل بمثل هذا النظام؟" فقط بسبب NAT'a أو لرصد من خلال قناة بطيئة بعض ...
أ: - وأنت تستخدم Zabbix كجاذب ، إذا فهمت بشكل صحيح. أو هل انتقلت الرسومات (أين توجد طبقة الأرشيف) إلى نظام آخر ، مثل Grafana؟ أم أنك لا تستخدم هذه الوظيفة؟
مم: - سأؤكد مرة أخرى: لقد حققنا اندماجاً كاملاً. نصب التاريخ في Clickhouse ، لكن في نفس الوقت قمنا بتغيير الواجهة الأمامية لـ php. ينتقل Php-frontend إلى Clickhouse ويقوم بجميع الرسومات من هناك. في الوقت نفسه ، لكي نكون صادقين ، لدينا جزء يقوم ببناء البيانات في أنظمة عرض الرسوم الأخرى من نفس Clickhouse ، من نفس بيانات Zabbix.
صحة الأم والطفل: - في "جرافانا" بما في ذلك.
كيف تم اتخاذ قرار تخصيص الموارد؟
أ: - شارك قليلاً من المطبخ الداخلي. كيف تم اتخاذ القرار بضرورة تخصيص الموارد لمعالجة جادة للمنتج؟ هذه ، بشكل عام ، بعض المخاطر. ورجاء إخباري ، في سياق حقيقة أنك ستدعم الإصدارات الجديدة: كيف يبرر هذا القرار من وجهة نظر الإدارة؟
مم: - على ما يبدو ، لم نخبر دراما التاريخ بشكل جيد. وجدنا أنفسنا في موقف كان يجب القيام فيه بشيء ما ، وذهبنا في الواقع بأمرين متوازيين:
- شارك أحدهم في إطلاق نظام مراقبة يعتمد على طرق جديدة: المراقبة كخدمة ، مجموعة قياسية من الحلول مفتوحة المصدر التي ندمجها ثم نحاول تغيير عملية العمل من أجل العمل مع نظام المراقبة الجديد.
- في موازاة ذلك ، كان لدينا مبرمج متحمس فعل هذا (عن نفسه). لقد حدث أنه ربح.
أ: - وما هو حجم الفريق؟
صحة الأم والطفل: هي أمامك.
أ: - هذا ، كما هو الحال دائمًا ، هناك حاجة إلى شغف؟
مم: - لا أعرف ما هو الشغف.
أ: في هذه الحالة ، يبدو أنك أنت. شكرا جزيلا لك ، أنت رائع.
مم: - شكرًا لك.
حول بقع Zabbix
أ: - بالنسبة للنظام الذي يستخدم الوكيل (على سبيل المثال ، في بعض الأنظمة الموزعة) ، هل من الممكن تكييف وتصحيح ، على سبيل المثال ، أجهزة الاستقصاء والوكلاء والمعالج المسبق لـ Zabbix نفسه ؛ وتفاعلهم؟ هل من الممكن تحسين التطورات الحالية لنظام ذي وكلاء متعددين؟
مم: - أعلم أن خادم "Zabbix" يتم تجميعه باستخدام وكيل (يتم تجميعه والحصول على الكود). لم نختبر هذا في الإنتاج. لست متأكدًا من ذلك ، لكنني لا أعتقد أن مدير المعالج المسبق مستخدم في الوكيل. تتمثل مهمة الوكيل في أخذ مجموعة من المقاييس من Zabbix وتفريغها (كما يسجل التكوين وقاعدة البيانات المحلية) وإعادتها إلى خادم Zabbix. سيقوم الخادم نفسه بعد ذلك بإجراء المعالجة المسبقة عند استلامه.
الاهتمام بالوكلاء أمر مفهوم. سنفحصه. أنه موضوع شيق.
أ: - كانت الفكرة كالتالي: إذا كان بإمكانك تصحيح أدوات الاقتراع ، فيمكنك تصحيحها على وكيل وتصحيح التفاعل مع الخادم ، وتكييف المعالج المسبق لهذه الأغراض فقط على الخادم.
مم: - أعتقد أنه أسهل. تأخذ الشفرة ، وتطبق التصحيح ، ثم تهيئها بالطريقة التي تريدها - تجمع الخوادم الوكيلة (على سبيل المثال ، مع ODBC) وتوزع الشفرة المصححة بين الأنظمة. عند الضرورة - جمع الوكيل ، عند الضرورة - الخادم.
أ: - بالإضافة إلى ذلك ، لن تضطر إلى تصحيح نقل الوكيل إلى الخادم ، على الأرجح؟
صحة الأم والطفل: لا ، هذا قياسي.
مم: - في الحقيقة ، إحدى الأفكار لم تكن سليمة. لقد حافظنا دائمًا على التوازن بين انفجار الأفكار وعدد التغييرات وسهولة الدعم.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com