أستكشاف أخطاء IM وإصلاحها واختبارها

المقدمة

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

المتطلبات الأساسية

المتطلبات

يفترض هذا المستند أن القارئ على دراية بميزة مدير الحدث المضمن Cisco IOS/IOS XE. إذا لم تكن على دراية بهذه الميزة بالفعل، فيرجى قراءة نظرة عامة على ميزة EEM اولا.

تتطلب EEM على مجموعة المحولات Catalyst 9K مدخل DNA لمستوى ترخيص أساسيات الشبكة. ميزة الشبكة تدعم بشكل كامل تقنية الإدخال والإخراج.

المكونات المستخدمة

تتعلق المعلومات الواردة في هذا المستند بالإصدار 4.0 من IM كما تم تنفيذها على مجموعة المحولات Catalyst.

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

معلومات أساسية

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

التحقق من صحة EEM باستخدام أوامر show

تأكيد أن وحدات التوقيت نشطة

عند نشر برنامج نصي ل IM يتم تشغيله بواسطة مؤقت، إذا لم يتم تشغيل البرنامج النصي كما هو متوقع، تأكد من أن المؤقت نشط ويقوم بالتقييم.

خذ بعين الإعتبار هذه النصوص المسماة الإختبار والاختبار 3 على التوالي:

event manager applet test authorization bypass
event timer watchdog time 60
action 0010 syslog msg "Test script running"

event manager applet test3 authorization bypass
event timer watchdog name test3 time 300
action 0010 syslog msg "test3 script running"

• يستخدم البرنامج النصي الأول (الإختبار) جهاز ضبط مؤقت لمدة 60 ثانية (غير مسمى) لإطلاق البرنامج النصي.
• يستخدم النص الثاني (Test3) مؤقت جهاز مراقبة 300 ثانية يسمى Test3 لتشغيل النص.

يمكن عرض وحدات التوقيت التي تم تكوينها والقيمة الحالية لهذه وحدات التوقيت باستخدام الأمر show event manager statistics server.

مثال

Switch#show event manager statistics server
EEM Queue Information
                        Triggered Dropped Queue Queue Average
Client                  Events    Events  Size  Max   Run Time
-------------------------------------------------------------------------------
Call Home               5         0       0     64    0.021
EEM Applets             181       0       0     64    0.003
EEM IOS .sh Scripts     0         0       0     128   0.000
EEM Tcl Scripts         0         0       0     64    0.000
iosp_global_eem_proc    30        0       0     16    0.004
onep event service init 0         0       0     128   0.000

EEM Policy Counters
Name Value
-------------------------------------------------------------------------------


EEM Policy Timers
Name                      Type                  Time Remaining <-- EEM Countdown timer
-------------------------------------------------------------------------------
_EEMinternalname0         watchdog              53.328    <--- Unnamed timers receive an internal name - this timer is for the 'test' policy
_EEMinternalname1         watchdog              37.120
test3                     watchdog              183.232   <--- Named timers use their configured name - this is the named timed configured for policy 'test3'

تأكيد أحداث الإطلاق

كما هو موضح في القسم "تأكيد وحدات التوقيت" التي هي قسم نشط في هذا المستند، يقوم IOS XE بزيادة عمود "الأحداث التي تم تشغيلها" لصف عميل تطبيقات IM في إخراج خادم إحصائيات مدير أحداث العرض في كل مرة يتم فيها تشغيل تطبيق IM. للتحقق من أن برنامج IM النصي يعمل كما هو متوقع، قم بتنفيذ حدث المشغل الخاص بك عدة مرات وفحص إخراج خادم إحصائيات مدير الأحداث show لتأكيد هذه الزيادات في القيمة. إذا لم يتم تشغيل البرنامج النصي الخاص بك.

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

Switch#show event manager statistics server
EEM Queue Information
                        Triggered Dropped Queue Queue Average
Client                  Events    Events  Size  Max   Run Time
-------------------------------------------------------------------------------
Call Home               5         0       0     64    0.021
EEM Applets             183       0       0     64    0.003     <--- "Triggered Events" column is incremented by 2 due to 2 timers firing
EEM IOS .sh Scripts     0         0       0     128   0.000
EEM Tcl Scripts         0         0       0     64    0.000
iosp_global_eem_proc    30        0       0     16    0.004
onep event service init 0         0       0     128   0.000

EEM Policy Counters
Name Value
-------------------------------------------------------------------------------


EEM Policy Timers
Name                           Type            Time Remaining
-------------------------------------------------------------------------------
_EEMinternalname0              watchdog        56.215
_EEMinternalname1              watchdog        100.006
test3                          watchdog        126.117

ملاحظة: إذا لم يحدث ذلك، تحقق من البرنامج النصي للتحقق من وحدات التوقيت التي تم تكوينها.

سجل حدث المراجعة

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

تأملوا في هذا النص:

event manager applet test_manual authorization bypass
event none                                                 <-- manual trigger type for testing
action 0010 syslog msg "I am a manually triggered script!" <-- message that is printed when script runs 

يتم تشغيل هذا البرنامج النصي عند تنفيذ إدارة أحداث واجهة سطر الأوامر (CLI) التي تشغل TEST_MANUAL وطباعة رسالة syslog. بالإضافة إلى الإخراج في syslog، يمكن التحقق من تنفيذ هذا البرنامج النصي من خلال مراجعة إخراج أحداث محفوظات مدير الأحداث show كما هو موضح:

Switch#show event manager history events
No. Job Id Proc Status   Time of Event             Event Type           Name
1   5      Actv success  Fri Nov 6 15:45:07 2020   timer countdown      callback: Call Home process  <-- timer bases event that fired 
2   18     Actv success  Mon Nov 9 14:12:33 2020   oir                  callback: Call Home process
3   19     Actv success  Mon Nov 9 14:12:40 2020   oir                  callback: Call Home process
4   20     Actv success  Fri Nov13 14:35:49 2020   none                 applet: test_manual          <-- manually triggered event 

التحقق من صحة EEM مع المشغل اليدوي

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

event manager applet test_manual authorization bypass
event none
action 0010 syslog msg "I am a manually triggered script!"

قم بتشغيل البرنامج النصي يدويا باستخدام الأمر event manager run test_manual من موجه الأمر enable:

Switch#event manager run test_manual <-- Manually runs the script
Switch#show log <-- Check for the log from action 10.
*Oct 26 21:24:40.762: %HA_EM-6-LOG: test_manual: I am a manually triggered script!  <-- %HA_EM logs are from EEM events. The syslog confirms the script has run. 

اعتبارات عملياتية

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

يوضح هذا القسم كيفية التحقق من وجود هذه المشاكل الثلاثة الشائعة في برامج IM النصية:

1. CLI يفشل أمر: يفشل الأمر في التحليل وبالتالي يفشل في التنفيذ.
2. يتم تشغيل البرنامج النصي لفترة طويلة جدا: تحتوي البرامج النصية ل EEM على حد زمني افتراضي للتشغيل يبلغ 20 ثانية. إذا تم تجاوز هذا الوقت، يتوقف البرنامج النصي قبل تشغيل كل الأوامر.
3. يتم تشغيل النص بشكل متكرر: في بعض الأحيان قد يحدث حدث الإطلاق المستخدم من قبل النص التنفيذي بشكل متكرر، مما يتسبب في تشغيل النص بشكل سريع.  ومن المستحسن ان نضبط كم مرة وبأي معدل ينشب النص.

مشكلة: فشل تنفيذ أوامر CLI

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

event manager applet Data_Collection auth bypass 
event timer watchdog time 60
action 1.0 cli command "enable"
action 1.1 cli command "show clock | append flash:DataCollection.txt"
action 1.2 cli command "show interfaces breif | append flash:DataCollection.txt"
action 1.3 cli command "show ip route | append flash:Datacollection.txt"
action 1.4 cli command "show processes cpu sorted | exclude 0.0 | append flash:DataCollection.txt"
action 1.5 cli command "show platform hardware fed switch active qos stats internal cpu policer | append flash:DataCollection.txt"
action 2.0 syslog msg  "Data Capture Complete"

تم تشغيل التطبيق الصغير بنجاح، ولكن لم يتم إنشاء النتائج المتوقعة:

Switch#show logging | in Capture <--  Our script-generated syslog contains the string "Capture".
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection: Data Capture Complete <-- Action 2.0 successfully ran.

Switch#dir flash: | in .txt  <-- We only expected one .txt file, however two appear in flash:
32792 -rw- 36 Mar 11 2021 20:40:01 +00:00 DataCollection.txt
32798 -rw- 807 Mar 11 2021 20:40:01 +00:00 Datacollection.txt

Switch#more flash:DataCollection.txt <-- the output of our expected .txt file is empty except for the output of "show clock"
*20:40:01.343 UTC Thu Mar 11 2021

أستخدم واجهة سطر الأوامر (CLI) الخاصة بإجراء مدير الأحداث المضمنة debug للمساعدة في التحقق من البرنامج الصغير.

Switch#debug embedded event manager action cli

*Mar 11 20:40:01.175: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : CTL : cli_open called. <-- The applet is called.
*Mar 11 20:40:01.275: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch>
*Mar 11 20:40:01.275: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch>enable
*Mar 11 20:40:01.285: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch#
*Mar 11 20:40:01.285: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch#show clock | append flash:DataCollection.txt 
*Mar 11 20:40:01.396: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch#
*Mar 11 20:40:01.396: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch#show interfaces breif | append flash:DataCollection.txt
*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : show interfaces breif | append flash:DataCollection.txt <-- Here is our first problem. "brief" is misspelled, so the command does not run. 
*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : ^
*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : % Invalid input detected at '^' marker. <-- CLI parser failure

*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 
*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch#
*Mar 11 20:40:01.507: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch#show ip route | append flash:Datacollection.txt <-- This created the second .txt file. The file name is case-sensitive.

*Mar 11 20:40:01.618: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch#
*Mar 11 20:40:01.618: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch#show processes cpu sorted | exclude 0.0 | append flash:DataCollection.txt <-- This problem is less intuitive. 
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%           We see the output of the command within the debug output. The intention with this action was for the filtered output to be appended to file.
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process                            The problem is that the "exclude" argument reads everything beyond the pipe as the value that is to be excluded.
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 117 57246 448028 127 0.07% 0.05% 0.07% 0 Crimson config p                           The result is the full output of "show processes cpu sorted", which is expected behavior. A problem like this will likely not be evident in debugging.
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 2 4488 16816 266 0.07% 0.00% 0.00% 0 Load Meter                                     This underscores the importance of pre-production testing to ensure the script performs as expected.
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 173 829 44093 18 0.07% 0.00% 0.00% 0 SASRcvWQWrk2                                   The solution here is to avoid this type of syntax mistake by eliminating "| exclude 0.0." and would be obvious if the command were tested before implementation.
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 205 22271 1313739 16 0.07% 0.03% 0.00% 0 VRRS Main thread 
*Mar 11 20:40:01.729: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 467 238 2238 106 0.07% 0.01% 0.00% 0 Exec 

*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 81 12793 151345 84 0.07% 0.01% 0.00% 0 IOSD ipc task 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 232 22894 2621198 8 0.07% 0.03% 0.01% 0 IP ARP Retry Age 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 7 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 6 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 8 17 2804 6 0.00% 0.00% 0.00% 0 VIDB BACKGD MGR 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 9 33511 11402 2939 0.00% 0.03% 0.00% 0 Check heaps 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 12 0 2 0 0.00% 0.00% 0.00% 0 Timers 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 10 106 1402 75 0.00% 0.00% 0.00% 0 Pool Manager 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 14 439 42047 10 0.00% 0.00% 0.00% 0 IOSXE heartbeat 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 11 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 16 0 1 0 0.00% 0.00% 0.00% 0 DB Notification 

*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 5 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 18 0 3 0 0.00% 0.00% 0.00% 0 Graceful Reload 
*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : CTL : 20+ lines read from cli, debug output truncated

*Mar 11 20:40:01.730: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : IN : Switch#show platform hardware fed switch active qos stats internal cpu policer | append flash:DataCollection.txt 
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : show platform hardware fed switch active qos stats internal cpu policer | append flash:DataCollection.txt <-- Here, the syntax of the command was not properly parsed out before implementation. We are missing an argument between "qos" and "stats".
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT :                                             ^  <-- missing word queue
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : % Invalid input detected at '^' marker.        <-- CLI parser failure
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : 
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : OUT : Switch#
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection: Data Capture Complete <-- The syslog from Action 2.0 writes.
*Mar 11 20:40:01.941: %HA_EM-6-LOG: Data_Collection : DEBUG(cli_lib) : : CTL : cli_close called. <-- The applet closes out as expected after executing all configured actions.

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

المشكلة: تستغرق إجراءات IM وقتا أطول من الحد الأقصى لوقت التشغيل

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

event manager applet Capture 
event timer watchdog time 120     <-- 120 second countdown timer 
action 1.0 cli command "enable"
action 1.1 cli command "no monitor capture CPUCapture"
action 2.0 cli command "monitor capture CPUCapture control-plane in match any buffer circular" 
action 2.1 cli command "monitor capture CPUCapture start"
action 3.0 wait 45
action 4.0 cli command "monitor capture CPUCapture stop"
action 4.1 cli command "show clock | append flash:CPUCapture.txt"
action 4.2 cli command "show mon cap CPUCapture buff dump | append flash:CPUCapture.txt"
action 5.0 syslog msg "CPUCapture Complete - Next capture in 2 minutes"

ويمكنكم بسهولة ان تقرروا ان إدخال المعلومات غير كامل كما هو متوقع. فحصت محلي سجل ل ال syslog من إجراء 5.0.  يطبع هذا syslog على كل تكرار ناجح للتطبيق. لم تتم طباعة السجل داخل المخزن المؤقت ولم تتم كتابة الملف CPUCapture.txt إلى flash:

Switch#show logging | include "CPUCapture Complete"

Switch#dir flash: | include CPUCapture.txt

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

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

Switch#debug event manager action cli

*Jan 28 22:55:54.742: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : CTL : cli_open called. <-- This is the initial message seen when the applet is called.
*Jan 28 22:55:54.843: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : CoreSwitch>          The applet name can be seen within the line.
*Jan 28 22:55:54.843: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : IN : CoreSwitch>enable
*Jan 28 22:55:54.854: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : CoreSwitch#
*Jan 28 22:55:54.854: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : IN : CoreSwitch#no monitor capture CPUCapture
*Jan 28 22:55:54.964: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : Capture does not exist
*Jan 28 22:55:54.964: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : 
*Jan 28 22:55:54.964: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : CoreSwitch#
*Jan 28 22:55:54.965: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : IN : CoreSwitch#monitor capture CPUCapture control-plane in match any buffer circular
Jan 28 22:55:55.075: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : CoreSwitch#
*Jan 28 22:55:55.075: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : IN : CoreSwitch#monitor capture CPUCapture start
*Jan 28 22:55:55.185: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : Started capture point : CPUCapture <-- The applet successfully creates and starts the capture.
*Jan 28 22:55:55.185: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : OUT : CoreSwitch#
*Jan 28 22:56:15.187: %HA_EM-6-LOG: Capture : DEBUG(cli_lib) : : CTL : cli_close called. <-- After 20 seconds, cli_close is called and the applet begins to exit.
*Jan 28 22:56:15.187: fh_server: fh_io_ipc_msg: received msg FH_MSG_CALLBACK_DONE from client 27 pclient 1
*Jan 28 22:56:15.187: fh_io_ipc_msg: EEM callback policy Capture has ended with abnormal exit status of 0xFFFFFFFFFFFFFFFF
*Jan 28 22:56:15.187: EEM policy Capture has exceeded it's elapsed time limit of 20.0 seconds <-- We are informed that the policy has exceeded its elapsed time limit. The default value is 20 seconds.
*Jan 28 22:56:15.187: fh_io_ipc_msg: received FH_MSG_API_CLOSE client=27
*Jan 28 22:56:15.187: tty is now going through its death sequence

*Note "debug event manager all" is used to enable all debugs related to event manager.

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

مثال

event manager applet Capture 
event timer watchdog time 120 maxrun 60  <-- Maxrun 60 specifies the capture will run for a maximum of 60 seconds. 
action 1.0 cli command "enable"
action 1.1 cli command "no monitor capture CPUCapture"
action 2.0 cli command "monitor capture CPUCapture control-plane in match any buffer circular" 
action 2.1 cli command "monitor capture CPUCapture start"
action 3.0 wait 45                      <-- The altered maxrun allows the capture to run for the necessary time.
action 4.0 cli command "monitor capture CPUCapture stop"
action 4.1 cli command "show clock | append flash:CPUCapture.txt"
action 4.2 cli command "show mon cap CPUCapture buff dump | append flash:CPUCapture.txt"
action 5.0 syslog msg "CPUCapture Complete - Next capture in 2 minutes"

المشكلة هي أن "م.م.م" غالبا ما يثيرون

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

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

event manager applet MonitorLinkFlap
event syslog pattern "Interface GigabitEthernet1/0/23, changed state to down"
action 1.0 cli command "enable"
action 1.1 cli command "show ip route | append flash:MonitorLinkFlap.txt "
action 2.0 cli command "show interface gig1/0/23 | append flash:MonitorLinkFlap.txt"
action 3.0 cli command "show process cpu sorted | append flash:MonitorLinkFlap.txt"
action 4.0 cli command "show platform hardware fed active fwd-asic drops exceptions | append flash:MonitorLinkFlap.txt"
action 5.0 syslog msg "Link has flapped - Data gathered"

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

Switch#sh log | in Data gathered
*Jan 29 04:19:06.678: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered <-- The applet generates this syslog each time it fires.
*Jan 29 04:19:27.367: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:19:36.779: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:19:57.472: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:20:06.570: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:20:27.671: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:20:36.774: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered
*Jan 29 04:20:57.264: %HA_EM-6-LOG: MonitorLinkFlap: Link has flapped - Data gathered

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

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

الحل: تطبيق حد المعدل للتحكم في سرعة تشغيل التطبيق الصغير. يتم إلحاق الكلمة الأساسية RateLimit بجملة المشغل وتقترن بقيمة بالثواني.

مثال

event manager applet MonitorLinkFlap 
event syslog pattern "Interface GigabitEthernet1/0/23, changed state to down" ratelimit 60 <-- Ratelimit 
    
    
      specifies a minimum amount of time that must pass before the applet will again trigger. 
    
action 1.0 cli command "enable"
action 1.1 cli command "show clock | append flash:MonitorLinkFlap.txt "
action 2.0 cli command "show interface gig1/0/23 | append flash:MonitorLinkFlap.txt"
action 3.0 cli command "show process cpu sorted | append flash:MonitorLinkFlap.txt"
action 4.0 cli command "show platform hardware fed active fwd-asic drops exceptions | append flash:MonitorLinkFlap.txt"
action 5.0 syslog msg "Link has flapped - Data gathered"

معلومات ذات صلة

مدير الحدث المضمن IOS 4.0 من Cisco

أفضل الممارسات والنصوص المفيدة