購入する または契約更新する
購入する または契約更新する
キャンセル
提案をオンにする
自動提案では、入力時に可能な一致が提案されるので検索結果を素早く絞り込むことができます。
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
新しい記事を作成する
778
閲覧回数
10
いいね！
0
コメント

NSO: Kicker でアクションを自動実行する

Tomonobu Okada
Cisco Employee
Cisco Employee

‎2018-01-13 11:32 PM ‎2018-01-13 11:46 PM 更新

 

Kicker とは

Kicker は NSO 4.2 から導入された新機能で、CDB の変更や Netconf notification をトリガーにして action を起動する仕組みを提供するものです。以前のバージョンから存在していた CDB subscriber とほぼ同等の機能ですが、トリガーの定義やアクションを起動するロジックをコーディングすることなくコンフィグとして定義できるのでより簡単に実装できるというメリットがあります。

Kicker には data-kicker と notification-kicker があります。

data-kicker
CDB subscriber とほぼ同じです。CDB の変更をモニターしてアクションを実行することができます。

notification-kicker
Southbound デバイスから送られてくる Netconf notificaiton をトリガーにしてアクションを実行することができます。Kicker が実装される前は、受信した notification を CDB に格納しそのパスを CDB subscriber によってモニターする必要がありました。notification-kicker を使用すると受信した nofiticaiton を CDB に格納する必要はありませんし CDB subscriber も不要になります。

Kicker はデフォルトで hidden に設定されていますので、CLI で見えるようにするには unhide する必要があります。まず ncs.conf に以下の設定を追加します。

<hide-group>
 <name>debug</name>
</hide-group>

ncs --reload で設定を適用後、以下の CLI コマンドで unhide してください。

admin@ncs(config)# unhide debug
admin@ncs(config)#

これで kicker が見えるようになります。

admin@ncs(config)# kickers
Possible completions:
 data-kicker
 notification-kicker This list contains declared notification kickers.
 send-kicker-triggered Kicker action to Send a kicker-triggered notification

 

Data Kicker

Data Kicker は以下のフォーマットで記述します。

admin@ncs(config)# kickers data-kicker e1 \
> monitor /sys/ifc[name='port-0'] \
> kick-node /sys/ifc[name='port-0']\
> action-name local_me
  • monitor: モニターするノードです。このノードのサブツリーに変更があった場合アクションを kick します。
  • kick-node: ここで定義されるノード配下のアクションが kick されます。
  • action-name: 起動するアクションです。

さらに trigger-expr を定義してより細かくアクションを起動する条件を設定することもできます。

admin(config)# kickers data-kicker k1 monitor /sys/ifc \
> trigger-expr "hw/mtu > 800" \
> trigger-type enter \
> kick-node /sys \
> action-name kick_me

monitor に設定している /sys/ifc に変更があった場合 trigger-expr が評価されます。上記の例では"hw/mtu > 800" が true であればアクションが実行されます。実行の挙動は trigger-type でコントロールでき、enter だと false から true になった場合のみ、enter-and-leave だと true から false になった場合もアクションが実行されます。

また、以下のように variable を使用することもできます。

admin@ncs(config)#kickers data-kicker k3 monitor $PATH/c
 kick-node /x/y[id='n1']
 action-name kick-me
 variable PATH value "/a/b[k1=3][k2='3']"

上記の例では PATH という variable にパスを設定し、monitor 内で $PATH として参照しています。

NSO インストールディレクトリ 配下の examples.ncs/web-server-farm/web-site-service が Kicker の
サンプルとなっていますので、試しに実行してみます。README_KICKER に Kicker の説明とサンプルの実行手順が記載されています。ここでは実行手順に従って実行してみます。(事前に source ncsrc を実行してください。本記事では NSO 4.4.4 を使用しています。)

まずラボを起動し CLI を接続します。

make all
make start
ncs_cli -u admin -C

kicker が CLI で見えるようにするために unhide します。

admin@ncs# config
admin@ncs(config)# unhide debug

sync-from を実行します。

admin@ncs# devices sync-from
sync-result {
 device lb0
 result true
}
sync-result {
 device www0
 result true
}
sync-result {
 device www1
 result true
}
sync-result {
 device www2
 result true
}

Data Kicker を作成します。

admin@ncs(config)# kickers data-kicker a1 monitor /services/properties/wsp:web-site/profile kick-node /services/wse:actions action-name diffcheck
admin@ncs(config-data-kicker-a1)# commit

この設定例では /services/properties/wsp:web-site/profile をモニターし、変更があれば /services/wse:actions の diffcheck アクションを実行します。diffcheck アクションは本サンプルに含まれているもので、トランザクションにアタッチして diffiterate を実行し変更内容を表示します。

それでは kicker が実行されるように monitor のパスに変更を加えてみます。Kicker の実行の様子は commit にパイプして debug kicker を付けることで確認できます。

admin@ncs(config)# services properties web-site profile lean lb lb0
admin@ncs(config-profile-lean)# commit | debug kicker
kicker: a1 at /ncs:services/ncs:properties/wsp:web-site/wsp:profile[wsp:name='lean'] changed, invoking diffcheck
Commit complete.

期待通り diffcheck が実行されました。ncs-java-vm.log でも diffcheck の出力が確認できます。

-------------------
{[669406386|kicker-id], a1}
{[669406386|path], /ncs:services/properties/web-site/profile{lean}}
{[669406386|tid], 126}
path = /ncs:services/properties/wsp:web-site/profile{lean}
op = MOP_CREATED
newValue = null
path = /ncs:services/properties/wsp:web-site/profile{lean}/name
op = MOP_VALUE_SET
newValue = lean
path = /ncs:services/properties/wsp:web-site/profile{lean}/lb
op = MOP_VALUE_SET
newValue = lb0

 

Notification Kicker

Notification Kicker は以下のフォーマットで記述します。

admin@ncs(config)# kickers notification-kicker k4 \
> selector-expr "$NOTIFICATION_NAME=linkUp and address[ip=$IP]" \
> kick-node /x/y[id='n1'] \
> action-name kick-me \
> variable IP value '192.168.128.55'

ほぼ Data Kicker と同様ですが、monitor ではなく selector-expr を使用してどの Netconf notification を対象とするか定義します。前提として /devices/device/netconf-notification/subscription でサブスクリプションの設定がされていて Netconf notification を受信できる状態である必要があります。以下の predefined variables が使用可能ですので、これらを使用してトリガーとなる notification をフィルターすることができます。

DEVICE
The name of the device emitting the current notification.

SUBSCRIPTION_NAME
The name of the current subscription from which the notification was received. the kicker

NOTIFICATION_NAME
The name of the current notification.

NOTIFICATION_NS
The namespace of the current notification.

ここで使用するサンプルは Data Kicker と同様の web-site-service です。起動までの手順は同じですのでここでは割愛し、kicker を設定するところから始めます。

admin@ncs(config)# kickers notification-kicker n1 selector-expr "$SUBSCRIPTION_NAME = 'mysub'" kick-node /services/wse:actions action-name diffcheck
admin@ncs(config-notification-kicker-n1)# commit

この例ではサブスクリプションの名前が mysub の notification を受信した場合に diffcheck を実行します。このサンプルラボでは各デバイスが定期的に Netconf notification を送信する仕様になっていますので、サブスクリプションを設定すればすぐに Kicker が実行されます。

admin@ncs(config)# devices device www0 netconf-notifications subscription mysub local-user admin stream interface
admin@ncs(config-subscription-mysub)# commit

ncs-java-vm.log でも実行の出力が確認できます。

-------------------
{[669406386|kicker-id], n1}
{[669406386|path], /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0}/data/linkUp}
{[669406386|tid], 185}
path = /ncs:devices/device{www0}
op = MOP_MODIFIED
newValue = null
path = /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0}
op = MOP_CREATED
newValue = null
path = /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0}/event-time
op = MOP_VALUE_SET

 

Sample package

最後に簡単なオリジナルパッケージを作成してみます。Cisco StarOS の新しいバージョンでは logging を Netconf notification として送信する機能がありますので、特定のログを受信したら任意の show コマンドを実行してタイムリーにログを取得するというものです。

まずはスケルトンパッケージを作成します。ここでは python を使用します。

ncs-make-package --service-skeleton python pyservice

任意のコマンドを実行できるように、pyservice/src/yang/pyservice.yang に command ノードを追加します。

// may replace this with other ways of refering to the devices.
 leaf device {
 type leafref {
 path "/ncs:devices/ncs:device/ncs:name";
 }
 }

// command to execute
 leaf-list command {
 type string;
 }

pyservice/python/pyservice/main.py の cb_create を以下のように定義します。サービスと同じ名前の Kicker が存在する場合のみ command で定義されたコマンドをデイバスに対して実行し、ログに残します。Kicker が存在しない場合は何もせず終了します。

@Service.create
 def cb_create(self, tctx, root, service, proplist):
 self.log.info('Service create(service=', service._path, ')')

service_name = service.name
 if service_name not in root.kickers.notification_kicker:
 self.log.info('kicker for this service does not exist.')
 return
 dev = root.devices.device[service.device]
 input = dev.live_status.staros_exec.staros_exec__exec.get_input()
 input.args = service.command
 result = dev.live_status.staros_exec.staros_exec__exec(input)
 self.log.info(result.result)

対象の notification は以下とします。ポートがダウンしたことを示すものです。

data event facility csp
 data event id 7207
 data event severity 3
 data event critical-info true
 data event text "2018-Jan-12+19:12:28.411 [csp 7207 warning] [1/0/5701 <cspctrl:0> spctrl_events.c:11887] [port: 1/10] [hardware external system critical-info syslog] Port link down"

まずはサービスを作成します。取得するコマンドは show port utilization table を指定しています。

admin@ncs(config)# pyservice ps1 device ssi command "show port utilization table"
admin@ncs(config-pyservice-ps1)# commit

この時点では Kicker が存在しないため何も実行しません。

ncs-python-vm-pyservice.log
 2018-01-13 19:10:59 - pyservice - INFO - kicker for this service does not exist.

Kicker を設定します。上記のログをフィルターするために、id を指定しています。また、コード内で同じ名前の Kicker を条件として探すため、名前はサービスと同じである必要があります。

admin@ncs(config)# kickers notification-kicker ps1 selector-expr id=7207 kick-node /pyservice[name='ps1'] action-name reactive-re-deploy
admin@ncs(config-notification-kicker-ps1)# commit

Netconf notification のサブスクリプションは以下のように設定済みです。

netconf-notifications subscription foo
 stream StarOS
 local-user admin

それでは Netconf notification を送ってみます。マニュアルでインターフェースを shutdown します。

[local]qvpc-si# configure
[local]qvpc-si(config)# port ethernet 1/10
[local]qvpc-si(config-port-1/10)# shut

Kicker が正しく動作し、以下のようにコマンド出力がログに保存されました。

ncs-python-vm-pyservice.log
2018-01-13 20:04:30 - pyservice - INFO - Service create(service=/pyservice:pyservice{ps1})
2018-01-13 20:04:30 - pyservice - INFO - ------ Average Port Utilization (in mbps) ------
Port Type Current 5min 15min
 Rx Tx Rx Tx Rx Tx
----- ------------------------ ------- ------- ------- ------- ------- -------
 1/1 Virtual Ethernet 0 0 0 0 0 0
 1/10 Virtual Ethernet 0 0 0 0 0 0
 1/11 Virtual Ethernet 0 0 0 0 0 0
 1/12 Virtual Ethernet 0 0 0 0 0 0
 1/13 Virtual Ethernet 0 0 0 0 0 0

今回は簡単な例ですが、何かの障害に応じて必要なリカバリアクションを実行したりログ取得を実施したりするようなもう少し複雑なアプリケーションも作成可能ですので、ぜひお試しください。

 

リファレンス

Kicker に関しては以下のデータソースがありますので、参照してみてください。

  • NSO Development Guide の Kicker セクション
  • examples.ncs/web-server-farm
  • examples.ncs/getting-started/developing-with-ncs/21-kicker
  • src/ncs/yang/tailf-kicker.yang
ラベル：
Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします

Customers Also Viewed These Support Documents