Get best of the week

HighLoad ++ و Mikhail Makurov و Maxim Chernetsov (Intersvyaz): Zabbix، 100kNVPS على خادم واحد

سيُعقد مؤتمر HighLoad ++ التالي يومي 6 و 7 أبريل 2020 في سان بطرسبرغ. التفاصيل والتذاكر هنا . HighLoad ++ موسكو 2018. قاعة موسكو. 9 نوفمبر ، 3 مساءً الملخصات والعرض .



* المراقبة - على الإنترنت والتحليلات.
* القيود الرئيسية لمنصة ZABBIX.
* حل لتوسيع نطاق تخزين التحليلات.
* تحسين خادم ZABBIX.
* تحسين واجهة المستخدم.
* خبرة في تشغيل النظام بأحمال تزيد عن 40 ألف NVPS.
* استنتاجات موجزة.

ميخائيل ماكوروف (من الآن فصاعدا - MM): - مرحبا بالجميع!

مكسيم تشيرنيتسوف (فيما يلي - MCH): - مساء الخير!

م: - اسمحوا لي أن أعرض مكسيم. ماكس مهندس موهوب ، أفضل شبكة اتصال أعرفها. تتعامل مكسيم مع الشبكات والخدمات وتطويرها وتشغيلها.



MCH: - وأود أن أتحدث عن مايكل. مايكل مطور C. كتب بعض حلول معالجة حركة المرور المحملة لشركتنا. نحن نعيش ونعمل في جبال الأورال ، في مدينة الفلاحين الشديدين في تشيليابينسك ، في شركة Intersvyaz. شركتنا مزود لخدمات الإنترنت والتلفزيون الكابلي لمليون شخص في 16 مدينة.

مم:- ومن الجدير بالذكر أن Intersvyaz هي أكثر بكثير من مجرد مزود ، إنها شركة تكنولوجيا المعلومات. يتم اتخاذ معظم قراراتنا من قبل قسم تكنولوجيا المعلومات لدينا.

ج: من الخوادم التي تعالج حركة المرور ، إلى مركز الاتصال وتطبيق الهاتف المحمول. يوجد حوالي 80 شخصًا في قسم تكنولوجيا المعلومات بكفاءات متنوعة للغاية.

عن شركة زبكس وهندستها المعمارية


MCH: - وسأحاول الآن تسجيل رقم قياسي شخصي وأقول في دقيقة واحدة ما هو Zabbix (فيما يلي - "Zabbiks").

تضع Zabbix نفسها كنظام مراقبة "خارج الصندوق" على مستوى المؤسسة. لديها العديد من الميزات المبسطة للحياة: قواعد التصعيد المتقدمة ، واجهات برمجة التطبيقات للتكامل ، التجميع والكشف التلقائي عن المضيفين والمقاييس. في Zabbix هناك ما يسمى أدوات القياس - الوكلاء. Zabbix هو نظام مفتوح المصدر.

باختصار حول العمارة. يمكننا القول أنها تتكون من ثلاثة مكونات:



  • الخادم. هو مكتوب في C. مع معالجة معقدة نوعا ما ونقل المعلومات بين تيارات. تتم جميع عمليات المعالجة فيه: من الاستلام إلى الحفظ في قاعدة البيانات.
  • يتم تخزين جميع البيانات في قاعدة البيانات. تدعم Zabbix MySQL و PostreSQL و Oracle.
  • واجهة الويب مكتوبة بلغة PHP. في معظم الأنظمة ، يأتي مع خادم Apache ، ولكنه يعمل بكفاءة أكبر في حزمة nginx + php.

اليوم نود أن نروي من حياة شركتنا قصة واحدة تتعلق بـ Zabbix ...

قصة حياة شركة Intersvyaz. ماذا لدينا وما هو مطلوب؟



قبل 5 أو 6 أشهر. مرة بعد العمل ...

MCH: - ميشا ، مرحبا! سعيد تمكنت من اللحاق بك - هناك محادثة. مرة أخرى كانت لدينا مشاكل مع المراقبة. خلال حادث كبير ، تباطأ كل شيء ، ولم تكن هناك معلومات حول حالة الشبكة. لسوء الحظ ، هذه ليست المرة الأولى التي تتكرر. بحاجه لمساعدتك. دعونا نجعل أعمال المراقبة لدينا تحت أي ظرف من الظروف!

MM: - لكن دعنا نتزامن أولاً. لم أنظر هناك منذ بضع سنوات. بقدر ما أتذكر ، رفضنا Nagios وانتقلنا إلى Zabbix قبل 8 سنوات. والآن يبدو أن لدينا 6 خوادم قوية ونحو 12 خادمًا. هل أربك شيئا؟

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

م: - فهمت. هل نظرت إلى شيء ما ، هل قمت بحفر شيء من التشخيص؟

صحة الأم والطفل:- أول شيء عليك التعامل معه هو قاعدة البيانات فقط. يتم تحميل MySQL باستمرار ، ويحافظ على مقاييس جديدة ، وعندما يبدأ Zabbix في إنشاء مجموعة من الأحداث ، تذهب قاعدة البيانات إلى نفسها حرفيا لعدة ساعات. لقد أخبرتك بالفعل عن تحسين التكوين ، ولكن حرفيًا هذا العام قمنا بتحديث الأجهزة: هناك أكثر من مائة جيجا بايت من الذاكرة على الخوادم ومصفوفات الأقراص على SSD RAID-ahs - لا معنى لنموها بشكل خطي. ماذا نفعل؟

م: - فهمت. بشكل عام ، MySQL هي قاعدة بيانات LTP. على ما يبدو ، لم تعد مناسبة لتخزين أرشيف المقاييس من حجمنا. دعونا نكتشف ذلك.

MCH: - هيا!

تكامل Zabbix و Clickhouse نتيجة ل hackathon


بعد مرور بعض الوقت ، تلقينا بيانات مثيرة للاهتمام:



تم شغل معظم المساحة في قاعدة بياناتنا بأرشيف المقاييس وتم استخدام أقل من 1٪ للتكوين والقوالب والإعدادات. وبحلول ذلك الوقت ، منذ أكثر من عام ، كنا نستخدم حل البيانات الضخمة القائم على Clickhouse. كان اتجاه الحركة واضحًا لنا. في ربيعنا هاكاثون ، كتب دمج Zabbix مع Clickhouse للخادم والواجهة الأمامية. في ذلك الوقت ، كان Zabbix يحظى بالفعل بالدعم لـ ElasticSearch ، وقررنا مقارنتها.



قارن Clickhouse و Elasticsearch


م.م: - للمقارنة ، قمنا بإنشاء نفس الحمل الذي يوفره خادم Zabbix ونظرنا في كيفية تصرف الأنظمة. كتبنا البيانات على دفعات من 1000 سطر ، استخدمنا CURL. اقترحنا سابقًا أن Clickhouse سيكون أكثر فعالية لملف تعريف التحميل الذي يفعله Zabbix. حتى النتائج تجاوزت توقعاتنا: في



ظل نفس ظروف الاختبار ، كتب Clickhouse ثلاث مرات من البيانات. في الوقت نفسه ، استهلك كلا النظامين بكفاءة عالية (كمية صغيرة من الموارد) أثناء قراءة البيانات. لكن "Elastix" تطلب كمية كبيرة من المعالج عند التسجيل:



في المجموع ، تجاوز Clickhouse بشكل كبير Elastix في استهلاك المعالج وسرعته. في الوقت نفسه ، وبسبب ضغط البيانات ، يستخدم "Clickhouse" 11 مرة أقل على القرص الثابت ويقوم بحوالي 30 مرة أقل لعمليات القرص:



MCH: - نعم ، العمل مع النظام الفرعي للقرص في "Clickhouse" فعال للغاية. تحت القواعد ، يمكنك استخدام أقراص SATA ضخمة والحصول على سرعة كتابة مئات الآلاف من الخطوط في الثانية. النظام "خارج الصندوق" يدعم التجميع والنسخ ، ومن السهل جدًا تكوينه. نحن أكثر من سعداء بعملها لمدة عام.

لتحسين الموارد ، يمكنك تثبيت "Clickhouse" بجوار القاعدة الرئيسية الحالية وبالتالي توفير الكثير من وقت المعالج وعمليات القرص. أخذنا أرشيف المقاييس لمجموعات "Clickhouse" الحالية:



لقد قمنا بإلغاء تحميل قاعدة بيانات MySQL الرئيسية لدرجة أنه يمكننا دمجها على نفس الجهاز مع خادم Zabbix والتخلي عن الخادم المخصص لـ MySQL.

كيف يعمل الاستطلاع في Zabbix؟


قبل 4 أشهر م

: - حسنا ، يمكنك نسيان مشاكل القاعدة؟

MCH: - هذا أمر مؤكد! هناك مشكلة أخرى نحتاج إلى حلها وهي جمع البيانات البطيء. الآن جميع البروكسيات الخمس عشرة لدينا مثقلة بعمليات SNMP وعمليات الاقتراع. وليس هناك سوى إنشاء خوادم جديدة وجديدة.

م: - عظيم. ولكن أخبرني أولاً كيف يعمل الاستطلاع في Zabbix.

صحة الأم والطفل: - باختصار ، هناك 20 نوعًا من المقاييس وعشر طرق للحصول عليها. يمكن لـ Zabbix جمع البيانات إما في وضع "الطلب-الاستجابة" ، أو توقع بيانات جديدة من خلال "واجهة Trapper".



من الجدير بالذكر أنه في Zabbix الأصلي هذه الطريقة (Trapper) هي الأسرع.

هناك وكلاء لموازنة التحميل:



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



MM: - كل شيء واضح مع البنية. يجب أن ننظر إلى المصدر ...

بعد ذلك بيومين

قصة كيف فاز nmap fping


م.م: - يبدو أنني حفرت شيئًا.

MCH: - أخبرني!

م.م: - لقد وجدت أنه خلال عمليات التحقق من التوفر ، يقوم Zabbix بإجراء فحص لما يصل إلى 128 مضيفًا في المرة الواحدة. لقد حاولت زيادة هذا الرقم إلى 500 وأزلت الفاصل بين الرزم في ping (ping) - مما أدى إلى زيادة الأداء بعامل اثنين. ولكن أود الحصول على أرقام كبيرة.

MCH: - في ممارستي ، أضطر أحيانًا إلى التحقق من توفر الآلاف من المضيفين ، ولم أر أي شيء أسرع من nmap. أنا متأكد من أن هذه هي الطريقة الأسرع. فلنجربها! تحتاج إلى زيادة عدد المضيفين بشكل كبير في تكرار واحد.

م: - تحقق أكثر من خمسمائة؟ 600؟

صحة الأم والطفل: - على الأقل بضعة آلاف.

مم:- حسنا. أهم شيء أردت أن أقوله: وجدت أن معظم الاستطلاعات في Zabbix تم بشكل متزامن. يجب أن نعيدها بشكل غير متزامن. بعد ذلك يمكننا زيادة عدد المقاييس التي جمعها المستطلعون بشكل كبير ، خاصة إذا قمنا بزيادة عدد المقاييس في تكرار واحد.

MCH: - عظيم! وعندما؟

م: - كالعادة أمس.

MCH: - قارنا بين نسختي fping و nmap:



على عدد كبير من المضيفين ، كان من المتوقع أن تكون nmap أكثر كفاءة بما يصل إلى خمسة أضعاف. نظرًا لأن nmap يتحقق فقط من حقيقة مدى التوفر ووقت الاستجابة ، فقد قمنا بتحويل حساب الخسارة إلى مشغلات وقمنا بتقليل فترات التحقق من التوفر بشكل كبير. وجدنا العدد الأمثل لمضيفات nmap في منطقة 4 آلاف لكل تكرار. سمح لنا Nmap بتقليل تكاليف وحدة المعالجة المركزية لفحص التوفر ثلاث مرات وتقليل الفاصل الزمني من 120 ثانية إلى 10.

تحسين الاقتراع


م: - ثم ذهبنا للناخبين. كنا مهتمين بشكل رئيسي بإزالة SNMP والوكلاء. في Zabbix ، تم إجراء الاقتراع بشكل متزامن واتخذت تدابير خاصة من أجل زيادة كفاءة النظام. في الوضع المتزامن ، يؤدي عدم توفر المضيف إلى تدهور كبير في الاستقصاء. هناك نظام كامل من الدول ، وهناك عمليات خاصة - ما يسمى بجهات الاستطلاع التي لا يمكن الوصول إليها ، والتي تعمل فقط مع المضيفين الذين يتعذر الوصول إليهم:



هذا تعليق يوضح مصفوفة الحالة ، وتعقيد النظام الانتقالي المطلوب حتى يظل النظام فعالًا. بالإضافة إلى ذلك ، فإن الاستقصاء المتزامن نفسه بطيء إلى حد ما:



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



بالإضافة إلى ذلك ، قمنا بتعديل وتحسين نظام الاقتراع لـ SNMP- الاستفسارات. والحقيقة هي أن معظمهم لا يمكنهم الاستجابة لطلبات SNMP متعددة في نفس الوقت. لذلك ، قمنا بعمل وضع مختلط عندما يقوم استطلاع SNMP لنفس المضيف بشكل غير متزامن:



يتم ذلك لحزمة المضيف بالكامل. هذا الوضع في النهاية ليس أبطأ من التزامن غير المتزامن تمامًا ، نظرًا لأن الاستقصاء بمقدار واحد ونصف من قيم SNMP لا يزال أسرع بكثير من مهلة واحدة.

أظهرت تجاربنا أن العدد الأمثل للطلبات في تكرار واحد هو حوالي 8 آلاف مع استطلاع SNMP. في المجموع ، سمح الانتقال إلى الوضع غير المتزامن بتسريع أداء الاستطلاع بمقدار 200 مرة ، عدة مئات من المرات.

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

منذ حوالي ثلاثة أشهر

تغيير الهيكل - زيادة الحمل!


م: حسنا ، ماكس ، هل حان الوقت لتكون منتجة؟ أحتاج إلى خادم قوي ومهندس جيد.

صحة الأم والطفل: - حسنًا ، نحن نخطط. حان الوقت للخروج من الأرض عند 5000 مقياس في الثانية.

صباحًا بعد ترقية

MCH: - ميشا ، قمنا بتحديثها ، ولكن تراجعنا في الصباح ... خمن السرعة التي حققتها؟

م.م: - ألف 20 كحد أقصى.

MCH: - نعم ، 25! للأسف ، نحن من حيث بدأنا.

م: - وهكذا؟ هل حصلت على أي تشخيصات؟

MCH: - نعم بالطبع! هنا ، على سبيل المثال ، قمة مثيرة للاهتمام:



MM: - دعنا نرى. أرى أننا جربنا عددًا كبيرًا من سلاسل الاقتراع:



ولكن في الوقت نفسه لم نتمكن من استخدام النظام حتى منتصف الطريق:



والأداء العام صغير جدًا ، حوالي 4 آلاف مقياس في الثانية:



هل هناك شيء آخر؟

صحة الأم والطفل: - نعم ، ركود أحد المستطلعين:



م.م: - من الواضح هنا أن عملية الاقتراع تنتظر "الإشارات". هذه أقفال:



MCH: - ليس واضحا.

م.م: - انظر ، هذا يشبه الموقف حيث تحاول مجموعة من الخيوط العمل مع الموارد التي لا يمكن إلا لواحد العمل معها في كل مرة. ثم كل ما يمكنهم فعله هو مشاركة هذا المورد مع الوقت:



والإنتاجية الإجمالية للعمل مع مثل هذا المورد محدودة بسرعة جوهر واحد: هناك



طريقتان لحل هذه المشكلة.

ترقية مكواة الآلة ، التبديل إلى حبات أسرع:



أو قم بتغيير الهيكل ، وفي نفس الوقت الحمل:



MCH: - بالمناسبة ، دعنا نضع عدد أقل من النوى على آلة اختبار مقارنة بالآلة القتالية ، لكن معدل تواترها 1.5 مرة أسرع لكل قلب!

م: - هل هذا واضح؟ من الضروري إلقاء نظرة على رمز الخادم.

مسار البيانات في خادم Zabbix


MCH: - لفهم ، بدأنا في تحليل كيفية نقل البيانات داخل خادم Zabbix:



صورة رائعة ، أليس كذلك؟ دعنا نذهب خطوة بخطوة لتوضيح أكثر أو أقل. هناك تدفقات وخدمات مسؤولة عن جمع البيانات:



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



مدير المعالج المسبق "بنقل البيانات إلى عمالها الذين ينفذون تعليمات المعالجة المسبقة ويعيدونها عبر نفس المقبس:



بعد ذلك ، المعالج المسبق -المدير يحفظهم في ذاكرة التخزين المؤقت للتاريخ:



من هناك ، يتم التقاطها من قبل الغطاسون الذين يقومون بأداء الكثير من الوظائف: على سبيل المثال ، حساب المشغلات ، وملء ذاكرة التخزين المؤقت للقيمة ، والأهم من ذلك ، حفظ المقاييس في متجر المحفوظات. بشكل عام ، العملية معقدة ومربكة للغاية.



م.م: - أول ما رأيناه هو أن معظم سلاسل الرسائل تتنافس على ما يسمى بـ "ذاكرة التخزين المؤقت للتهيئة" (منطقة ذاكرة يتم فيها تخزين جميع تكوينات الخادم). على وجه الخصوص ، يتم إجراء الكثير من عمليات الإقفال من خلال التدفقات المسؤولة عن جمع البيانات:



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



يجب ألا يتعارض القائمون بالتصويت




لذلك ، كان أول شيء فعلناه هو تقسيم قائمة الانتظار إلى 4 أجزاء والسماح للمستطلعين بحظر هذه الطوابير بأمان ، وهذه الأجزاء في نفس الوقت:



أزال هذا التنافس على ذاكرة التخزين المؤقت للتكوين ، وزادت سرعة المستطلعين بشكل ملحوظ. ولكننا واجهنا بعد ذلك حقيقة أن مدير المعالجة الأولية بدأ في تجميع قائمة انتظار للوظائف:



يجب أن يكون مدير المعالج المسبق قادرًا على تحديد الأولويات


حدث هذا عندما كان يفتقر إلى الإنتاجية. : ثم كل ما يمكن القيام به هو لطلبات تتراكم من عمليات جمع البيانات وإضافة عازلة لحين انه يلتهم كل ذكرى وتحطم



، واضاف نحن لحل هذه المشكلة مأخذ الثاني الذي خصص تحديدا للعمال:



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



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



نقوم بزيادة عدد المقابس - نحصل على النتيجة


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



لذلك ، قمنا بعمل أربع ، بأربع مجموعات من المقابس ، العمال:



وهذا سمح لنا بزيادة السرعة إلى حوالي 130 ألف متر:



يتم تفسير عدم خطية النمو من خلال حقيقة وجود منافسة على ذاكرة التخزين المؤقت قصص. بالنسبة له ، تنافس 4 من مديري ما قبل المعالجة والمعالجات التاريخية. في هذه المرحلة ، تلقينا حوالي 130 ألف مقياس في الثانية على جهاز اختبار ، نستخدمه بنسبة 95٪ تقريبًا على المعالج:



منذ حوالي 2.5 شهرًا

أدى رفض مجتمع snmp إلى زيادة NVPs بمقدار مرة ونصف


م: - ماكس ، أحتاج إلى آلة اختبار جديدة! لم نعد ننسجم مع التيار.

MCH: - وما هو الآن؟

MM: - الآن - NVPs 130 كيلو ومعالج "الرف".

MCH: - واو! رائع! انتظر لدي سؤالان. وفقًا لحساباتي ، فإن حاجتنا في حدود 15-20 ألف متر في الثانية. لماذا نحتاج المزيد؟

م.م: - أريد إنهاء المهمة حتى النهاية. أريد أن أرى كم يمكننا أن نخرج من هذا النظام.

MCH: - لكن ...

MM: - لكنها غير مجدية للأعمال.

MCH: - فهمت. والسؤال الثاني: ماذا لدينا الآن ، هل يمكننا دعم أنفسنا ، دون مساعدة مطور؟

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

MCH: - فأنت بحاجة إلى نوع من البديل.

م.م: - هناك مثل هذا الخيار. يمكننا التحول إلى النوى السريعة ، مع التخلي عن نظام القفل الجديد. ما زلنا نحصل على أداء 60-80 ألف متر. في هذه الحالة ، يمكننا ترك باقي الكود. Clickhouse ، ستعمل الاستطلاع غير المتزامن. وسيكون من السهل الحفاظ عليها.

MCH: - عظيم! أقترح أن أسهب في الحديث عن هذا.

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



على سبيل المثال ، سمح لنا رفض ماكرو مجتمع snmp ، والذي يوجد غالبًا في الوثائق والأمثلة ، في حالتنا بتسريع NVPs بنحو 1.5 مرة.

بعد يومين من الإنتاج

إزالة النوافذ المنبثقة لتاريخ الحادث


MCH: - ميشا ، نستخدم النظام لمدة يومين ، ويعمل كل شيء. ولكن فقط عندما يعمل كل شيء! لقد خططنا للعمل مع نقل جزء كبير بما فيه الكفاية من الشبكة ، ومرة ​​أخرى تحققنا من أنها ارتفعت ، ولم ترتفع.

م: - لا يمكن أن يكون! فحصنا كل شيء 10 مرات. يقوم الخادم بمعالجة عدم إمكانية الوصول الكامل للشبكة على الفور.

MCH: - نعم ، أفهم كل شيء: الخادم ، قاعدة البيانات ، الأعلى ، austat ، السجلات - كل شيء سريع ... لكننا ننظر إلى واجهة الويب ، وهناك معالج "على الرف" على الخادم وهذا:



MM: - فهمت. دعونا نشاهد الويب. وجدنا أنه في حالة وجود عدد كبير من الحوادث النشطة ، بدأت معظم أدوات التشغيل تعمل ببطء شديد:



كان السبب في ذلك هو إنشاء النوافذ المنبثقة التي لها تاريخ من الأحداث التي تم إنشاؤها لكل عنصر في القائمة. لذلك ، رفضنا إنشاء هذه النوافذ (علقت 5 أسطر في الكود) ، وهذا حل مشاكلنا.

تم تقليل وقت تحميل الأداة ، حتى عندما يتعذر الوصول إليها تمامًا ، من بضع دقائق إلى الوقت المقبول بالنسبة لنا من 10 إلى 15 ثانية ، ولا يزال من الممكن عرض السجل بالنقر فوق الوقت:



بعد العمل. منذ شهرين

MCH: - ميشا ، هل ستغادر؟ يجب أن نتحدث.

م: - لن. مرة أخرى شيء مع Zabbix؟

MCH: - أوه لا ، استرخ! أردت فقط أن أقول: كل شيء يعمل ، شكرًا! بيرة معي.

Zabbix فعال


Zabbix هو نظام ووظيفة متعددة الاستخدامات وغنية إلى حد ما. يمكن استخدامه للتركيبات الصغيرة خارج الصندوق ، ولكن مع نمو الاحتياجات يجب تحسينه. لتخزين أرشيف كبير من المقاييس ، استخدم التخزين المناسب:

  • يمكنك استخدام الأدوات المدمجة في شكل تكامل مع Elastixerch أو تحميل التاريخ إلى ملفات نصية (متوفرة من الإصدار الرابع) ؛
  • يمكنك الاستفادة من خبرتنا والتكامل مع Clickhouse.

لزيادة سرعة جمع المقاييس بشكل كبير ، وجمعها بشكل غير متزامن ونقلها من خلال واجهة الصياد إلى خادم Zabbix ؛ أو يمكنك استخدام التصحيح لمُصْدِر Zabbix غير المتزامن نفسه.

Zabbix مكتوب بلغة C وهو فعال للغاية. يسمح حل العديد من الأماكن المعمارية الضيقة بزيادة إنتاجيتها ، ومن واقع خبرتنا ، الحصول على أكثر من 100 ألف مقياس على جهاز معالج واحد.



نفس التصحيح Zabbix


م.م: - أريد إضافة نقطتين. يتم إعطاء التقرير الحالي بأكمله ، جميع الاختبارات والأرقام للتكوين المستخدم معنا. نأخذ الآن حوالي 20 ألف مقياس في الثانية منه. إذا كنت تحاول فهم ما إذا كان هذا سيعمل معك - يمكنك المقارنة. ما تحدثوا عنه اليوم تم نشره على GitHub على شكل رقعة: github.com/miklert/zabbix



يتضمن التصحيح:

  • التكامل التام مع Clickhouse (خادم Zabbix والواجهة الأمامية) ؛
  • حل المشاكل مع مدير المعالج المسبق ؛
  • اقتراع غير متزامن.

التصحيح متوافق مع جميع الإصدار 4 ، بما في ذلك lts. على الأرجح ، مع الحد الأدنى من التغييرات ، سيعمل على الإصدار 3.4.

شكرا للانتباه.

الأسئلة


سؤال من الجمهور (فيما يلي - أ): - مساء الخير! من فضلك قل لي ، هل لديك خطط للتفاعل المكثف مع فريق Zabbix أم لديهم معك حتى لا يكون هذا تصحيحًا ، ولكن السلوك الطبيعي لـ Zabbix؟

م.م: - نعم ، بالتأكيد سنلتزم بجزء من التغييرات. سيكون هناك شيء ، سيبقى شيء في الرقعة.

ج: - شكرا جزيلا على التقرير الممتاز! أخبرني ، من فضلك ، بعد تطبيق التصحيح ، سيظل الدعم من جانب Zabbix وكيفية الاستمرار في الترقية إلى إصدارات أعلى؟ هل سيكون من الممكن تحديث Zabbix بعد التصحيح الخاص بك إلى 4.2 ، 5.0؟

مم:- لا استطيع ان اقول عن الدعم. إذا كنت دعم Zabbix الفني ، لربما سأقول لا ، لأن هذا هو رمز شخص آخر. أما بالنسبة لقاعدة الكود 4.2 ، فإن موقفنا هو: "سنذهب مع الوقت ، وسيتم تحديثنا في الإصدار التالي". لذلك ، لبعض الوقت سنقوم بتحميل التصحيح إلى الإصدارات المحدثة. سبق أن قلت في التقرير: إن عدد التغييرات مع الإصدارات لا يزال صغيرًا جدًا. أعتقد أن الانتقال من 3.4 إلى 4 استغرقنا ، على ما يبدو ، حوالي 15 دقيقة. لقد تغير شيء ما هناك ، ولكن ليس مهمًا جدًا.

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

م.م: - نوصي بشدة. هذا يحل الكثير من المشاكل بالنسبة لنا.

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

م.م: - إذا كانت التفاصيل مثيرة للاهتمام ، فإن "Clickhouse" يستخدم ما يسمى بمكتبة التاريخ. إنه غير مقيد - هذه نسخة من دعم مرونة ، أي أنه قابل للتكوين. الاستقصاء يغير فقط من المصوتين. نعتقد أن هذا سيعمل لفترة طويلة.

ج: - شكرا جزيلا. ولكن أخبرني ، هل هناك أي توثيق للتغييرات التي تم إجراؤها؟



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

حول استبدال fping بـ nmap


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

MM:- رائع. سؤال صحيح جدا! هذه هي النقطة. قمنا بتعديل المكتبة (ICMP ping ، جزء من Zabbix) لفحوصات ICMP ، والتي تشير إلى عدد الحزم - الوحدة (1) ، ويحاول الرمز استخدام nmap. أي أن هذا هو العمل الداخلي لـ Zabbix ، فقد أصبح العمل الداخلي لل Pinger. وبناء على ذلك ، لا يلزم تزامن أو استخدام الصياد. وقد تم ذلك عن عمد من أجل ترك النظام متماسكًا وعدم الانخراط في مزامنة نظامين أساسيين: ما يجب التحقق منه ، وملئه من خلال وحدة التخزين ، وإذا كان التعبئة قد اخترق فينا؟ .. هذا أبسط بكثير.

ج: - هل يعمل لوكيل أيضا؟

م.م: - نعم ، لكننا لم نتحقق. رمز الاقتراع هو نفسه في كل من Zabbix والخادم. يجب أن تعمل. أؤكد مرة أخرى: أداء النظام بحيث لا نحتاج إلى وكيل.

صحة الأم والطفل: - الإجابة الصحيحة على السؤال هي: "لماذا تحتاج إلى وكيل بمثل هذا النظام؟" فقط بسبب NAT'a أو للمراقبة من خلال قناة بطيئة بعض ...

ج: - وأنت تستخدم Zabbix كمسبب للحساسية ، إذا فهمت بشكل صحيح. أو الرسومات (أين طبقة الأرشيف) التي تركتها لنظام آخر ، مثل Grafana؟ أم أنك لا تستخدم هذه الوظيفة؟

م.م: - سوف أؤكد مرة أخرى: لقد حققنا التكامل التام. نصب التاريخ في "Clickhouse" ، ولكن في نفس الوقت غير واجهة أمامية php. يذهب PHP-Frontend إلى "Clickhouse" ويقوم بكل الرسومات من هناك. في الوقت نفسه ، لنكون صادقين ، لدينا جزء يبني من نفس "Clickhouse" ، من نفس بيانات Zabbix ، البيانات في أنظمة عرض الرسوم البيانية الأخرى.

صحة الأم والطفل: - في "جرافان" كذلك.

كيف تم اتخاذ قرار تخصيص الموارد؟


ج: - شارك القليل من المطبخ الداخلي. كيف تم اتخاذ القرار بضرورة تخصيص الموارد لمعالجة المنتجات الجادة؟ هذه ، بشكل عام ، بعض المخاطر. وأرجو أن تخبرني ، في سياق حقيقة أنك ستدعم الإصدارات الجديدة: كيف يتم تبرير هذا القرار من وجهة نظر الإدارة؟

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

  • شارك المرء في إطلاق نظام مراقبة باستخدام طرق جديدة: المراقبة كخدمة ، مجموعة قياسية من الحلول مفتوحة المصدر التي نجمعها ثم نحاول تغيير عملية الأعمال من أجل العمل مع نظام المراقبة الجديد.
  • في موازاة ذلك ، كان لدينا مبرمج متحمس يقوم بهذا (عن نفسه). حدث ذلك أنه فاز.

ج: - وما هو حجم الفريق؟

MCH: - إنها أمامك.

ج: - كالعادة هناك حاجة إلى عاطفي؟

م: - أنا لا أعرف ما هو عاطفي.

ج: - في هذه الحالة ، يبدو أنك. شكرا جزيلا ، أنت رائع.

م: - شكرا لك.

حول بقع Zabbix


ج: - بالنسبة للنظام الذي يستخدم الوكلاء (على سبيل المثال ، في بعض الأنظمة الموزعة) ، هل من الممكن أن يتخذ قرارك للتكيف والتصحيح ، على سبيل المثال ، المستطلعين والوكلاء ومعالج Zabbix نفسه جزئيًا ؛ وتفاعلهم؟ هل من الممكن تحسين التطورات الحالية لنظام متعدد الوكلاء؟

م.م: - أعلم أن خادم Zabbix يتم تجميعه باستخدام وكيل (يتم تجميعه والحصول على الرمز). لم نختبر هذا في المنتج. لست متأكدًا من ذلك ، ولكن في رأيي ، لا يتم استخدام مدير المعالج الأولي في الوكيل. تتمثل مهمة الوكيل في أخذ مجموعة من المقاييس من Zabbix ، وملئها (كما يكتب التكوين وقاعدة البيانات المحلية) وإعادتها إلى خادم Zabbix. ثم يقوم الخادم نفسه بإجراء المعالجة المسبقة عندما يستلمها.

الاهتمام بالوكيل أمر مفهوم. سوف نتحقق من ذلك. أنه موضوع شيق.

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

م.م: - أعتقد أن كل شيء أبسط. تأخذ الشفرة ، وتطبق التصحيح ، ثم تهيئته حسب حاجتك - اجمع خوادم الوكيل (على سبيل المثال ، مع ODBC) ووزع الشفرة المصححة على الأنظمة. عند الضرورة - جمع الوكلاء ، عند الضرورة - الخادم.

ج: بالإضافة إلى ذلك ، لن تضطر إلى تصحيح إرسال الخادم الوكيل إلى الخادم ، على الأرجح؟

MCH: - لا ، إنه قياسي.

مم:- في الواقع ، لم تكن إحدى الأفكار سليمة. لقد حافظنا دائمًا على التوازن بين انفجار الأفكار وعدد التغييرات وسهولة الدعم.


القليل من الدعاية :)


أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك ، VPS السحابي للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles