المحتويات

المقدمة

مستمع

مقدمة مختصرة عن القياس عن بعد

لماذا القياس عن بعد

الحاجة إلى الابتعاد عن بروتوكول SNMP

مزايا تتبع الدفق

المواصفات الفنية للقياس عن بعد المعتمدة على النموذج

وظائف القياس عن بعد

مكونات القياس عن بعد

يانغ

ترميز

النقل

القياس عن بعد المستند إلى Cadence مقابل القياس عن بعد المستند إلى الحدث

إرشادات تصميم بيانات تتبع الاستخدام

كيفية تحديد مخطط الترميز

إعتبار تصميم شبكة النقل

تقييم خيارات تكوين بيانات تتبع الاستخدام

أمثلة تكوين بيانات تتبع الاستخدام

IOS-XR

تقسيم تكوين الطلب الخارجي

تحديد مجموعات المستشعر

تحديد مجموعات الوجهة

تحديد الاشتراك

إكمال مثال التكوين

مزايا الطلب الهاتفي

تقسيم التكوين للطلب في

تمكين gRPC

تحديد مجموعات المستشعر

تحديد الاشتراك

إكمال قالب التكوين ومثال

مزايا الطلب الهاتفي

القياس عن بعد المستند إلى الحدث

تكوين بيانات تتبع إستخدام الحدث

إكمال قالب التكوين ومثال الطلب الهاتفي

إكمال قالب التكوين ومثال الطلب الهاتفي

التحقق من بيانات تتبع الاستخدام باستخدام أوامر SHOW

مجموعة بيانات تتبع الاستخدام

اعتبارات النشر للقياس عن بعد في شبكة

تغيير المقياس

دفق البيانات المطلوبة فقط

ضع في الاعتبار مقدار البيانات المتدفقة

المراجع

المقدمة

مستمع

يهدف هذا التقرير الرسمي إلى مساعدة العملاء على الحصول على فهم سريع لميزة "القياس عن بعد وفقا للنموذج (MDT)" بشكل عام وكيف تم تنفيذها في موجه خدمات التجميع 9000 (ASR9K) بما في ذلك بعض إرشادات التصميم وتفاصيل التكوين. كما أنها تتضمن بعض الاعتبارات الخاصة بعملية النشر، والتي ستكون مفيدة أثناء نشر هذه الميزة باستخدام ASR9K. بشكل عام، يمكن أن يكون هذا التقرير مرجعا سريعا لأي شخص يعمل على هذه الميزة.

على الرغم من إدخال بيانات تتبع الاستخدام كميزة عامة، إلا أن التركيز يكون على تنفيذ ASR9K، أي أن الميزات التي تدعمها منصات Cisco الأخرى لا تدعمها منصة ASR9K وقد يكون بعض تنفيذ الميزات خاصا ب ASR9K.

مقدمة مختصرة عن القياس عن بعد

في البداية ، وبعبارات بسيطة ، القياس عن بعد هو عملية جمع بيانات عملية مفيدة. وفقا لويكيبيديا، القياس عن بعد هو عملية إتصالات آلية يتم من خلالها جمع القياسات والبيانات الأخرى في نقاط بعيدة أو يصعب الوصول إليها ونقلها إلى أجهزة الاستقبال للمراقبة. كلمة تتبع الاستخدام نفسها مشتقة من الجذور اليونانية: tele = remote، و metron = measure.

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

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

تم إدخال تقنية Telemetry المستندة إلى النماذج (MDT) في cXR (32 بت IOS XR) منذ الإصدار 6.1.1 وتسمح بتجميع وقياس البيانات المهمة في وقت قريب من الوقت الفعلي مما يوفر إجابة سريعة لمعظم مشكلات تشغيل الشبكة الحديثة.

بنية تتبع الاستخدام عالية المستوى

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

بدلا من انتظار إسترداد البيانات (سحبها) من محطة إدارة مركزية (عادة ما تكون SNMP NMS)؛ باستخدام ميزة MDT، تقوم أجهزة الشبكة بإرسال (الدفع) بشكل استباقي بيانات الأداء المتعلقة بالمهام الحيوية للشبكة، مثل معلومات إعادة توجيه الحزم وإحصاءات الأخطاء وحالة النظام ووحدة المعالجة المركزية (CPU) وموارد الذاكرة، وما إلى ذلك.

لماذا القياس عن بعد

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

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

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

الحاجة إلى الابتعاد عن بروتوكول SNMP

كان بروتوكول إدارة الشبكات البسيط (SNMP) موجودا منذ ثلاثة عقود ولم تتغير الطريقة التي يعمل بها لتتناسب مع إحتياجات المراقبة للشبكات الحديثة. المشكلة الحقيقية هي سرعة تنفيذ SNMP.

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

- سرعة التنفيذ والحاجة إلى مراقبة فورية

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

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

- النفقات الإضافية ونقص خيارات التحسين

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

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

- الطبيعة الخطية لأعباء العمل

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

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

وبواسطة المعاملة التجارية المتعددة، فإن النهج المتبع في جمع البيانات يتغير تغيرا جذريا ومبادئه الأساسية يرد في الجدول أدناه ومقارنته بالنقاط الرئيسية لتكنولوجيا SNMP.

بروتوكول إدارة الشبكات البسيط (SNMP)

القياس عن بعد المستند إلى النموذج (MDT)

معلومات غير آنية

معلومات الوقت الفعلي

غير قابل للتطوير بدرجة كبيرة

قابلية تطوير عالية

نموذج السحب

نموذج الدفع

غير مؤتمت

الجاهزية للأتمتة/نموذج البيانات المدفوع

مزايا تتبع الدفق

تعد بيانات تتبع إستخدام البيانات في الوقت الفعلي المتدفقة مفيدة في:

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

إمكانية رؤية أفضل: يساعد على اكتشاف حالات الأعطال التي تحدث بعد ظهور حالة إشكالية في الشبكة وتفاديها بسرعة فائقة.

المواصفات الفنية للقياس عن بعد المعتمدة على النموذج

يتناول القسم التالي الوظائف الفنية والمكونات الرئيسية لتطبيق Telemetry المستند إلى نموذج IOS XR المعروف بالاختصار MDT.

وظائف القياس عن بعد

يتم تنظيم إطار عمل تتبع الاستخدام في ثلاث كتل وظيفية منفصلة ومترابطة.

الكتلة الأولى تتعلق بتمثيل البيانات، وهي الطريقة التي يتم بها تنظيم تحليل أو قياسات إحالة المعلومات على متن الطائرة.

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

والكتل الأخير يتعلق بالنقل. هذا هو مكدس البروتوكولات الذي يتم إستخدامه لنقل البيانات بين الأجهزة.

يلخص الجدول التالي البنية الرئيسية للكتل البنائية للقياس عن بعد المستندة إلى النموذج:

دالة

المكونات

تمثيل البيانات

نماذج بيانات يانغ

ترميز

GPB / GPB ذاتي الوصف

النقل

TCP/gRPC

جدول 3 كتل بناء تتبع الاستخدام

مكونات القياس عن بعد

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

أصبح Yang مؤخرا معيارا لنمذجة البيانات، ويستخدم هذا من قبل مكدس قابلية البرمجة من Cisco لتشكيل مجموعة بيانات مهيكلة يمكن تشفيرها وحملها بأسرع ما يمكن عبر الشبكة. توفر مرونة يانغ الميزة الكبيرة التي يمكن إستخدامها أيضا كأداة تكوين لعمليات التشغيل التلقائي. ويتم دمج نماذج البيانات هذه بتنسيقات ترميز وبروتوكولات نقل محددة لجعل MDT حلا كاملا لتحليلات الشبكة.

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

حزمة قابلية البرمجة IOS XR

يانغ

ويعرف يانغ باسم "لغة نمذجة البيانات المستخدمة لنمذجة بيانات التكوين وبيانات الحالة والإخطارات لبروتوكولات إدارة الشبكة". وبسبب طبيعتها المنفصلة عن بنية لغة برمجة نموذجية يمكن تنفيذ اليانغ للتفاعل مع مجموعة كبيرة متنوعة من الادوات.

بنى بيانات نماذج يانغ مبنية حول مفهوم الوحدات والوحدات الفرعية التى تحدد تسلسل البيانات في شجرة مثل الموضة التى يمكن إستخدامها في عدة عمليات بما في ذلك إجراءات التكوين ومعالجة الاخطار.

هناك مصادر متعددة من طرازات // يانغ // متاحة للاستخدام منها اقل من ثلاثة تعتبر أساسية :

- الطرز الأصلية / الخاصة من Cisco

- أوبن config

- IETF

نماذج خاصة من Cisco: تسمى هذه أيضا طراز أصلي ويتم نشرها بواسطة العديد من موردي الأجهزة، بما في ذلك Cisco. على سبيل المثال Cisco-IOS-XR-ptp-oper.yang

نماذج OpenConfig: OpenConfig هو مجموعة عمل غير رسمية من مشغلي الشبكة. يحدد OpenConfig طرز YANG الشائعة التي يجب على جميع الموردين دعمها لتكوين الميزات الحيوية للمهام. على سبيل المثال، openConfig-interfaces.yang

نماذج IETF: كما تحدد IETF عددا قليلا من وحدات YANG الشائعة التي تصف التكوين الأساسي للواجهات، وجودة الخدمة، وتحدد أنواع البيانات الأخرى الشائعة (مثل IPv4 و IPv6، وما إلى ذلك). على سبيل المثال، ietf-syslog-types.yang

تدعم Cisco نماذج OpenConfg المتاحة. ويتقارب البائعون مع الطريقة الموحدة لنمذجة البيانات لدعم بيئة متعددة البائعين.

وهناك ثلاثة أنواع من نماذج يانغ:

1. عملياتي

2. التكوين

3. الإجراء

ولا تهتم القياسات عن بعد إلا بنماذج يانغ التشغيلية التي يمكن تحديدها على أنها *-oper-*.yang.

ويتم تحديد Yang في RFC 7950: https://tools.ietf.org/html/rfc7950.

ترميز

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

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

هناك نوعان من GPB كخيارات تشفير للتدفق عن بعد:

1. GPB مضغوط

2. GPB ذاتي الوصف

الفرق الأساسي بين تنسيقي تتبع تتبع تتبع تتبع تتبع تتبع تتبع GPB هو كيفية تمثيلهما وترميز المفاتيح داخل دفق بيانات تتبع بيانات القياس.

JSON هو مخطط ترميز آخر سهل الاستخدام يسهل فهمه ويمكن لأي تطبيق تقريبا فك ترميزه.

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

النقل

يوفر القياس عن بعد ثلاثة خيارات ممكنة لبروتوكولات النقل:

- TCP

- gRPC

- UDP

كما يحدد TeleRate وضعي بدء مختلفين لبدء جلسة بين العقدة والمجمع:

- اتصال هاتفي

- الطلب الهاتفي

يتكون الفرق بين الوضعين فقط في كيفية إنشاء جلسة عمل النقل.

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

لجلسات عمل الطلب الهاتفي، يستمع الموجه بشكل سلبي إلى منفذ TCP في انتظار اتصال خادم.

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

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

تعد gRPC إطارا عصريا مفتوح المصدر تم تصميمه لتشغيله في أية بيئة. تم تصميمه على قمة HTTP/2 ويوفر مجموعة محسنة وغنية من الميزات.

القياس عن بعد المستند إلى Cadence مقابل القياس عن بعد المستند إلى الحدث

يتم تدفق البيانات من مجموعة البيانات المشتركة إلى الوجهة إما في فترة دورية تم تكوينها أو فقط عند حدوث حدث. ويعتمد هذا السلوك على ما إذا كان يتم تكوين MDT للقياس عن بعد المستند إلى تحديد الطلب أو القياس عن بعد المستند إلى الحدث.

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

يوصى باستخدام بيانات تتبع إستخدام الحدث لأحداث مرتبطة بالتغيير.

إرشادات تصميم بيانات تتبع الاستخدام

كما هو موضح، هناك العديد من المكونات في مكدس بيانات تتبع الاستخدام، فيما يلي بعض الإرشادات التي يجب مراعاتها أثناء تنفيذ بيانات تتبع إستخدام أجهزة XR.

كيفية تحديد مخطط الترميز

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

وتختلف خيارات الترميز المختلفة من حيث كفاءة السلك وسهولة الاستخدام.

ترميز

وصف موجز

الكفاءة على الأجهزة السلكية

إعتبار آخر

GPB (مضغوط)

كل شيء ثنائي

(باستثناء القيم التي هي سلاسل)

سرعة أكبر بمعدل الضعف وأكثر تعقيدا من الناحية التشغيلية (ولكن ليس بالنسبة لبروتوكول SNMP)

عالي

ملف Proto لكل نموذج

GPB - KV (زوج قيم المفاتيح)

مفاتيح السلسلة والقيم الثنائية

(باستثناء القيم التي هي سلاسل)

أكبر بمعدل 3 أضعاف،

النماذج الأصلية: لا تزال بحاجة إلى معرفة أسماء المفاتيح

متوسط إلى منخفض

ملف .proto واحد لفك الترميز

جسون

كل شيء سلاسل مفاتيح وقيم

منخفض

ودود. طراز قابل للقراءة من قبل الأشخاص ويتسم بسهولة الاستخدام وسهولة التحليل

يعطي GPB-KV نقطة منتصف جيدة ومتوازنة لمخطط الترميز.

فيما يتعلق بطول الرسالة لمخطط الترميز المختار، فيما يلي المقارنة الموجودة على السلك.

مقارنة الترميز - طول الرسالة بالبايت

إعتبار تصميم شبكة النقل

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

مقارنة عرض النطاق الترددي للشبكة

cisco يوصي أن يستعمل KV-GPB. فهو يعمل كنقطة وسط جيدة بين الكفاءة والراحة.

تقييم خيارات تكوين بيانات تتبع الاستخدام

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

والمكونات الرئيسية الأربعة هي:

1. النقل

2. ترميز

3. إتجاه جلسة العمل

4. نماذج بيانات يانغ

النقل: وكما ذكرنا، يمكن للعقدة توفير بيانات تتبع الاستخدام إما عبر إستخدام بروتوكول TCP أو بروتوكول UDP أو gRPC عبر بروتوكول HTTP/2.

على الرغم من أن بروتوكول TCP هو الخيار المفضل للبساطة، إلا أن تقنية gRPC توفر إمكانية TLS إختيارية والتي يمكن اعتبارها ميزة إضافية من وجهة نظر الأمان.

الترميز: يمكن للموجه توفير بيانات القياس عن بعد في معيارين مختلفين من وحدات التخزين المؤقت لبروتوكول Google: جهاز GPB صغير الحجم وذاتي الوصف.

إن GPB المضغوط هو أكثر الترميز فعالية ولكنه يتطلب ميزة .proto فريدة لكل طراز يانغ يتم تدفقه. ولأنه يصف نفسه بنفسه، فإن قاعدة بيانات gpb أقل كفاءة، إلا أنها تستخدم ملف .proto مفرد لفك ترميز جميع طرازات YANG، وذلك لأن المفاتيح يتم تمريرها كسلاسل في .proto.

إتجاه جلسة العمل: هناك خياران لبدء جلسة العمل في نشر بيانات تتبع الاستخدام. يمكن للموجه "الاتصال الهاتفي" بالمجمع أو يمكن للمجمع "الاتصال الهاتفي" بالموجه.

يانغ هو المعيار المقبول في الصناعة لنمذجة البيانات و مجموعة قابلية البرمجة من Cisco تستخدمها أيضا لتشكيل مجموعة بيانات مركبة يمكن تشفيرها وحملها بأسرع ما يمكن عبر الشبكة.

تعمل نماذج البيانات هذه المقترنة بتنسيقات ترميز وبروتوكولات نقل معينة كما تمت مناقشته أعلاه على جعل القياس عن بعد المستند إلى النموذج (MDT) حلا متكاملا للتحليلات.

أمثلة تكوين بيانات تتبع الاستخدام

IOS-XR

تقسيم تكوين الطلب الخارجي

في وضع الطلب الهاتفي، يكون الموجه مسؤولا عن بدء جلسة TCP إلى المجمع وإرسال البيانات التي تم تحديدها بواسطة مجموعة المستشعر في الاشتراك.

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

1. تحديد مجموعات المستشعر

2. تحديد مجموعات الوجهة

3. تحديد الاشتراك

تحديد مجموعات المستشعر

يحدد تكوين مجموعة المستشعر المعلومات التي سيتم تدفقها. يوفر قالب التكوين التالي التكوين المطلوب لتكوين مجموعات المستشعر.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

يوضح المثال التالي المثال الفعلي من واجهة سطر الأوامر (CLI) للموجه حيث يوجد مثال حقيقي لتكوين مجموعة المستشعر:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

يمكن أن يكون لدينا مسارات مستشعر متعددة كجزء من نفس تعريف SensorGroup:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

تحديد مجموعات الوجهة

يحدد تكوين مجموعة الوجهة الوجهة الوجهة التي سيتم توجيه المعلومات إليها.

له ثلاثة معايير رئيسية

1. إتجاه جلسة العمل

2. الترميز المراد إستخدامه

3. بروتوكول النقل المراد إستخدامه

فيما يلي مثال:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)# destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#  address family ipv4 10.1.1.1 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#   encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#   protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

تحديد الاشتراك

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

فيما يلي مثال:

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

إكمال مثال التكوين

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

مزايا الطلب الهاتفي

- مرونة أوسع لخيارات النقل.

- لا حاجة إلى فتح المنافذ لحركة مرور الإدارة الواردة.

- موازنة الأحمال والتجميع.

تقسيم التكوين للطلب في

في وضع الطلب الهاتفي، يدخل مجمع / مستقبل / تنسيق MDT إلى الموجه ويشترك ديناميكيا في مسار مستشعر واحد أو أكثر أو في اشتراكات. يعمل الموجه كخادم والعميل كجهاز إستقبال.

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

طلب بيانات تتبع الاستخدام

بما أن المجمع "dials-in" إلى الموجه، فلا حاجة لتحديد كل وجهة MDT في التكوين. قم فقط بتمكين خدمة gRPC على الموجه، واتصل عميلك، وقم بتمكين اشتراك تتبع الاستخدام الذي تريده بشكل ديناميكي.

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

1. تمكين gRPC

2. تحديد مجموعات المستشعر

3. تحديد الاشتراك

انقر للتوسيع (إبراز إلى القراءة)

وضع الطلب الهاتفي مدعوم فقط مع gRPC

وضع الطلب الهاتفي مدعوم فقط مع gRPC

تمكين gRPC

أولا، يلزمنا تمكين خادم gRPC على الموجه لقبول الاتصالات الواردة من المجمع.

انقر للتوسيع (إبراز إلى القراءة)

- يتراوح <port-number> بين 57344 و 57999. إذا كان رقم المنفذ غير متوفر، يتم عرض خطأ.

يتراوح <port-number> بين 57344 و 57999. إذا كان رقم المنفذ غير متوفر، يتم عرض خطأ.

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)#commit

RP/0/RP0/CPU0:XR(config-grpc)#end

RP/0/RP0/CPU0:XR#

تحديد مجموعات المستشعر

يحدد تكوين مجموعة المستشعر المعلومات التي سيتم تدفقها. يوفر قالب التكوين التالي التكوين المطلوب لتكوين مجموعات المستشعر.

يوضح المثال التالي المثال الفعلي من واجهة سطر الأوامر (CLI) للموجه حيث يوجد مثال حقيقي لتكوين مجموعة المستشعر

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path openconfig-interfaces:interfaces/interface

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end

RP/0/RP0/CPU0:XR#

تحديد الاشتراك

يعمل الاشتراك على ربط Sensor-Group و gRPC معا كالجزء الأخير من التكوين. يتم تحديد الفاصل الزمني العينة كجزء من الاشتراك.

يوفر قالب التكوين التالي التكوين المطلوب لتكوين الاشتراك.

يوضح المثال التالي مثالا فعليا من واجهة سطر الأوامر للموجه حيث نقوم بإنشاء اشتراك وربط مجموعة المستشعر ومجموعة الوجهة معا وكذلك تحديد معدل العينة.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

إكمال قالب التكوين ومثال

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

مزايا الطلب الهاتفي

- قناة واحدة للتهيئة والدفق

- منفذ الاستماع على الموجه/الجهاز

- اتصال عابر

- يتوفر حاليا gRPC/gNMI فقط

القياس عن بعد المستند إلى الحدث

في تتبع تتبع الأحداث، يتم تدفق البيانات من مجموعة البيانات التي تم الاشتراك فيها فقط عند حدوث حدث.

تكوين بيانات تتبع إستخدام الحدث

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

إكمال قالب التكوين ومثال الطلب الهاتفي

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path>

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group <Destination-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 <Destination-IP>  port <Destination-Port>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding <Encoding-Type>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol <Transport-Protocol>

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription <Subscription-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id <Destination-Group-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

يوضح المثال التالي المثال الفعلي من واجهة سطر الأوامر (CLI) للموجه.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#conf

RP/0/RP0/CPU0:XR(config)#

RP/0/RP0/CPU0:XR(config)#telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp

RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0

RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

إكمال قالب التكوين ومثال الطلب الهاتفي

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port <port-number>

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription <Subscription-Name>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0>

RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)#end

RP/0/RP0/CPU0:XR#

يوضح المثال التالي المثال الفعلي من واجهة سطر الأوامر (CLI) للموجه.

RP/0/RP0/CPU0:XR#

RP/0/RP0/CPU0:XR#config

RP/0/RP0/CPU0:XR(config)# grpc

RP/0/RP0/CPU0:XR(config-grpc)#port 57890

RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven

RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101

RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0

RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit

RP/0/RP0/CPU0:XR(config-model-driven-subs)# end

RP/0/RP0/CPU0:XR#

التحقق من بيانات تتبع الاستخدام باستخدام أوامر SHOW

من وجهة نظر الموجه، يمكننا التحقق من المعلمات التي تم تكوينها لكل مجموعة مستشعر ومجموعة وجهة والاشتراك

// ALL CONFIGURED SUBSCRIPTIONS

RP/0/RP0/CPU0:XR#show telemetry model-driven subscription

Subscription:  Subscription101          State: ACTIVE

-------------

Sensor groups:

Id                Interval(ms)        State

SensorGroup101    30000               Resolved

Destination Groups:

Id                Encoding            Transport   State   Port    IP

DestGroup101      self-describing-gpb tcp         Active  5432    172.16.128.3

// DETAILS ON A PARTICULAR SUBSCRIPTION

RP/0/RP0/CPU0:XR#show telemetry model-driven subscription Subscription101

Subscription:  Subscription101

-------------

State:       ACTIVE

Sensor groups:

Id: SensorGroup101

Sample Interval:      30000 ms

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:    Resolved

Destination Groups:

Group Id: DestGroup101

Destination IP:       172.16.128.3

Destination Port:     5432

Encoding:             self-describing-gpb

Transport:            tcp

State:                Active

Total bytes sent:     4893

Total packets sent:   1

Last Sent time:       2019-11-01 10:04:11.2378949664 +0000

Collection Groups:

------------------

Id: 1

Sample Interval:      30000 ms

Encoding:             self-describing-gpb

Num of collection:    5

Collection time:      Min:     6 ms Max:    29 ms

Total time:           Min:     6 ms Avg:    12 ms Max:    29 ms

Total Deferred:       0

Total Send Errors:    0

Total Send Drops:     0

Total Other Errors:   0

Last Collection Start:2019-11-01 10:06:11.2499000664 +0000

Last Collection End:  2019-11-01 10:06:11.2499006664 +0000

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR#

// ALL CONFIGURED DESTINATIONS

RP/0/RP0/CPU0:XR#show telemetry model-driven destination

Group Id        IP              Port    Encoding            Transport   State

-----------------------------------------------------------------------------

DestGroup101    172.16.128.3    5432    self-describing-gpb tcp         Active

RP/0/RP0/CPU0:XR#

// PARTICULAR DESTINATION

RP/0/RP0/CPU0:XR#show telemetry model-driven destination DestGroup101

Destination Group:  DestGroup101

-----------------

Destination IP:       172.16.128.3

Destination Port:     5432

State:                Active

Encoding:             self-describing-gpb

Transport:            tcp

Total bytes sent:     83181

Total packets sent:   17

Last Sent time:       2019-11-01 10:12:11.2859133664 +0000

Collection Groups:

------------------

Id: 1

Sample Interval:      30000 ms

Encoding:             self-describing-gpb

Num of collection:    17

Collection time:      Min:     5 ms Max:    29 ms

Total time:           Min:     6 ms Max:    29 ms Avg:    10 ms

Total Deferred:       0

Total Send Errors:    0

Total Send Drops:     0

Total Other Errors:   0

Last Collection Start:2019-11-01 10:12:11.2859128664 +0000

Last Collection End:  2019-11-01 10:12:11.2859134664 +0000

Sensor Path:          Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

RP/0/RP0/CPU0:XR#

// ALL CONFIGURED SENSOR GROUPS

RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group

Sensor Group Id:SensorGroup101

Sensor Path:        Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:  Resolved

// PARTICULAR SENSOR GROUPS

RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group SensorGroup101

Sensor Group Id:SensorGroup101

Sensor Path:        Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

Sensor Path State:  Resolved

RP/0/RP0/CPU0:XR#

مجموعة بيانات تتبع الاستخدام

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

- يجب تثبيت جهاز فك الترميز لأخذ الحزم الواردة وتمريرها من أجل مزيد من التخزين.

- يلزم وجود قاعدة بيانات للسلسلة الزمنية (المعروفة أيضا باسم TSDB) لتخزين المعلومات المتدفقة.

- ويلزم أيضا إستخدام أداة رسومية لعرض البيانات المأخوذة من قاعدة البيانات الداخلية.

يتجاوز النطاق لوصف مكدس المجموعات بالتفصيل. تتيح Cisco Crossworks Health Insights بيانات تتبع الاستخدام من دون لمس حيث يتم توفير الأجهزة تلقائيا بتكوين بيانات تتبع الاستخدام وإنشاء الجداول/المخططات في قاعدة بيانات من السلسلة الزمنية (TSDB). فهي تعمل على تبسيط النفقات العامة التشغيلية والمتعلقة بإدارة الشبكات لجمع البيانات وتنقيحها، وبالتالي السماح للمشغلين بالتركيز على أهداف أعمالهم. يسمح إستخدام مجمع مشترك لجمع بيانات أجهزة الشبكة عبر SNMP و CLI وقياس telemetry المستند إلى نموذج بتجنب تكرار البيانات وكذلك تقليل الحمل على الأجهزة والشبكة.

اعتبارات النشر للقياس عن بعد في شبكة

فيما يلي اعتبارات مختلفة ينبغي القيام بها أثناء تحليل نشر بيانات القياس عن بعد في شبكة.

تغيير المقياس

يمكن أن يقوم القياس عن بعد بدفق كمية كبيرة من البيانات ويوصى بالتفكير بعناية في جوانب قابلية التطوير.

دفق البيانات المطلوبة فقط

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

ضع في الاعتبار مقدار البيانات المتدفقة

ستحتاج الكمية الإجمالية لبيانات القياس عن بعد التي يتم تدفقها إلى النظر في النقاط التالية:

1. تخصيص عرض النطاق الترددي داخل الشبكة

2. جودة الخدمة

3. أداء تطبيقات/برامج إضافية مثل

- برنامج التجميع

- قاعدة بيانات السلسلة الزمنية

- التحليلات / برامج المحاكاة الافتراضية

4. يؤثر ترميز الكفاءة (الذي تمت مناقشته في القسم "إرشادات تصميم القياس عن بعد") تأثيرا مباشرا على كمية البيانات التي يتم تدفقها. يوصى باستخدام قاعدة بيانات عامة (GPB) مضغوطة حيثما كان ذلك ممكنا.

5. تؤثر فترة التحصيل مباشرة على جوانب متعددة بما في ذلك على سبيل المثال لا الحصر ما يلي.

1. إستخدام النطاق الترددي في الشبكة

2. متطلبات التخزين على قاعدة البيانات

3. أداء الجهاز في نقل البيانات

يوصى بتقييم تواتر التحصيل استنادا إلى متطلبات التطبيق.

ويوصى عموما بالنظر في تصفية البيانات غير المرغوب فيها في المصدر أو الوجهة باعتبار ذلك ممكنا. لدينا الخيار لتصفية البيانات غير المرغوب فيها. يمكن إجراء التصفية على مستويين: -

1. في المصدر - تعمل الأجهزة على تدفق البيانات.

2. في الوجهة - يقوم المجمع بتجميع البيانات وتصحيحها. (تتجاوز التصفية في مجمع نطاق هذا المستند)

يظهر المثال التالي البيانات التي يتم تصفيتها فقط لواجهات Gig المجمعة ضمن مسارات المستشعر بتطبيق أحرف البدل.

sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters

المراجع

https://blogs.cisco.com/sp/the-limits-of-snmp

https://blogs.cisco.com/sp/why-you-should-care-about-model-driven-telemetry

https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/telemetry/b-telemetry-cg-asr9000-61x.html