変更要約: 初版
6.4EEMとオーケストレーション
機器上で自律的に動くEEM（Embedded Event Manager）のアプレットを、event（何をトリガとするか＝syslogパターン/タイマ/CLI）とaction（何を実行するか）の対で読み解き、設定・トラブルシュート・データ収集の自動化に使えるようにします。あわせて外部からの構成管理を、エージェント型（Puppet/Chef＝常駐エージェントがプル）とエージェントレス型（Ansible＝SSHでプッシュ）として比較します。
自動化には機器の中で完結するものと外部から機器を統制するものの2系統があり、ENCORはこの両方を扱います。前者の代表がEEMで、機器自身が「特定の出来事が起きたら、この処理を実行する」というルールを持ち、外部サーバや人の介在なしに動くのが特徴です。深夜に一瞬だけ発生してすぐ消える障害の情報を採る、といった人が張り付けない場面で威力を発揮します。後者が構成管理ツールで、ここではエージェントを常駐させるか否かという設計上の分かれ道が問われます。どちらも「便利な道具」ではなく、要件（自律性が要るか・大規模な標準化が要るか・機器にソフトを入れられるか）から選ぶ対象として捉えます。
6.4.1EEMアプレット：eventとactionの対
- EEM（Embedded Event Manager）はIOS/IOS XE上で動く機器内蔵の自動化機構で、アプレットは
event manager applet <名前>で定義する。中身は必ずevent（いつ発火するか）とaction（何をするか）の対で構成され、actionには番号（実行順を決めるラベル）を付ける——番号は昇順に実行されるため、action 1.0→action 2.0のように並べる。外部サーバに依存せず機器単独で完結する点が最大の特徴。 - トリガ（event）の代表は3つ。
event syslog pattern "..."＝指定した正規表現に一致するsyslogが出た瞬間に発火（例：インタフェースのdown、隣接関係の喪失）。event timer cron/event timer watchdog＝時刻や周期で発火（定期的なデータ収集向け）。event cli pattern "..."＝特定のCLIコマンドが入力されたときに発火（危険なコマンドの記録や抑止）。「何をきっかけにしたいか」でこの3つを引き分ける。 - 処理（action）の代表は、
action 1.0 cli command "..."（機器上でCLIを実行——showによる情報採取や設定投入）、action 2.0 syslog msg "..."（自前のログを残す）、action 3.0 mail ...（通知）など。設定変更を伴うCLIを実行するにはcli command "enable"で特権に上がり、configure terminalに入るという手順をactionとして順に書く必要があり、アプレットにevent manager session cli username <user>等の実行権限の考慮も要る。
6.4.2外部からの構成管理：エージェント型とエージェントレス型
- エージェント型（Puppet・Chef）は、管理対象に常駐エージェント（ソフトウェア）を導入し、エージェント側が定期的にマスタへ問い合わせて設定を取りに行く（プル型）。常駐しているため「あるべき状態」からのずれを継続的に検知して自動修復（状態の収束）しやすい一方、全機器へのエージェント導入と維持が前提になる。
- エージェントレス型（Ansible）は、管理対象にソフトを入れず、制御ノードからSSH（ネットワーク機器ではAPIも）で接続して設定をプッシュ（プッシュ型）する。エージェントを入れられない/入れたくないネットワーク機器と相性がよく導入が軽いが、実行は制御ノードが動いたときだけなので、継続的なドリフト検知は定期実行の仕組みで補う必要がある。
- EEMと構成管理ツールは競合ではなく役割が違う。EEMはその機器で起きた出来事に即座に反応する自律動作（外部が落ちていても働く）に強く、Ansible等は多数の機器へ同じ標準構成を一斉に展開/検証するのに強い。「1台の中で即応したいのか、多数に横展開したいのか」で選び分けるのが判断の軸になる。
EEMはevent（トリガ）とaction（処理）の対として読み、event syslog pattern＝ログ一致で即発火／event timer＝時刻・周期／event cli pattern＝コマンド入力を引き分けられるようにしましょう。actionは番号の昇順に実行されます。構成管理はエージェント型（Puppet/Chef＝常駐・プル・状態収束）対 エージェントレス型（Ansible＝SSH・プッシュ・導入が軽い）の対比が頻出で、「常駐が要るか」「プルかプッシュか」の2軸で押さえます。
ある支店ルータで、深夜帯にWAN側インタフェースが数秒だけダウンして自動復旧する現象が週に数回起きています。翌朝にshowを打っても既に正常化しており、原因の手掛かりが残りません。運用チームは「毎晩、担当者が起きて待機する」案を出しましたが、これはEEMで解くべき典型例です。設計は「何を引き金にするか」から始めます——事象はインタフェースのダウンでsyslogが出るので、event manager applet WAN-FLAP を作り、event syslog pattern "%LINK-3-UPDOWN.*GigabitEthernet0/1.*down" としてログ一致を引き金にします。ここでevent timer cronを選ぶのは誤りで、障害の発生時刻が不定である以上、定期実行では発生の瞬間を捉えられません（採れるのは無関係な平常時のデータばかりになります）。次にactionですが、目的はその瞬間の状態を残すことなので、action 1.0 syslog msg "WAN flap detected - collecting"で記録の起点を残し、action 2.0 cli command "enable"で特権に上がり、action 3.0 cli command "show interface GigabitEthernet0/1"、action 4.0 cli command "show logging | last 50"のように順に情報を採取します。actionは番号の昇順に実行されるため、enableを後ろの番号に書くと特権が必要なコマンドが先に失敗します——番号は単なる名札ではなく実行順序そのものだという点が、アプレット診断で最も問われる箇所です。ここでもし「syslogを引き金にできるなら、そもそも外部のAnsibleで監視すればよいのでは」と考えたなら、EEMの本質的な利点を見落としています——EEMは機器の中で完結するため、WANが落ちて外部の制御ノードに到達できない状況でも動作します。まさに今回のように回線が落ちる障害では、外部からプッシュする仕組みはその瞬間に届きません。一方、この支店ルータ群200台に同じアプレットを配布したいという別の要件が出たなら、そこは構成管理ツールの出番です。ネットワーク機器にエージェントを常駐させたくない/できないのが通例なので、AnsibleがSSHで各機器へプッシュするエージェントレスの方式が素直で、導入も軽く済みます。逆に、サーバ群のようにエージェントを入れられ、かつ「あるべき状態」から外れたら継続的に自動修復したい要件であれば、PuppetやChefの常駐エージェントが定期的にマスタへ取りに行くプル型が適します。整理すると、EEM＝1台の中で出来事に即応する自律動作、Ansible＝多数へ標準構成を一斉プッシュ、Puppet/Chef＝常駐エージェントによる継続的な状態収束であり、この3つは置き換え合うものではなく、要件ごとに組み合わせるものです。
| 手段 | 動作の起点 | 常駐エージェント | 向く要件 |
|---|---|---|---|
| EEM（`event syslog pattern`） | 機器上のsyslog一致で即時 | 不要（機器内蔵） | 突発事象の瞬間のデータ収集・自動復旧 |
| EEM（`event timer`） | 時刻または周期 | 不要（機器内蔵） | 定期的な設定バックアップ・状態採取 |
| EEM（`event cli pattern`） | 特定CLIの入力 | 不要（機器内蔵） | 危険コマンドの記録・警告 |
| Ansible（エージェントレス） | 制御ノードからのプッシュ | 不要（SSH等で接続） | 多数の機器へ標準構成を一斉展開 |
| Puppet / Chef（エージェント型） | エージェントが定期的にプル | 必要（対象に導入） | あるべき状態からのずれを継続検知し収束 |
ひっかけ： 発生時刻が不定の突発障害にevent timerを使うのは誤りで、瞬間を捉えるにはevent syslog patternが必要です。またactionの番号は単なる名札ではなく実行順序で、enableを後ろに書くと特権が要るコマンドが先に失敗します。さらに「Ansibleはエージェント型」「Puppet/Chefはエージェントレス」は逆＝Ansibleはエージェントレスのプッシュ（SSH）、Puppet/Chefは常駐エージェントのプルです。そして「EEMは外部サーバが必要」も誤り＝機器内で完結するため、回線障害で外部に到達できない状況でも動作します。
6.4.3この節のまとめ
- EEMアプレットは
event（トリガ）とaction（処理）の対で読み、actionは番号の昇順に実行される——enable等の前提処理は若い番号に置く - トリガは
event syslog pattern＝ログ一致で即時／event timer＝時刻・周期／event cli pattern＝コマンド入力で引き分け、発生時刻が不定の突発事象にタイマは使わない - 構成管理はAnsible＝エージェントレス・SSHでプッシュ、Puppet/Chef＝常駐エージェントがプルして状態を収束。EEMは機器内で完結し外部到達不能でも動く点が本質的な差
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 支店ルータのWAN側インタフェースが週に数回、深夜に数秒だけダウンして自動復旧する。翌朝の調査では既に正常化しており手掛かりが残らない。障害発生時点の `show interface` 出力を自動採取したい。EEMアプレットの設計として最も適切なものはどれか。
Q2. 設定変更を伴うEEMアプレットを作成したところ、`action 1.0 cli command "configure terminal"` が失敗し、後続の設定投入も行われない。アプレットには `action 3.0 cli command "enable"` が含まれている。この不具合の原因として最も適切なものはどれか。
Q3. 200台のネットワーク機器へ標準設定を一斉展開したいが、機器へ追加ソフトウェアを常駐させることは運用ポリシーで認められていない。一方、別途管理するサーバ群では「あるべき状態」からのずれを継続的に検知して自動修復したい。この2つの要件に対する構成管理方式の組み合わせとして最も適切なものはどれか。