시스코 살펴보기
구매 방법

계정이 있습니까?

  •   맞춤형 콘텐츠
  •   제품 및 지원

계정이 필요하십니까?

계정 만들기

EEM 스크립트 문제 해결 및 테스트

다운로드 옵션

  • PDF     (159.6 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (83.7 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (78.3 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2021년 3월 31일 (수)
문서 ID:217013

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

    소개

    이 문서에서는 EEM(Embedded Event Manager) 스크립트 검증에 대해 설명하고 일반적인 운영 고려 사항 및 오류 시나리오를 소개합니다.

    사전 요구 사항

    요구 사항

    이 문서에서는 독자가 Cisco IOS/IOS-XE EEM(Embedded Event Manager) 기능을 이미 알고 있다고 가정합니다.이 기능에 대해 잘 모르는 경우 EEM 기능 개요 먼저

    Catalyst 9K 스위치 제품군의 EEM에는 Network Essentials 라이센스 수준에 대한 DNA 주소가 필요합니다.Network Advantage는 EEM을 완벽하게 지원합니다.

    사용되는 구성 요소

    이 문서의 정보는 Catalyst 스위치 제품군에 구현된 EEM 버전 4.0과 관련이 있습니다.

    이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.

    배경 정보

    EEM은 효과적으로 구축할 때 유용한 기능이지만 EEM이 작성자가 의도한 대로 정확히 수행되도록 하는 것이 중요합니다.스크립트가 제대로 검증되지 않으면 생산 과정에서 심각한 문제가 발생할 수 있습니다.최상의 경우 스크립트는 원하지 않는 방식으로 수행됩니다.이 문서에서는 CLI show 명령을 사용하여 EEM을 테스트하고 확인하는 방법에 대한 유용한 정보를 제공하며, 몇 가지 일반적인 오류 시나리오와 문제를 식별하고 수정하는 데 사용되는 디버그에 대해서도 설명합니다.

    show 명령을 사용한 EEM 검증

    타이머가 활성 상태인지 확인

    타이머에 의해 트리거되는 EEM 스크립트가 구축된 경우 스크립트가 예상대로 실행되지 않으면 타이머가 활성 상태이고 카운트다운이 중지되었는지 확인합니다.

    각각 test 및 test3라는 EEM 스크립트를 고려합니다.

    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초(명명되지 않은) watchdog 타이머를 사용하여 스크립트를 실행합니다.
    • 두 번째 스크립트(test3)는 test3이라는 300초 watchdog 타이머를 사용하여 스크립트를 실행합니다.

    '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는 EEM 애플릿이 실행될 때마다 'show event manager statistics server'의 출력에 'EEM 애플릿' 클라이언트 행의 '트리거된 이벤트' 열을 증가시킵니다.EEM 스크립트가 예상대로 작동하는지 확인하려면 트리거 이벤트를 여러 번 수행하고 'show event manager statistics server'의 출력을 검사하여 이 값 증분을 확인합니다.그렇지 않으면 스크립트가 트리거되지 않습니다.

    명령이 순서대로 여러 번 실행되면 카운트다운할 타이머 값이 계산됩니다.타이머가 0을 반복하고 스크립트가 실행되면 EEM 애플릿에 대해 트리거된 이벤트 카운트도 증가합니다.

    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 history events' 명령을 사용하면 애플릿이 예상대로 트리거되는지 확인하는 데 유용합니다.

    다음 EEM 스크립트를 고려하십시오.

    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 "event manager run test_manual"이 실행되고 syslog 메시지가 인쇄될 때 실행됩니다.syslog의 출력 외에도, 다음과 같이 'show event manager history events' 출력을 검토하여 이 스크립트 실행을 확인할 수 있습니다.

    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 검증

    실행 흐름을 테스트하거나 일회성 작업을 수행하기 위해 EEM 스크립트를 수동으로 트리거하는 것이 좋은 시나리오가 있습니다.이 출력에 표시된 대로 'event none' 트리거가 있는 EEM 스크립트를 사용하여 이 작업을 수행할 수 있습니다.

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

    enable 프롬프트에서 'event manager run test_manual' 명령을 사용하여 스크립트를 수동으로 실행합니다.

    Switch#show log
    *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

    운영 고려 사항

    프로덕션 환경에서 사용하기 전에 EEM 스크립트가 검증되었는지 확인합니다.일반적으로 스크립트에서 예상대로 작동하지 않는 몇 가지 기본 방법이 있으며, 이 중 3가지 방법이 여기에서 설명합니다.

    이 섹션에서는 EEM 스크립트에서 다음과 같은 세 가지 일반적인 문제를 확인하는 방법을 보여줍니다.

    • CLI 명령 실패: 명령이 구문 분석되지 않아 실행되지 않음
    • 스크립트가 너무 오래 실행됩니다. EEM 스크립트의 기본 실행 시간 제한은 20초입니다.이 시간이 초과되면 모든 명령이 실행되기 전에 스크립트가 중지됩니다.
    • 스크립트가 너무 자주 실행됩니다. 스크립트에서 사용하는 트리거 이벤트가 너무 자주 발생하여 스크립트가 빠르게 실행됩니다.  스크립트가 실행되는 빈도 및 속도를 제어할 수 없습니다.

    문제/장애:CLI 명령을 실행하지 못함

    이 예제 스크립트에는 몇 가지 문제가 포함되어 있습니다.여러 show 명령의 출력을 로컬 플래시 미디어의 텍스트 파일에 추가하는 간단한 애플릿입니다.

    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 
    *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

    "debug embedded event manager action cli"를 사용하여 애플릿 확인을 지원합니다.

    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.

    결론:모든 EEM 작업을 올바르게 검사하고 디버그를 사용하여 잘못된 구성 및 입력 오류를 방지합니다.

    문제/장애:EEM 작업이 최대 런타임보다 오래 걸립니다.

    이 시나리오에서는 단순 EEM을 사용하여 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"

    EEM이 예상대로 완료되지 않았음을 쉽게 확인할 수 있습니다.작업 5.0에서 syslog에 대한 로컬 로그를 확인합니다.  이 syslog는 애플릿의 성공적인 반복에 대해 인쇄됩니다.로그가 버퍼 내에 인쇄되지 않았으며 "CPUCapture.txt" 파일이 플래시에 기록되지 않았습니다.

    Switch#show logging | include "CPUCapture Complete"

    Switch#dir flash: | include CPUCapture.txt

    조사할 디버그를 활성화합니다.가장 일반적으로 사용되는 디버그는 디버그 이벤트 관리자 작업 cli입니다.이 유틸리티는 작업 대화 상자를 순서대로 인쇄합니다.

    디버그 출력:디버그 출력에는 성공적으로 호출된 애플릿이 표시됩니다.초기 작업은 문제 없이 실행되지만 캡처가 마무리되지 않습니다.

    Switch#debug embedded 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

    해결책:기본적으로 EEM 정책은 20초 이내로 실행됩니다.EEM 내의 작업을 실행하는 데 20초 이상 걸리는 경우 EEM이 완료되지 않습니다.EEM의 런타임이 애플릿 작업을 실행할 수 있도록 충분한지 확인합니다.보다 적절한 최대 런타임 값을 지정하도록 "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"

    문제/장애:EEM이 너무 자주 트리거됨

    지정된 트리거의 여러 인스턴스가 짧은 시간 내에 발생할 수 있습니다.이 경우 애플릿의 과도한 반복이 발생할 수 있으며 최악의 경우 심각한 결과가 발생할 수 있습니다.

    이 애플릿은 특정 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

    이 애플릿은 몇 분 동안 여러 번 실행되어 외부 데이터가 포함된 원치 않는 출력 파일이 생성되었습니다.또한 파일의 크기가 계속 증가하며 로컬 미디어를 계속 채웁니다.이 간단한 예제 EEM은 반복적으로 실행되는 경우 운영 위협을 많이 나타내지 않지만, 이 시나리오는 더 복잡한 스크립트로 인해 충돌이 발생할 수 있습니다.

    이 시나리오에서는 애플릿이 트리거되는 빈도를 제한하는 것이 좋습니다.

    해결책:"속도 제한"을 적용하여 애플릿의 실행 속도를 제어합니다."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"

    참조

    Cisco IOS Embedded Event Manager 4.0

    EEM을 위한 모범 사례 및 유용한 스크립트

    TAC Authored

    Cisco 엔지니어가 작성

    • Jason Babb
      Cisco TAC

    이 문서가 도움이 되셨습니까?

    Feedback피드백

    지원 문의

    이 문서가 적용되는 제품