مرحبا
هناك رغبة في مشاركة المجتمع بفكرة يتم تنفيذها في الشركة المزودة للاستجابة السريعة للأضرار التي لحقت بالكبل النحاسي. إنه عن زوج ملتوي وإيثرنت. بالطبع أنا لا أدعي أنها حلول أنيقة ، لكن الخدمة أظهرت نتائج جيدة.
بالنسبة لأولئك الذين كسول جدا لقراءة. كيف يعمل: مراقبة سقوط الجلسات على دائرة نصف قطرها ، تجميع حسب المفاتيح ، اختبار الخط ، إخطار خوذة.
لا يمكنني إعطاء رمز المشروع بالكامل لأسباب تتعلق بالشركات ، لكنني سأزيل الرمز الموجود تحت المفسدين للمهتمين. نعم ، وسيختلف تطبيق كل مزود. بدلاً من ذلك ، فإن الهدف هو مشاركة فكرة قد تساعد شخصًا ما.
الجهاز في الشركة هو 99 ٪ مد وصلة ، لذلك يتم سرد SNMP MIBs لهذا البائع. بعضها RFCs وينبغي أن تكون مناسبة للشركات المصنعة الأخرى.
قليلا من التاريخ حول كيف خرج كل شيء.
بدأ كل شيء في ربيع عام 2018. زاد العبء على مجموعة الدعم الفني (TP). بالإضافة إلى معالجة مكالمات المشترك ، قامت TP أيضًا بتنسيق المثبتات عند توصيل مشتركين جدد ، وكذلك عند المغادرة لاستعادة وتصحيح العملاء الحاليين. كان من الضروري تفريغ TP قليلاً وإعطاء بعض الأدوات للمثبتين. تقرر إنشاء برنامج "روبوت" للرسول يقبل تسجيل الدخول / العقد الخاص بالمشترك ويمكن أن يقوم المثبت بإجراء تصحيح الحد الأدنى مباشرة في الحقول.
لم أكن أرغب في تضمين جميع الوظائف في تطبيق واحد ، لأن في الواقع ، ستكون هذه الوظيفة مفيدة أيضًا في المستعرض في نفس CRM عند معالجة مكالمة ، لذلك تقرر وضع آليات التفاعل مع معدات الشبكة ، والفوترة ، ونصف القطر في خدمة منفصلة ، وجعلها واجهة برمجة تطبيقات وربط كل من الروبوت و CRM عبر واجهة برمجة التطبيقات وهذا كل شيء أيا كان.
الآن رمز صغير وانتقل إلى جوهر المنشور.
وهكذا ، ماذا يمكن أن يحتاج المثبت في الحقول:
- اختبار كابل بالطبع
- عرض أخطاء المنفذ
- عرض حالة المنفذ
- معرفة ما إذا كان هناك عناوين MAC على المنفذ. (فجأة قام المشترك بتوصيل الكبل في منفذ LAN بدلاً من WAN)
- اشتراك IPTV
- عرض سجلات التفويض
- حالة الرصيد
سنتفاعل مع المفاتيح عبر SNMP ، وفي بعض الأماكن عبر telnet.
أنا استخدم زجاجة كإطار ويب.
و كذلك
نضيف ورقة مع مفاتيح API والديكور للتحقق منها ، لكننا لن نقدم بيانات للجميع على التوالي).
كود apikeys = ['RANDOM_KEY1', 'RANDOM_KEY2'] api_error = '{"error":"apikey invalid"}' host_down_error = '{"error":"host down"}' def apikey_checker(fn): def wrapper(*args, **kwargs): if not check_apikey(): return api_error return fn(*args, **kwargs) return wrapper def check_apikey(): return 'apikey' in request.query and request.query['apikey'] in apikeys
حسنا ، في الواقع بضع وظائف للتفاعل مع المعدات.
كود @route('/port_status/<ip>/<port>') @apikey_checker def get_port_status(ip=' ', port=' '): return snmp.port_status(ip, port) @route('/cable_test/<ip>/<port>') @apikey_checker def get_cable_test(ip, port): return snmp.cable_test(ip, port)
داخل snmp لدينا قاموس مع تفسير لحالات SNMP التي تم إرجاعها للزوج على المنفذ.
قاموس الحالة pair_status = { '0': 'ok', '1': 'open', '2': 'short', '3': 'open-short', '4': 'crosstalk', '5': 'unknown', '6': 'count', '7': 'no-cable', '8': 'other' }
تحضير القاموس لنتائج قياس المنفذ. سنقوم بنسخها ، حتى لا تصنع واحدة جديدة في كل مرة.
النص المخفي pair_result = { 'pairs': { 1: { 'status': '-', 'length': '-' }, 2: { 'status': '-', 'length': '-' }, 3: { 'status': '-', 'length': '-' }, 4: { 'status': '-', 'length': '-' }, } }
وظيفة
اختبار الكابل def cable_test(ip, port): if not check_ip(ip):
سوف وظيفة العودة
النتيجة { "pairs": { "1": { "status": "other", "length": "0" }, "2": { "status": "open", "length": "4" }, "3": { "status": "open", "length": "4" }, "4": { "status": "other", "length": "0" } } }
وأضاف في وقت لاحق وظيفة أخرى مماثلة ، حصرا للبرنامج النصي ، فإنه يتلقى قائمة من المنافذ كمدخل ، وليس واحد ، ولا يتحقق من حالة المنفذ قبل الاختبار ، وهذا ليس ضروريا مع انخفاض هائل في الروابط.
هذا ما بدأ الروبوت لتبدو
الآن إلى جوهر هذا المنصب.
قبل تنفيذ
تصحيح أخطاء الخادم ، تم استخدام تقنية مشابهة لتلك الموضحة في
المنشور habr.com/post/188730 . حلقة على المنفذ مع تمكين سلم SNMP. عندما سقطت "الطائرة" في الميناء ، سقطت رسالة حول ذلك في المراقبة.
بادئ ذي بدء ، لقد قمت بالثقب في البرنامج النصي بحيث أنه عندما سقط ارتباط التتبع ، انتقل خادم debug إلى المحول ، وتحقق مما إذا كان المنفذ يكذب حقًا ، ولم يكن وميضًا فقط ، وكانت الأزواج الموجودة عليه مفتوحة أو مختصرة ، ثم أرسل رسالة إلى المشغلين.
ومع ذلك ، فإن حوالي 10 ٪ فقط من المفاتيح لديها مثل هذه الفخاخ المادية ، وهذا تبين أن لا يكفي.
جاء في وقت لاحق مع دائرة نصف قطرها الشاشة. وهذا ما سمح بزيادة نسبة التغطية بنسبة تصل إلى 100٪. وهنا كل شيء يختلف بالفعل عن البنية التحتية للمزود.
نحن ننظر بشكل دوري إلى عدد جلسات العميل التي سقطت من مفتاح معين. يكون ذلك سهلاً إذا تم تمكين circuit_id على رموز التبديل التي تحتوي على النموذج
D4: CA: 6D: 0A: 66: C9 ::
192.168.20.86 ::
20هنا لدينا لجنة الهدنة العسكرية للمشترك ، والتبديل IP ، ورقم المنفذ للمشترك. أي كل ما تحتاجه لتصحيح.
نقوم بتجميع الجلسات المكتملة بواسطة مفتاح IP ، إذا كان هناك أكثر من عدد قليل من الجلسات (لدينا مجموعة مشغلات في جلستين في الدقيقة) ، ثم يقوم البرنامج النصي بالاتصال بخادم تصحيح الأخطاء واختبار منافذ الجلسات المسقطة. إذا كانت المنافذ لا تزال قائمة وأزواج الكبلات مفتوحة أو قصيرة ، وطول المنفذين على الأقل هو نفسه (+ - 2 متر) ، وهو بالضبط ما يبدو عليه قطع الكبلات بعيون المحول ، فإننا نعتبر الموقف مشبوهًا ونرسل رسالة إلى المشغل.
بالطبع ستكون هناك إيجابيات كاذبة عندما يومض الضوء في المنزل ، أو أنه يتزامن فقط مع قيام المشتركين بإيقاف تشغيل الكابل في نفس الوقت ويكون الطول هو نفسه ، ولكن هذا هو الحال ، كما يقولون ، عندما يكون من الأفضل الإفراط في ذلك. بالإضافة إلى ذلك ، يمكنك تحديد الحد الأقصى للطول (الاستجابة فقط للأطوال القصيرة) ، وعدد القطرات المتزامنة ، إلخ.
هنا هو التقرير الحقيقي لحدث مشبوه.
ونتائج معالجة هذه الرسائل
كانت هناك حالة عندما أرسل البرنامج النصي رسالة مماثلة ، وبعد بضع ثوانٍ أصبح المفتاح غير متصل ، لأن البصريات التالفة ، وإن لم يكن لسرعة البرنامج ، فإن الوضع قد يكون مخطئًا بسبب انقطاع التيار الكهربائي المعتاد في المنزل.
مرة أخرى ، بدأت شركة الإدارة في إصلاح السقف دون سابق إنذار ، وانتقلت VOKhR بالمدافع الرشاشة إليهم ، مما تسبب في إجهاد مفاجئ للأقفال.
وهكذا بدأ النص يظهر نتائج جيدة وعلى مدى أكثر من 4 أشهر من العمل ، أنجزت VOKhR والشرطة وموظفو المزود أنفسهم بنجاح أكثر من 10 حالات تخريب. لذلك ، قررت أن أشارككم مفهوم هذا الرصد.
يقوم البرنامج النصي الآن بمراقبة حوالي 15000 مفتاح دون أي "اعتراضات" أو اعتراضات SNMP.
حظا سعيدا للجميع في العام الجديد!