نظام مراقبة آخر

16 مودم ، 4 مشغلي شبكة خلوية = سرعة التحميل 933.45 ميجابت في الثانية

مقدمة

مرحبًا! تتناول هذه المقالة كيفية كتابة نظام مراقبة جديد لأنفسنا. وهو يختلف عن الموجود من خلال إمكانية الحصول المتزامن عالي التردد على المقاييس واستهلاك الموارد المنخفض للغاية. يمكن أن يكون معدل الاقتراع منخفضًا مثل 0.1 مللي ثانية مع دقة توقيت تبلغ 10 نانوثانية بين المقاييس. تشغل جميع الملفات الثنائية 6 ميغا بايت.

نبذة عن المشروع

لدينا منتج محدد نوعًا ما. نحن ننتج حلاً شاملاً لتجميع الإنتاجية والتسامح مع أخطاء قنوات نقل البيانات. هذا عندما يكون هناك عدة قنوات ، دعنا نقول Operator1 (40Mbps) + Operator2 (30Mbps) + شيء آخر (5 Mbps) ، تكون النتيجة قناة واحدة ثابتة وسريعة ، وسرعتها ستكون شيئًا كالتالي: (40+ 30) +5) x0.92 = 75 × 0.92 = 69 ميجابت في الثانية.

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

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

صياغة المشكلة

يوفر نظام المراقبة استلام مقاييس من فئتين مختلفتين اختلافًا جوهريًا: مقاييس الوقت الفعلي وجميع المقاييس الباقية. كان لدى نظام المراقبة المتطلبات التالية فقط:

1. اكتساب متزامن عالي التردد لمقاييس الوقت الفعلي ونقلها إلى نظام التحكم في الاتصالات دون تأخير.
   لا يعد التردد العالي ومزامنة المقاييس المختلفة أمرًا مهمًا فحسب ، بل إنه أمر حيوي لتحليل إنتروبيا قنوات نقل البيانات. إذا كان متوسط ​​التأخير في إحدى قنوات نقل البيانات 30 مللي ثانية ، فإن الخطأ في المزامنة بين المقاييس الأخرى بمقدار مللي ثانية واحد فقط سيؤدي إلى تدهور سرعة القناة الناتجة بنحو 5٪. إذا فاتنا التوقيت بمقدار 1 مللي ثانية في 4 قنوات ، يمكن أن ينخفض ​​تدهور السرعة بسهولة إلى 30٪. بالإضافة إلى ذلك ، فإن الانتروبيا في القنوات تتغير بسرعة كبيرة ، لذلك إذا قمنا بقياسها أقل من مرة واحدة كل 0.5 مللي ثانية ، فسنحصل على انخفاض عالي السرعة في القنوات السريعة مع تأخير بسيط. بالطبع ، هذه الدقة ليست ضرورية لجميع المقاييس وليس في جميع الظروف. عندما يكون التأخير في القناة 500 مللي ثانية ، ونحن نعمل مع هذا ، فإن خطأ 1 مللي ثانية سيكون بالكاد ملحوظًا. أيضًا ، بالنسبة لمقاييس أنظمة دعم الحياة ، لدينا معدلات اقتراع ومزامنة كافية لمدة ثانيتين ، ولكن يجب أن يكون نظام المراقبة نفسه قادرًا على العمل بمعدلات اقتراع عالية جدًا ومزامنة فائقة الدقة للمقاييس.
2. الحد الأدنى من استهلاك الموارد ومكدس واحد.
   يمكن أن يكون الجهاز النهائي إما نظامًا قويًا على متن الطائرة يمكنه تحليل الموقف على الطريق أو إجراء تثبيت بيومتري للأشخاص ، أو جهاز كمبيوتر بحجم راحة اليد يرتديه جندي من القوات الخاصة تحت سترة واقية من الرصاص لنقل الفيديو في في الوقت الحقيقي في ظروف ضعف التواصل. على الرغم من هذا التنوع في البنى وقوة الحوسبة ، نود أن يكون لدينا نفس مجموعة البرامج.
3. العمارة المظلة
   يجب جمع المقاييس وتجميعها على الجهاز النهائي ، وأن يكون لديها نظام تخزين محلي وتصور في الوقت الفعلي وبأثر رجعي. إذا كان هناك اتصال ، فقم بنقل البيانات إلى نظام المراقبة المركزي. في حالة عدم وجود اتصال ، يجب أن تتراكم قائمة انتظار الإرسال ولا تستهلك ذاكرة الوصول العشوائي.
4. API للتكامل في نظام مراقبة العميل ، لأنه لا يحتاج أحد إلى العديد من أنظمة المراقبة. يجب على العميل جمع البيانات من أي أجهزة وشبكات في مراقبة واحدة.

ماذا حدث

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

جمع صبيب ثلاث قنوات لطبولوجيا الشبكات المختلفة

تصور بعض المقاييس الرئيسية

هندسة معمارية

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

يتم تنفيذ النظام وفقًا للمبدأ المعياري الكلاسيكي ويحتوي على عدة أنظمة فرعية:

1. تسجيل المقاييس.
   يتم تقديم كل مقياس من خلال مؤشر ترابط خاص به ويتم مزامنته عبر القنوات. تمكنا من الحصول على دقة مزامنة تصل إلى 10 نانوثانية.
2. تخزين المقاييس
   اخترنا بين كتابة التخزين الخاص بنا للسلسلة الزمنية أو استخدام شيء من التخزين الحالي. قاعدة البيانات مطلوبة للبيانات بأثر رجعي التي تخضع لتصور لاحق. أي أنها لا تحتوي على بيانات عن تأخيرات القناة كل 0.5 مللي ثانية أو مؤشرات الخطأ في شبكة النقل ، ولكن هناك سرعة على كل واجهة كل 500 مللي ثانية. بالإضافة إلى المتطلبات العالية للمنصات المشتركة والاستهلاك المنخفض للموارد ، من المهم للغاية بالنسبة لنا أن نكون قادرين على المعالجة. البيانات حيث يتم تخزينها. هذا يوفر الكثير من موارد الحوسبة. لقد استخدمنا نظام Tarantool DBMS في هذا المشروع منذ عام 2016 ، وحتى الآن لا نرى بديلاً له في الأفق. المرونة ، مع الاستهلاك الأمثل للموارد ، أكثر من الدعم الفني الكافي. يحتوي Tarantool أيضًا على وحدة GIS. بالطبع ، ليست قوية مثل PostGIS ، لكنها كافية لمهامنا في تخزين بعض المقاييس المتعلقة بالموقع (ذات الصلة بالنقل).
3. تصور المقاييس
   كل شيء بسيط نسبيًا هنا. نأخذ البيانات من المستودع ونعرضها إما في الوقت الفعلي أو بأثر رجعي.
4. تزامن البيانات مع نظام المراقبة المركزي.
   يتلقى نظام المراقبة المركزي البيانات من جميع الأجهزة ، ويخزنها بأثر رجعي معين ، ويرسلها عبر واجهة برمجة التطبيقات إلى نظام مراقبة العميل. على عكس أنظمة المراقبة الكلاسيكية ، حيث يسير "الرأس" ويجمع البيانات ، لدينا المخطط العكسي. ترسل الأجهزة نفسها البيانات عندما يكون هناك اتصال. هذه نقطة مهمة للغاية ، لأنها تسمح لك باستقبال البيانات من الجهاز لتلك الفترات الزمنية التي لم يكن فيها متاحًا وعدم تحميل القنوات والموارد في وقت لا يكون فيه الجهاز متاحًا. نحن نستخدم خادم مراقبة التدفق كنظام مراقبة مركزي لدينا. على عكس نظائرها ، يمكنها استيراد البيانات بأثر رجعي (أي ، مع طابع زمني مختلف عن لحظة استلام المقياس). يتم تصور المقاييس التي تم جمعها بواسطة Grafana ، مع تعديلها بملف. تم اختيار هذا المكدس القياسي أيضًا لأنه يحتوي على واجهات برمجة تطبيقات جاهزة للتكامل مع أي نظام مراقبة للعملاء تقريبًا.
5. مزامنة البيانات مع نظام إدارة الجهاز المركزي.
   يقوم نظام إدارة الجهاز بتنفيذ Zero Touch Provisioning (تحديث البرنامج الثابت والتكوين وما إلى ذلك) ، وعلى عكس نظام المراقبة ، لا يتلقى سوى مشاكل الجهاز. هذه هي المشغلات لتشغيل خدمات مراقبة الأجهزة على متن الطائرة وجميع مقاييس أنظمة دعم الحياة: درجة حرارة وحدة المعالجة المركزية و SSD ، وحمل وحدة المعالجة المركزية ، والمساحة الخالية وصحة SMART على الأقراص. تم بناء تخزين النظام الفرعي أيضًا على Tarantool. يمنحنا هذا سرعة كبيرة في تجميع السلاسل الزمنية عبر آلاف الأجهزة ، كما يحل تمامًا مشكلة مزامنة البيانات مع هذه الأجهزة. يحتوي Tarantool على نظام انتظار رائع وتسليم مضمون. لقد حصلنا على هذه الميزة المهمة خارج الصندوق ، رائع!

نظام إدارة الشبكة

ما هي الخطوة التالية

حتى الآن ، الحلقة الأضعف لدينا هي نظام المراقبة المركزي. يتم تنفيذه بنسبة 99.9 ٪ على مكدس قياسي وله عدد من العيوب:

1. InfluxDB يفقد البيانات عن انقطاع التيار الكهربائي. كقاعدة عامة ، يأخذ العميل بسرعة كل ما يأتي من الأجهزة ولا توجد بيانات أقدم من 5 دقائق في قاعدة البيانات نفسها ، ولكن في المستقبل يمكن أن يصبح هذا ألمًا.
2. تواجه Grafana عددًا من المشكلات المتعلقة بتجميع البيانات وتزامن العرض. المشكلة الأكثر شيوعًا هي عندما تحتوي قاعدة البيانات على سلسلة زمنية بفاصل زمني من ثانيتين تبدأ ، على سبيل المثال ، من 2:00:00 ، ويبدأ Grafana في عرض البيانات في تجميع من +00 ثانية. نتيجة لذلك ، يرى المستخدم رسمًا بيانيًا راقصًا.
3. كمية كبيرة من التعليمات البرمجية لتكامل واجهة برمجة التطبيقات مع أنظمة المراقبة التابعة لجهات خارجية. يمكنك جعله أكثر إحكاما وبالطبع إعادة كتابته في Go)

أفترض أنكم جميعًا قد رأيتم تمامًا كيف تبدو غرافانا وبدوني تعرفون مشاكلها ، لذلك لن أفرط في تحميل المنشور بالصور.

اختتام

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

إذا كان لدى أي شخص أسئلة خارج هذه المقالة ، فلا تتردد في مراسلتي عبر البريد الإلكتروني على a.rodin @ qedr.com

المصدر: www.habr.com