Zabbix هو نظام مراقبة مفتوح شعبي يستخدمه عدد كبير من الشركات. سأتحدث عن تجربة إنشاء مجموعة مراقبة.
في التقرير ، سأذكر بإيجاز التغييرات التي تم إجراؤها مسبقًا (التصحيحات) ، والتي تعمل على توسيع إمكانات النظام بشكل كبير وإعداد الأساس للمجموعة (تحميل السجل إلى "Clickhouse" ، الاستقصاء غير المتزامن). وسأبحث بالتفصيل المشكلات التي نشأت أثناء تجميع النظام - حل تعارضات الهوية في قاعدة البيانات ، قليلاً عن نظرية CAP والمراقبة مع قواعد البيانات الموزعة ، حول الفروق الدقيقة في Zabbix التي تعمل في وضع نظام المجموعة: النسخ الاحتياطي وتنسيق الخوادم والوكلاء ، حول "مجالات المراقبة" ونظرة جديدة على بنية النظام.
سأتحدث باختصار عن كيفية بدء تشغيل مجموعة في المنزل ، وأين يمكن الحصول على المصادر ، وما هي المصادر الإضافية. سوف تكون هناك حاجة الإعدادات للكتلة.
HighLoad ++ سيبيريا 2019. قاعة تومسك. 24 يونيو ، الساعة 5 مساءً الملخصات
والعرض التقديمي . سيعقد مؤتمر HighLoad ++ التالي في 6 و 7 أبريل 2020 في سان بطرسبرغ. التفاصيل والتذاكر
هنا .
ميخائيلي ماكوروف (المشار إليه فيما يلي - MM): - أنا أعمل في شركة موفر. يسمى الموفر Intersvyaz ، وهو يعمل في مدينة تشيليابينسك. لدينا حوالي 1.5 مليون شخص. ولكي يعمل المزود ، هناك بنية تحتية ضخمة. لدينا حوالي 70 ألف قطعة من المعدات: المحولات وأجهزة IoT ... - الكثير من كل شيء يحتاج إلى مراقبته. على وجه التحديد ، يتعلق هذا التقرير باستخدام Zabbix ، حول بناء كتلة قائمة على Zabbix لمراقبة البنية التحتية.
عمري 12 سنة في المزود. الآن لا أفعل أشياء فنية على الإطلاق ، إنها تتعلق بإدارة الأشخاص. وهذه (الأشياء التقنية) هي في الحقيقة هوايتي. سوف أطور هذا الموضوع قليلاً.
رصد القضايا
أعتقد أنني محظوظ. منذ حوالي عام ونصف ، انتهى بي الأمر في مشروع بدا كالتالي: "نحن بحاجة إلى حل بعض المشكلات المتعلقة بمراقبتنا". لقد ورثت منطقة مسؤولية (مراقبة) ، تتكون من مجموعة من الخوادم ، وتحديداً 21 خادمًا:
كان هناك 4 خوادم قوية و 15 وكيل - كان كل الأجهزة. كانت هناك بعض الشكاوى حول هذا الرصد. الأول هو أنه كان كثيرًا. ليس لدينا خادم واحد مع مزود استغرق مساحة كبيرة. هذا هو المال والكهرباء ... في الواقع ، هذه ليست مشكلة كبيرة.
كانت المشكلة الكبيرة هي أن المراقبة لم تواكب ما أردناه منه. بالنسبة لأولئك الذين لم يستخدموا Zabbix بشكل نشط ، فهذه لوحة معلومات تظهر تأخرًا في عمليات الفحص:
وكانت معظم الشيكات لدينا في المنطقة الحمراء. ركضوا أكثر من 10 دقائق أبطأ مما كنا نريد ، أي أنهم تأخروا 10 دقائق. لم يكن ذلك ممتعًا للغاية ، لكن كان لا يزال من الممكن العيش أكثر أو أقل. المشكلة الأكبر كانت هذه:
كان نظام مراقبة لشبكة العمل. عندما تم تنفيذ العمل المخطط له ، سقط جزء من الآلاف على خمسة مفاتيح. جنبا إلى جنب مع هذه المفاتيح ، ذهب المفتاح والرصد إلى النسيان. عندما تم استعادة كل شيء ، بعد ساعتين واستعادة المراقبة. كانت غير مؤلمة ، وهذه العبارة يجب أن تكون في كل تقرير:
"يجب علينا أن نفعل شيئا مع هذا المشروع!"
وهنا سأحكي قصتين. ثم حاولنا الذهاب في وقت واحد بطريقتين. لدينا مجموعة تكامل - اختارت طريقة بناء نظام معياري (كان هناك تقرير رائع جدًا من Avito إلى Highload في نوفمبر من العام الماضي في موسكو - تحدثوا عن هذا حول):
Zabbix = الناس + API + الكفاءة
بدأ الرجال من القطع الصغيرة في بناء النظام. ومع العديد من المتحمسين ، واصلت العمل على Zabbix. كانت هناك أسباب لذلك. ما هي الاسباب؟
- أولاً ، هناك واجهة برمجة تطبيقات رائعة. وعندما يكون لديك 60 إلى 70 ألف عنصر مراقبة ، فمن الواضح أن كل هذا يعمل تلقائيًا فقط - لا يمكنك إضافة العديد من الأيدي دون أخطاء.
- الإطارات. هناك نوبات مراقبة أثناء العمل تجلس على مدار الساعة طوال أيام الأسبوع. هؤلاء ليسوا متخصصين في تكنولوجيا المعلومات ، فهؤلاء هم أشخاص في الخدمة. لقد أظهرنا لـ "غرافان" بعض الأنظمة الأخرى - إنه أمر صعب بالنسبة لهم. هناك مدراء اعتادوا على التنوع ، وراحة المراقبة في Zabbix نفسها: القوالب ، والاكتشاف التلقائي - وهذا كل شيء رائع!
- Zabbix يمكن أن تكون فعالة.
هل قاعدة بيانات SQL تبطئ؟ إجابة واحدة - Clickhouse
السبب الأول كان واضحًا. ثم عملنا على MySQL ، وواجهنا حوالي 6-7 آلاف مقاييس في الثانية ، وشهدنا تأخيرًا ثابتًا على الأقراص.
اليوم بدا بالفعل 100 مرة: الجواب الوحيد هو Clickhouse:
في بنية الاستعلامات ، يمثل الجزء الأكبر من الاستعلامات (التنميط الخاص بنا في غضون ساعات قليلة) سجلات مقاييس. كتابة مقاييس إلى قاعدة بيانات SQL مكلفة للغاية. هنا ظهر TimeScaleDB ... ثم كان لدينا "Clickhouse" قيد التشغيل لمدة عام تقريبًا للقيام بمهام أخرى (نقوم ببيانات كبيرة ، لدينا تطبيق كبير - بشكل عام ، أصبح المزود الآن شركة تكنولوجيا معلومات كاملة).
بعد النظر في الرسوم البيانية الجميلة من الإنترنت (أن "Clickhouse" أسرع بمئات المرات ، وأنها تحتاج إلى مساحة صغيرة جدًا) ولديها تجربة حالية ، كتبنا وحدة HistoryStorage الخاصة بنا من أجل "Zabbix" بحيث يمكنها حفظ بيانات "Clickhouse" مباشرةً (أي ، ليس من تصدير الملف ، ولكن مباشرة على الطاير).
علاوة على ذلك ، كتبنا وحدة ل "الجبهة". يمكن بناء كل هذه الرسومات الجميلة في لوحة إدارة Zabbix من Clickhouse. من الواضح أن واجهة برمجة التطبيقات تعمل أيضًا.
التأثير هو نفسه تقريبا - خادم SQL ككيان مخصص لم يصبح تماما ، وهذا هو ، انخفض الحمل إلى الصفر. الأمر الأكثر بروزًا هو أنه كان لدينا بالفعل مجموعة مخصصة من "Clickhouse": عندما قدمنا كل حملاتنا هناك ، زاد من 6 إلى 10 آلاف مقاييس. قال الرجال الذين يديرون الشركة: "لكننا لا نرى شيئًا ما قد حدث. لا! "
كيف قمنا بتوسيع Clickhouse
سأقول أكثر من ذلك: بالنسبة للاختبارات ، حاولنا تحميل ما يصل إلى 140-150 ألف قياسات في الثانية (لم يعد بإمكاننا الضغط من Zabbix ، وسأقول لاحقًا السبب) ، ولن ترى Clickhouse هذا الحمل أيضًا. وهذا هو ، مريح جدا ، تحميل بارد. بشكل عام ، هناك مثل هذه الوحدة.
بالإضافة إلى ذلك ، قمنا بتوسيعه قليلاً:
في إصدارنا ، يمكنك إيقاف تشغيل النانوثانية. ربما تعرف: Zabbix يكتب ثواني والثانية في مجالين. في حقول "Clickhouse" التي يكون التباين فيها كبيرًا جدًا ، تشغل مساحة كبيرة.
بالمناسبة ، عن المكان. يستغرق قياس واحد في Clickhouse (لدينا الآن حوالي 700 مليار مقاييس مسجلة) 2.9 بايت. وفقًا لوثائق Zabbix ، يستغرق قياس واحد في قواعد بيانات SQL من 40 إلى 100 بايت. يؤدي إيقاف تشغيل النانوثانية إلى توفير 40٪ أخرى ، أي حوالي 1.5 بايت لكل متر. وهذا هو ، "Clickhouse" فعالة جدا من حيث الموقع.
بناءً على طلب من رجالنا الذين يشاركون في التعلم الآلي ، اتخذنا خيارًا حتى نتمكن من كتابة المضيف واسم المقياس. نظرًا لأن تباين البيانات كبير ، لا يستغرق هذا مساحة كبيرة ، على الرغم من أن البيانات النصية يمكن أن تكون كبيرة (لم يتم التحقق منها باختبارات طويلة حتى الآن).
بالإضافة إلى ذلك ، قمنا بإضافتين ، نظرًا لأننا قمنا بتطوير Zabbix وغالبًا ما كان يتعين علينا سحبه. إضافة رائعة جدًا: في البداية ، نظرًا لأن "Clickhouse" يتيح لك قراءة ملايين السجلات ، يمكننا ملء ذاكرة التخزين المؤقت للمحفوظات. في البداية ، يتم تأخيرنا لمدة 30-40 ثانية إضافية ، لكننا نحصل على خدمة يتم إطلاقها على الفور مع ذاكرة تخزين مؤقت مُسخنة.
في الحالات التي يكون فيها من السهل جمعها من البنية التحتية ، لا يزال هناك مثل هذا الخيار: حظر القراءة من ذاكرة التخزين المؤقت لبعض الوقت. من الأفضل أن تعمل بسرعة لمدة 5 دقائق ، دون حساب المشغلات ، وبعد ذلك سوف تملأ ذاكرة التخزين المؤقت - إذا لم تقم بذلك ، فإن الركود في غطاسات التاريخ يبدأ.
بشكل عام ، هناك وحدة "Clickhouse". يمكن استخدامه.
كفاءة الاقتراع
على الرغم من حقيقة أننا قمنا بعد ذلك بحل المشكلات المتعلقة بالقاعدة ، لا تزال الفرامل والمشكلة مع خمسة عشر وكيلًا. كانوا متصلين بهذا:
هذا هو خط أنابيب معالجة البيانات الرئيسي في Zabbix. هناك مرحلة من جمع البيانات ، وهناك معالجة مسبقة ، وهناك مزامنات تاريخية تقوم بجميع الأعمال (حساب المشغلات ، والتنبيهات ، وحفظ السجل). تبين أن عنق الزجاجة في ذاكرة التخزين المؤقت هو:
لماذا الاقتراع بطيء؟ لأن مؤشرات الترابط التي تجعل الطلبات تذهب إلى قائمة الانتظار في تكوين ذاكرة التخزين المؤقت لمقاييس الوحدة وحظرها. هناك أماكن أخرى ، لكنها ليست ضيقة للغاية. على سبيل المثال ، هناك معالجة مسبقة لنفسه وهناك ذاكرة التخزين المؤقت للتاريخ. في SQL ، حصلنا على القيود التالية:
ربما يرجع هذا إلى حقيقة أنه في حالتنا ، تبلغ القاعدة حوالي 5 ملايين مقاييس ، والتي نزيلها. مع كل التحسينات التي أجريناها ، تمكنا من الحصول على 70 ألف مقاييس في عنق الزجاجة (على ذاكرة التخزين المؤقت للتكوين) ، ولكن فقط في الحالة عندما عالجناها بكميات كبيرة.
ما هي المعالجة بالجملة؟ يذهب Poller إلى Configuration Cache ويأخذ المهمة ليس لمقياس واحد ، ولكن لمدة 4 أو 8 آلاف. في الوقت نفسه ، يحصل على فرصة رائعة أخرى: يمكنه الآن إجراء الاقتراع بشكل غير متزامن ، لأنه حصل على 4 آلاف مقاييس ... لماذا يفعلون واحد تلو الآخر؟ يمكنك أن تسأل على الفور كل شيء!
الاقتراع غير المتزامن أكثر فعالية من الوكيل!
بالنسبة للأنواع الرئيسية التي يستخدمها الموفر - هذه هي SNMP و AGENT ، نعيد كتابة الاستقصاء إلى الوضع غير المتزامن ، وقد أدى هذا بشكل إجمالي إلى زيادة السرعة من 100 إلى 200 مرة. كان لدينا 15 وكيلًا ، وقسمناها إلى 150 وكيلًا - لقد اختفوا تمامًا. ونتيجة لذلك ، تحولت جميعها إلى بنكين ، وهما ضروريان فقط للاحتياطي:
البنك أحادي المعالج (تكاليف زيون واحدة 1280). هذا هو الوقت dle:
حوالي 60٪ مجانية ، لكن هذه الرنين من 60٪ إلى 40٪ يتم تشغيل برامج نصية دورية على الجهاز نفسه (البرامج النصية الخارجية). يمكن تحسينها حتى يتم إنشاء المشكلات.
المقياس شيء مثل هذا:
هذه 62 ألف مضيفة ، حوالي 5 ملايين مقاييس. احتياجاتنا الحالية حوالي 20 ألف مقاييس في الثانية.
حسنا ، مثل كل شيء؟ لقد حللنا مشاكل الأداء ، وسّعنا التاريخ ، والاقتراع رائع. هل تم حل المشكلة؟ ليس حقا ... كل شيء سيكون بسيطا جدا.
لقد لعبت خدعة على الرسم البياني السابق (لم تظهر جميعًا):
هناك مشكلتان. أريد أن أقول: "الحمقى ، الطرق". هناك عامل بشري ، هناك معدات.
خادم واحد لا يزال غير كاف. في حوالي عام من التشغيل ، كانت هناك حالتان مع مشاكل في الأجهزة - محرك أقراص SSD وشيء آخر. معظم المشاكل هي العامل البشري عندما يقوم الناس بنوع من الاختبارات. في شركتنا ، يتم استخدام Zabbix كخدمة: يمكن لجميع الإدارات كتابة شيء خاص بها هناك.
أود التوسع. أود أن لا تعتمد على علبة واحدة. أردت أن نكون قادرين على التمسك بقوة أكبر. وأود أن توسيع نطاق وفقا لمبدأ التدريج. لا يوجد شيء يمكن مناقشته: النمو ، زيادة قدرة الفرد ، لمدة 20 عامًا لم تكن ذات صلة.
الكتلة المطلوبة ...
في مكان ما في ديسمبر ، ظهرت النسخة الأولى. وحدة الكتلة الذرية هي ما تتم معالجته على مضيف منفصل. تم اختيار المضيف.
الحقيقة هي أنه في Zabbix توجد روابط قوية إلى حد ما بين العناصر التي يمكن أن تكون على نفس المضيف ، أي أنه يمكن توصيل المشغلات ، ويمكن معالجتها معًا في المعالجة المسبقة. ولكن بين المضيفين ، فإن الاتصال ليس عاليًا جدًا ، لذلك من الطبيعي استخدام هذه الكتلة بين عقد الكتلة - سيكون هناك الكثير من الحركة هناك. تتمثل المهمة الرئيسية للمجموعات في الاتفاق فيما بينها على من يشارك فيما يستضيفه.
أود أن أتجاوز الحد الأقصى المسموح به وهو 60-70 ألف مقاييس ، لأن الشهية تأتي مع تناول الطعام. لدينا رجال يشاركون في جودة التجربة ... جودة الخبرة - تحليل لكيفية عمل الإنترنت للمشتركين بناءً على مقاييس النقل ، أي أنك توفر جميع مقاييس TCP لـ 1.5 مليون شخص ، وتصب في المراقبة - هناك الكثير من البيانات.
وأردت الموثوقية. أردت ذلك إذا حدث شيء ما ... قال ضابط المناوبة ، "لدينا مشاكل مع الخادم" ، وأطفئه ، وسنكتشف ذلك غدًا.
المجموعة الأولى
تم تنفيذ الإصدار الأول على أساس etcd:
Etcd عبارة عن وحدة تخزين ذات قيمة توزيع موزعة تستخدم في العديد من المشاريع التقدمية (حسب علمي ، في Kubernetes). كل شيء كان رائعا. يوفر Etcd أدوات مهمة للغاية - على سبيل المثال ، يحل مشكلة اختيار الخادم الرئيسي. لكن هذه المشكلة ...
كان لدينا رابط ثلاثي كلاسيكي "Zabbix": "الويب" - القاعدة - الخادم نفسه. وأضفنا "Clickhouse" هناك ، والآن أضفنا etcd أيضًا. بدأ المسؤولون يخدشون خلف رؤوسهم: هناك الكثير من التبعيات هنا - ربما لن تكون موثوقة. في عملية التطوير ، أصبح هناك شيء آخر واضح: في Zabbix نفسها هناك بالفعل طريقة مضمنة للاتصال بين الخوادم ، يتم استخدامها فقط بين الخادم والوكيل ، ما يسمى بعملية استقصاء الوكيل الوكيل:
إنه أمر رائع جدًا بالنسبة للاتصال بين أجهزة الخادم مع الحد الأدنى من التغييرات. هذا ما سمح لغيره (على الأقل مؤقتًا) ، وتبسيط الكود إلى حد كبير ، والأهم من ذلك ، العمل على الكود الذي تم التحقق منه (يبدو أن هذا الكود عمره 5 أو 7 سنوات).
كيف يتم تنسيق الخوادم في كتلة؟
يتم التنسيق حسب النوع ، مثل بروتوكول IGP. من أجل إعطاء الأولوية للخوادم (سأقول الآن لماذا هذا ضروري) ولتجنب التعارضات في قاعدة بيانات SQL عند كتابة السجلات ، يتم تعيين معرف لكل خادم (يدويًا حتى الآن) - هذا رقم من 0 إلى 63 (63 - إنه مجرد ثابت ، وربما أكثر):
يصبح الخادم ذو المعرف الأقصى هو "الرئيسي". عندما أطلقنا مجموعات الاختبار الأولى ، كان أول ما قاله مسؤولونا هو: "واو! ودعونا نضعها في مواقع مختلفة. حسنًا ، عظيم! "(سنعود إلى هذا). وعندما يقوم شخص ما بتوزيع مجموعات ، سيكون من الممكن التحكم في كيفية إعادة توزيع الطوبولوجيا: أين سينتقل دور "المعلم" في حالة حدوث هبوط في خادم "Zabbix" الرئيسي:
في هذه الحالة ، مثل هذا:
خطوة
في Zabbix الأصلي ، يتم ذلك على النحو التالي: الخادم نفسه مسؤول عن إنشاء فهارس الزيادة التلقائية. لمنع العديد من الحالات من التنقل على أعقاب بعضها البعض (حتى لا يتم إنشاء سجلات بنفس الفهارس) ، يتم استخدام الخطوة: "Zabbix" مع المعرف "1" ستنشئ مضاعفات واحد - 1 ، 11 ، 21 ؛ مع المعرف "7" - 7 ، 17 ، 27 (مع الفروق الدقيقة).
سافرنا مع المعدلات.
كيف تتفاعل الخوادم مع بعضها البعض؟
هذا هو إرث حزم IGP من IGP كل 5 ثوانٍ. لذلك تعرف الخوادم أن لديهم جيران. لذلك يعرف "المعلم" أن هناك جيرانًا قريبين ، وعلى أساس ذلك ، يقرر "الرئيسي" المضيفين الذين يمكن توزيعهم على الخوادم.
وفقا لذلك ، هناك التكوين. وفقا للذاكرة القديمة ، وأنا أسميها طوبولوجيا. الطبولوجيا هي أساسًا قائمة بالخوادم والمضيفات التي تنتمي إليها.
البروتوكول بسيط - وهذا هو JSON:
هذا هو أيضا إرث وكيل Zabbix واتصالات خادم Zabbix. بشكل عام ، لا معنى لاستخدام شيء آخر. الشيء الوحيد هو أنه في حالة Zabbix هناك 4 بايت (ZBXD) ، ولكن ليست هذه هي النقطة.
في حزمة hello ، يتم إرسال معرف الخادم: عندما يرسل الخادم الحزمة ، فإنه يشير إلى معرفه وإصداره من الهيكل - بهذه الطريقة تكتشف الخوادم بسرعة أن هناك إصدارًا جديدًا من الهيكل ويتم تحديثه بسرعة كبيرة.
في الواقع ، فإن الطوبولوجيا نفسها ليست سوى شجرة ، قائمة بالخوادم. لكل خادم ، قائمة بالمضيفات التي يدعمها:
ثم تنشأ مشكلة مثيرة للاهتمام.
هناك مثل هذه العبارة السحرية - مراقبة المجالات
ما هي النقطة؟ في Zabbix الكلاسيكية ، كان كل شيء بسيطًا - موقف لا لبس فيه: تتم مراقبة هذا المضيف بواسطة هذا الوكيل ، ويعطي هذا الوكيل البيانات إلى الخادم. إذا لم يتم تثبيت الخادم الوكيل (أو لم يكن مطلوبًا) ، فسيراقب هذا الخادم جميع المضيفين:
عندما يكون لدينا العديد من الخوادم ، ماذا تفعل؟ علاوة على ذلك ، قد تكون هناك مشكلة في حقيقة أن لدينا خوادم موزعة جغرافيًا ، وسيبدأ الخادم في بعض المكاتب التي تعمل ببطء في كيميروفو في محاولة لمراقبة البنية التحتية بالكامل لنوفوسيبيرسك.
نحن لا نريد هذا. نريد أن يكون لدينا نوع من الآلية بحيث لا تستطيع جميع الخوادم ، ولكن الخوادم التي اخترناها (ربما استنادًا إلى الجغرافيا) مراقبة مضيف معين. في الوقت نفسه ، نريد إدارة هذا الأمر ، ونريد أن يكون الأمر بسيطًا. لهذا ، اخترعت فكرة مراقبة المجالات. في الواقع ، هذه مجموعات بسيطة - ببساطة توجد مجموعات بالفعل في السجل.
وعندما فعلت هذا ، تحدث معي الرجال من العملية - قالوا: "تشوشنا المجموعات كثيراً. نحن دائما نبدأ في التفكير في المجموعات العادية. " لذلك ، هذا الاسم: مراقبة المجالات.
المضيفون يرتبطون بشكل لا لبس فيه: مضيف واحد - مجال واحد:
يمكن أن يتضمن المجال المضيف أي عدد من الخوادم. يمكن أن تكون الخوادم في أي عدد من المجالات. هذا شيء مرن للغاية. من أجل توسيع المرونة وكسر الدماغ بالكامل ، يوجد أيضًا مجال افتراضي:
تتم مراقبة الخوادم التي هي أعضاء في المجال الافتراضي من قبل جميع المضيفين الذين ليس لديهم خوادم حية أو ليس لديهم مجال مراقبة.
يسمح لنا هذا فقط بربط المضيفين طبولوجيا ببعض الخوادم والتحكم في كيفية توزيع المضيفين في حالة سقوط خادم واحد:
المشكلة التالية التي واجهناها ...
الكتلة: فكر بطريقة مختلفة
عندما يكون لدينا الكثير من الخوادم ، فهناك فرص جديدة لبناء كتلة ، لبناء طوبولوجيا. هذا كلاسيكي عندما يكون لدينا نوع من الموقع المركزي وهناك مواقع بعيدة ؛ أو ، على سبيل المثال ، وكيل حيث يتم تفويض الحمل:
في حالة نظام المجموعة Zabbix ، يمكن تنفيذه بطريقتين. يمكنك الذهاب بالطريقة الكلاسيكية: ما عليك سوى مضاعفة البنية التحتية. في الوسط ، لدينا خادمان يشكلان كتلة ، ويمكنهما إعادة ترتيب المضيفين أو تحمل العبء على أنفسهم إذا سقط الجار. وفقًا لذلك ، يمكنك رفع وكلاء إضافيين على نفس الخوادم - نحصل على احتياطي مزدوج:
يمكنك استخدام "الميزات" الجديدة والقيام بذلك:
الشيء الرئيسي هو عدم الذهاب إلى موقف يقوم فيه خادم بعيد جغرافيا بمراقبة بعض البنية التحتية الكبيرة في مكان آخر. هذه مشكلة إدارية (أسميها العمل) لأنها مشكلة في التكوين.
الكتلة: انقسام الدماغ ووجهة النظر
مع المجموعة جاءت حالة أخرى مثيرة للاهتمام واجهناها:أنها تتقاطع قليلا. Split brain - يحدث ذلك عندما يكون لديك خادمان مسؤولان عن استطلاع نفس البنية التحتية. عندما انقطع اتصالنا ، بدأ نوع من الحوادث - كيف سيتصرفون؟ من الواضح أنهم سوف يتصرفون بالطريقة التي تقوم بتكوينها ويجب عليك أيضًا التفكير في هذا مسبقًا (السيناريوهات مختلفة).مشكلة وجهة نظر شيء من هذا القبيل: يمكن أن تعطي عمليات التحقق التي تعتمد على المسافة الطوبولوجية للخوادم نتائج مختلفة لنفس المضيف ، لأنها بعيدة. وهذا ينطبق على فحص سرعة الوصول. لنفترض أنك إذا قمت بقياس RTT ، فقد يكون الأمر مختلفًا.من وجهة نظر التكنولوجيا ، تم صنع وحدات الماكرو التالية:
أنها تعمل على مستوى عناصر البيانات ، على مستوى المشغلات. إنها تسمح لك بتحديد مصدر هذه البيانات وأي من الخوادم كان بادئ التشغيل. وكيفية تفسير البيانات ، ما يجب القيام به - قرر بنفسك. ولكن عندما تعرف أي خادم سجل انخفاضًا في توفره للمضيف ، فأنت تعلم ما يجب القيام به.كتلة قاعدة بيانات SQL
من الواضح ، إذا قمنا بتوزيع مجموعة من الخوادم ، فإننا نرغب في أن يكون لدى الجميع قاعدة خاصة بهم في مكان قريب. سيكون من الخطأ ربط واحد مشترك. لسوء الحظ ، أن أقول إن لدي الآن حل جاهز ... ليس لدي أي تجربة من هذا القبيل حتى الآن. سأخبرك لماذا.أولاً ، أفترض أنه إذا بدأ شخص ما في اختبار واستخدام نظام المجموعة ، يمكنك استخدام الحلول القياسية. دعنا نقول جاليرا لماي.هناك أطنان من حلول النسخ المتماثل غير المتزامن لـ PostgreSQL. في حالة Zabbix ، يعمل هذا بشكل جيد: لن تتقاطع الفهارس ، وحقيقة أن البيانات متأخرة قليلاً في السجلات وسيتم كتابتها لاحقًا ليست مشكلة. بطبيعة الحال ، يمكن تجميع "clickhouse" بشكل مسبق.لماذا لا يوجد حل جاهز؟
من بين الهيكل العام للطلبات ، يوجد جزء صغير لا يرتبط بالتاريخ:
من هذا الجزء الصغير ، الغالبية العظمى من الطلبات التي لدينا الآن هي سجلات. تشكل السجلات أساسًا ثلاثة جداول:- تسجيل بعض الأشياء (السجلات) التي حدثت للبنية التحتية. هذه هي المشاكل والأحداث وجداول استرداد الأحداث. تعطل الخادم ، تعافى الخادم - عند إطلاق النار ، كل شيء مكتوب.
- 15 في المئة هي الدولة. الحالة هي تغيير في عناصر البنية التحتية (الخادم أو المضيف قد انخفض - المشغل قد نجح - Zabbix يكتب إلى قاعدة البيانات). في الواقع ، فإنه يخزن حالته في قاعدة البيانات. من ناحية ، إنه رائع ؛ من ناحية أخرى ، لدي ما أقوله حول هذا الموضوع ...
- ترتبط بعض الطلبات بتحميل وتغيير التكوين (تحديث التكوين).
هنا هو Zabbix الكلاسيكية. تمت إضافة "Clickhouse" إليها ، وتم إخراج المقاييس من قاعدة بيانات SQL:
أولاً ، أود الانتقال إلى الخادم للتعرف على الحالة:
هذا صحيح. إذا قمت بإسقاط الخادم وفتحت مسؤول الويب خلال ساعتين ، فستظهر لك حالة المراقبة ... لن يكون ذلك صحيحًا - سيُظهر ما كان عليه قبل ساعتين! سيكون من الصواب القول: "لا أعرف ما هي حالة الشبكة الآن". إذا كان هناك شيء محدد يهمك ، فيمكنك الاطلاع على تاريخ المشاكل أو الأحداث ، ما الذي حدث بالفعل هناك.والثاني. يُطلب من السجلات نقلها إلى نظام تخزين أرخص ، حيث تشغل مساحة أقل على القرص وتنفق موارد أقل:
ثم قد تعتقد ما يجب القيام به. أريد حقًا التخلص من قاعدة بيانات SQL. أولاً ، أود إجراء حالة ، سجلات خارج قاعدة بيانات SQL. إما أنه سيتم تكرارها بسهولة (لأنه سيكون هناك عدد قليل جدًا من التغييرات) ، أو يمكن سحبه إلى "Clickhouse" (فجأة سيبدأ دعم التغيير الكامل وحذف البيانات). لنرى ...الممارسة. تركيب
الكتلة ، نظرية ، "الماء" قلت. التفاصيل. إذا قررت إنشاء مجموعة لنفسك ، فما الذي يجب عليك فعله؟
من الضروري وضع خادم "Zabbiks" الثاني (أي ، هو البرنامج الخفي "syshny"). تظهر معلمتان جديدتان للكتلة (تحدثت عنها): معرف الخادم (رقم من 1 إلى 63 ، يصبح الخادم ذو المعرف الأعلى هو "الرئيسي") واسم المضيف (مطلوب للتعريف الذاتي للخادم عند تحميله قائمة الخوادم من قاعدة البيانات).لكل خادم ، تحتاج إلى تحديد منفذ ServerIP و IP. يعد ذلك ضروريًا حتى تتمكن الخوادم من العثور على بعضها البعض ، ويجب أن تعمل حركة المرور بين عناوين IP لهذه المنافذ. لا توجد منافذ إضافية مطلوبة ، نظرًا لأن كل شيء يعمل من أجلنا من خلال أداة مسح البروكسي القياسية ، أي أن أداة الصياد القياسية تلتقط طلبات الترحيب ، ويبدأ جهاز مسح البروكسي المرور.مزيد من التغييرات الصغيرة. في المكان الذي اعتدنا فيه على التحكم بالوكيل ، ظهرت الآن لوحة "Cluster Management":
هناك عدد من الكائنات الجديدة:
أهم شيء هو الذهاب إلى هناك وإنشاء مجال افتراضي. أنا أتحدث عن الحد الأدنى من التكوين للاختبار. والثاني هو بدء تشغيل كلا الخادمين ، كتابة نفس عناوين IP والمنافذ وأسماء المضيف التي حددتها في التكوين (يجب أن تتطابق). يحتوي الخادم على حقل "مجال" جديد - حدد هذا الإعداد الافتراضي.بشكل عام ، هذا كل شيء.- بدء خادم واحد.
- انظروا إلى ما يكتبه عن المجموعة: "أنا المحارب الوحيد في الميدان ، وأنا الأهم هنا." سيبدأ الرصد.
- انتظر بعض الوقت ، ابدأ تشغيل الخادم الثاني.
- أولاً ، سوف يرون بعضهم بعضًا ، ثم سيمضي وقتًا معينًا ، ويقولون: "يمكننا العمل معًا" ؛ سوف نشارك المضيفين فيما بينهم.
- استمتع بالعمل
أعتقد أن الأمر يستحق محاذاة الخوادم ، وانظر كيف تعمل. في اختباراتنا ، يكون وقت نقص المراقبة في حالة سقوط أحد الخوادم حوالي 30-40 ثانية. يمكن تقليل هذا ، ولكن بعد ذلك ، يعاني الاتصال بين الخوادم ، خاصةً إذا كانت الشبكة غير موثوق بها ، تبدأ رنين صغير.ليس الجزء الفني
ولد كل هذا وكان من المخطط في شكل بقع لدفعه إلى الفرع الرئيسي ، ولكن لأسباب مختلفة لم يذهب. ومنذ أبريل من هذا العام ، اقترح شخص من المجتمع: "ودعونا نفعل ذلك شوكة ، مشروع منفصل!"
وهنا شيء مثير للاهتمام: هناك عدد من المتحمسين الذين يقومون بشيء ما ، أو يرون ، أو يقومون بتكوين GitLab ، CI / CD ، ويقدمون أفكارًا رائعة. هنا ، على سبيل المثال ، النانو ثانية - جاء من المجتمع.بشكل عام ، في حين أنه يعمل كمشروع منفصل ، فإنه يتم تحديثه تلقائيًا تقريبًا إلى الإصدار الحالي - إنه في الإصدار 4.0.9 (لم نأخذ 4.2). هناك خريطة طريق معينة - الآن يمكن تنزيلها بالفعل في شكل حزم دبيان. في رأيي ، هناك تجمعات لأوبونتا ؛ لا أعرف ما إذا كانت هناك دورات في الدقيقة.
قريبا سيكون هناك دعم كامل لوكلاء (هناك بعض العوائق) و "ضبط" للعرض الحالي لحالة الكتلة في لوحة "Zabbix". في تجربتنا. من المهم بالنسبة للمسؤولين معرفة أي الخادم الذي تتم معالجته من أجل البدء في البحث عن المشاكل. النظام جديد - عامل نفسي بحت: لقد أنشأنا مجموعة ، شيء ما يعمل بشكل خاطئ ... على من يقع اللوم؟ الكتلة! .. لذلك ، تحتاج إلى "ضبط" ، تحتاج إلى فهم.حتى نهاية الصيف ، أود أن أسحب من قاعدة بيانات SQL جميع تدفقات المعلومات غير المطلوبة هناك ، لا يجب أن تكون كذلك. تخزين التاريخ.مراجع
لا يزال لدي 5 دقائق. أود مناقشة مواضيعي الاحتياطية.أولاً ، كل ما تحدثت عنه ، يلائم ببراعة أيديولوجية المراقبة النشطة ، أي عندما يذهب الخادم لإجراء عمليات الفحص في مكان ما.
الاقتراع النشط والسلبي
ماذا لو كان لديك مراقبة سلبية؟ لدينا الكثير من هذا! هناك اختبارات ، على سبيل المثال ، تستغرق وقتًا طويلاً لحسابها. أو عندما تنتقل بعض البرامج النصية المحددة إلى مكان ما ، قم بإعداد البيانات ومن ثم يجب إرسالها إلى الخادم. من الواضح أن هذه البرامج النصية لا يمكنها معرفة بنية المجموعة بالكامل ، ولن يقوم أي منهم بتفويض قاعدة البيانات بأكملها إليهم. لهذا ، تم إنشاء آلية في الكتلة للبقاء على قيد الحياة مثل هذه الأشياء:
هناك خوادم. قرر الخادم "الرئيسي" أي الأجهزة المضيفة التي تتم معالجتها.- لذلك في حالة إرسال المضيف للبيانات قسراً لا إلى خادمه ، فإن هذا الخادم يستقبل البيانات ويعالجها.
- هناك فحص في المعيار "Zabbix": إنه يتأكد من وجود هذه المقاييس بالفعل في ذاكرة التخزين المؤقت للتكوين ، والتحقق من نوعها.
- , , . , , .
- - , . , , . 200 , – .
ملاحظة: الوكيل الخامل غير معتمد حتى الآن!أزلت الكود. ويرجع ذلك إلى حقيقة أنه يصعب على الأشخاص إنشاء آلية أخرى ، والتي سيظل الخادم مسؤولاً عن هذا الوكيل.الوكلاء النشطون أنفسهم يذهبون إلى الخوادم. هناك خيار خادم لهذا (الوكيل القياسي). الوكيل المعدل لديه خيار الخوادم:
وماذا يفعل هذا الخادم المعدل؟ يحتفظ اتصال KPI مع كافة الخوادم المحددة لذلك ؛ يطلب التكوين ، يرسل البيانات إلى أول خادم متاح من القائمة. هذا يحل المشكلة. افترض أنه إذا كان لديك وكيل تم تكوينه على خادم Zabbix وانخفض خادم Zabbix ، فهناك وكيل آخر في المجموعة حتى لا تترك بدون وكيل ؛ ثم الوكيل فقط السنانير إلى آخر.الأسئلة
سؤال من الجمهور (المشار إليه فيما يلي - أ): - أود أن أوضح كيف تجري الأمور بين الخوادم؟ ما البروتوكول الذي يتواصلون معه؟ هل هناك أي نوع من الأمن؟ لأنه ليس من "الآمن" توصيل الاتصالات بين الخوادم إلى الإنترنت ... كيف يتم ذلك؟
MM: - أعتقد أن هذا منافس لأفضل سؤال - إلى حد! في الواقع ، عندما تحولنا إلى الاتصالات القياسية ، ورثت الخوادم الخاصة باتصالهم بين الخوادم جميع ميزات بروتوكول الاتصال الموجودة بين الخادم والوكيل. سأوضح: هناك تشفير وضغط البيانات. من فضلك - بنفس الطريقة يتم تكوين كل شيء عبر الويب ، حيث يتم تكوينه بشكل قياسي للخادم والوكيل ؛ كل شيء سوف يعمل.
A: - كيف يعمل Hauskiper لك في حالة Clickhouse؟
MM: - في "Zabbix" القياسي ، لا توجد واجهة من "مدبرة المنزل" إلى "واجهة المحفوظات" ، أي أن "واجهة المحفوظات" لا تدعم تدوير البيانات (لا يدعم تطبيق البحث المرن ، على سبيل المثال ، البحث المرن). ربما في 4.2 هو (لم أكن أنظر) ، ولكن حتى الآن على 4.0.9.
اجعلها سهلة! يحتوي "Clickhouse" الجديد على قسم. أود أن أفعل ذلك بفك الارتباط بين الأقسام القديمة. من الواضح أنه لن يكون هناك تناوب على مستوى العناصر الفردية ، ولكن هناك خدعة في Zabbix: يمكنك تحديد قيم عمومية (على سبيل المثال ، تخزين السجل بأكمله لمدة لا تزيد عن 90 يومًا) - يمكنك مسح جميع العناصر ، السجل بأكمله من هذه القيم العالمية . وسيتم ذلك! هناك المزيد حول هذا الموضوع في Gitlab.
نريد أن نفعل الحق المعماري: سواء لتوسيع واجهة التاريخ ، بحيث يكون في الأساس ... بشكل عام ، لا أريد أن أترك الديون التقنية ، ولكن سيتم ذلك. لأنه ضروري ، بدأ المزيد من "Clickhouse" في الدعم.
ج: كيف تشعر حيال هذا؟ يبدو أنك تقوم بالكثير من الأعمال غير المتعلقة بالمزود.
MM: - ربما لم أضعها بشكل صحيح. هذه هوايتي! أنا لست متخصصًا تقنيًا بالفعل - أنا مدير. في وقت فراغي أتدرب.
ج: - أعتقد أنك كنت تفعل هذا كجزء من عملك الأساسي ...
MM: - الأعمال يعطيني مكان بارد للاختبار. في الحقيقة ، أنا أوصي بشدة - إنه يخفف المخ. في مكان ما على "الشيء" الإداري أود أن أقول هذا - عندما يمكنك التبديل من المشاكل الإنسانية إلى هذه. هم بارد جدا حلها! هذه هي القضايا الفنية. أنت مبرمجة ، وأنها تعمل بالطريقة التي مبرمجة! إنه لأمر مؤسف أن لا يفعل الناس ذلك.
ج: - هل تكتب إلى "Clickhouse" من خلال بعض البروكسي أو مباشرة؟
MM: - مباشرة. في الواقع ، يتم أيضًا توريث واجهة المحفوظات التي تم تغييرها ، والتي تستخدم في "Elastix". يتم استخدام عنوان url ، أي من خلال واجهة HTTP "Zabbiks" يرسل "Clickhouse". ما هو رائع ، يجمع Zabbix عندما يكون هناك دفق كبير من التاريخ ، والآلاف من المقاييس في حزمة واحدة ، وهذا يقع بشكل مريح للغاية على Clickhouse.
A: - في الواقع ، يكتب باكي له؟
MM: - نعم. يحتوي استعلام SQL الذي يتم تنفيذه بواسطة عنوان url عادةً على ألف مقاييس. مدراء "Clickhouse" سعيدة فقط.
المقدم: - هذه هي نهاية البرنامج في هذه الغرفة. يوجد برنامج مسائي منظم ، وهناك شيء يمكنك القيام به فقط. وأقترح ، بينما ستتواصل مع بعضك البعض ، للتفكير في الأشياء المثيرة للاهتمام التي يمكنك ... عندما تخبر بعضكما البعض بحالاتك ، فهذا على الأرجح هو ما يمكنك التحدث عنه. مناقشة مع بعضنا البعض ، يمكنك فقط العثور على بعض الخطوط العريضة - سوف تقبل لجنة البرنامج طلبك ، وتدرسه وتساعد في إعداد قصة جيدة ومكتوبة. ربما لديك نوع من القصة حول العمل مع لجنة البرنامج؟
MM: - في الواقع ، يتم إعطاء الكثير من ردود الفعل. كنت محظوظًا للغاية: شخص من لجنة البرنامج يعيش في تشيليابينسك ، و Highload هو المؤتمر الوحيد الذي يعمل عن كثب مع المتحدثين. أنا لم أر أي شيء مثل هذا في أي مكان آخر. انها مفيدة جدا! مراحل مختلفة: يشاهد الرجال الفيديو ، ويقدمون تعليقات على الشرائح - يحدث هذا بالفعل في الموضوع (الإملاء ، الأخطاء المطبعية). رائع جدا أنا أوصي به! جرب نفسك!
قليلا من الإعلان :)
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك ،
VPS المستندة إلى مجموعة النظراء للمطورين من 4.99 دولار ، وهو
تناظرية فريدة من الخوادم على مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps من 19 $ أو كيفية تقسيم الخادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا
2 من Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 جيجا هرتز 14 جيجا بايت 64 جيجا بايت DDR4 4 × 960 جيجا بايت SSD 1 جيجابت في الثانية 100 TV من 199 دولار في هولندا! Dell R420 - 2x E5-2430 سعة 2 جيجا هرتز 6 جيجا بايت 128 جيجا بايت DDR3 2x960GB SSD بسرعة 1 جيجابت في الثانية 100 تيرابايت - من 99 دولارًا! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟