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

سرعة الجمع على 16 أجهزة المودم من 4 مشغلي شبكات الهاتف النقال. السرعة الصادرة في دفق واحد - 933.45 ميغابت في الثانية

مقدمة

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

عن المشروع

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

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

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

بيان المشكلة

يوفر نظام المراقبة مقاييس لفئتين مختلفتين بشكل أساسي: مقاييس في الوقت الفعلي وكل الباقي. كان لنظام الرصد المتطلبات التالية:

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

ماذا حدث

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

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

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

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

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

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

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

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

ما التالي

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

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

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

استنتاج

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

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