はじめに
こんにちは！
前回は全体構成編ということでシステム全体の構成を整理しました。
全体の流れや最終的なゴールは↓の記事を見てください！
【全体構成編】Zabbix × ServiceNow × AWX × Bedrockで障害初動対応を自動化してみた
今回はその続きとして、Zabbix設定編①を書いていこうと思います。
今回のゴール
Zabbix Proxy経由でCisco DevNet SandboxのNW機器を監視して、
インターフェースDownをZabbixで検知できる状態にすることをゴールとします。
このゴールが達成できると、次回の Webhook → Lambda連携 で
Zabbixを起点とした自動対応フローへつなげることができます。
今回の流れ
| # | 内容 |
|---|---|
| 1 | Zabbix Server / Zabbix Proxyの役割整理 |
| 2 | Cisco DevNet Sandbox Catalyst9000のLaunch |
| 3 | 監視対象ホストをZabbixに登録 |
| 4 | SSH Agent Itemで機器の状態を取得 |
| 5 | トリガーで障害条件・復旧条件を設定 |
| 6 | 障害/復旧の動作確認 |
構成図だと囲ってある部分が今回の対象になります！
Zabbix Server / Zabbix Proxyの役割を整理する
まずは、Zabbix Server と Zabbix Proxy の役割を整理します。
前回の記事でも少し触れましたが、今回の検証ではZabbixで検知したアラートを起点に、ServiceNowへのインシデント起票、AWX/Ansibleによるログ収集、Bedrockによる一次切り分けまでつなげています。
その連携のトリガーとなるのがZabbixです。
今回の構成では、Zabbix Serverだけで完結させずに、Zabbix Proxyも使っています。
Zabbix単体でもよかったのですが、どうせならAWSのVPC Peeringも触ってみようかなと思い結果としてProxy経由の構成としました！
あとですね、今回は 踏み台サーバとZabbix Proxyを同一インスタンスに同居 させてるんですよね。
どちらもパブリックサブネットに置く必要があるという共通点があるのと、またEC2建てて色々設定するのめんどくせぇーってことで、集約しちゃおう！となり兼任させてやりました。
本番環境では
役割分離の観点から、踏み台サーバとZabbix Proxyは別インスタンスにするのが一般的です。
今回は検証目的のため、これで行きます！
| コンポーネント | 役割 |
|---|---|
| Zabbix Server | 監視設定の管理、トリガー判定、Action実行、Webhook通知 |
| Zabbix Proxy 兼 踏み台サーバ | 監視対象に対する監視処理の中継、監視データの取得、Zabbix Serverへの送信 |
| 監視対象 | Cisco DevNet Sandbox上のNW機器 |
| Lambda | ZabbixからのWebhookを受けて、ServiceNow / AWX / Bedrock連携する仲介役 |
通信の流れ
[Cisco DevNet Sandbox]
↑ SSH (TCP 22) ← Zabbix Proxyから能動的に接続・コマンド実行
[Zabbix Proxy (パブリックサブネット / VPC-B)]
↓ Zabbix Protocol (TCP 10051) ← ProxyからServerへ監視データをPush
[Zabbix Server (プライベートサブネット / VPC-A)] ※VPC Peering経由
↓ Webhook (HTTPS)
[Lambda]
ポイント： ZabbixはProxyがServerに対してデータをPushする設計です。
そのため、ServerからProxyへの接続は不要で、セキュリティグループもProxy → Serverの方向だけ許可すれば成立する設計になってます。
Cisco DevNet Sandbox Catalyst9000のLaunch
ではZabbixの監視対象となるCisco機器を用意しましょう！
Cisco DevNet Sandboxは無料で使えるCisco機器の検証環境です。
以下のサイトにアクセスしてCatalyst9000を見つけたらLaunchをクリックします。
Cisco DevNet Sandbox
Review Summaryをクリックします
※Daysは使っていい期間となります。指定の日数が過ぎると使えなくなりますが、その時は再Launchすればまた使えますので今回はとりあえず2日にしておきます！
Activeになってますね！
小さいずんだもんのところをクリックすると詳細がみれますので hostname / password /username をメモっておきましょう！
試しにログインしてみます。
自宅ではWSL2インストールしてるのでWLS2のIPを確認します。
curl ifconfig.me
確認したIPをZabbix Proxy(踏み台サーバ)のセキュリティグループ、インバウンドルールに追加して許可しておきます。
終わったらZabbix Proxy(踏み台サーバ)経由でCisco DevNet Sandboxにログインします。
※WSL2にキーペアを置いておいてください
ssh -i <キーペアパス> \-o "ProxyCommand=ssh <キーペアパス> -W %h:%p ubuntu@<踏み台サーバパブリックIP>" \<username>@devnetsandboxiosxec9k.cisco.com
以下のメッセージが出るのでYesを入力してEnterしましょう！
Are you sure you want to continue connecting (yes/no/[fingerprint])?
パスワード聞かれるのでメモしたパスワードを使ってログインします
(username@devnetsandboxiosxec9k.cisco.com) Password:
ログイン出来たら次はZabbixでホスト登録します！
監視対象ホストをZabbixに登録する
※Proxyの登録とホストグループは前もって作成してます。
- ホスト名：devnetsandboxiosxec9k.cisco.com
- ホストグループ；NW
- インターフェース：エージェント
- DNS名：devnetsandboxiosxec9k.cisco.com
- 接続方法：DNS
- ポート：22
- 監視するもの：プロキシ
本当はSNMP監視したかったのですが、Cisco DevNet Always-On SandboxではSNMP（UDP 161）がインフラ側でブロックされているため、SSH Agent監視を代替としました。
そのため接続方法はDNSにしています。
SSH Agent ItemでCisco DevNet Sandboxの状態を取得する
次に、登録した監視対象ホストに対してSSH Agent Itemを作成します。
- 名前：Interface Status
- タイプ：SSHエージェント
- キー：ssh.run[interfaces]
- データ型：テキスト
- ホストインターフェース：devnetsandboxiosxec9k.cisco.com:22
- 認証方式：パスワード
- ユーザ名：メモしたusername
- パスワード：メモしたpassword
- 実行するスクリプト：show interfaces
作成できたら作成したアイテムのテストをしましょう！
アイテムをクリックするとテストボタンがあるのでそちらをクリックして値の取得とテストをクリックします。結果が返ってきたらOKです！
SSH Agent Itemとは
SSH Agent Itemは、Zabbix Proxy（またはServer）のプロセス自身がSSHクライアントとして動作し、監視対象に直接SSH接続してコマンドを実行します。エージェントを監視対象にインストールする必要がないため、NW機器のようにエージェントが入れられない機器の監視に向いています。
トリガーで障害条件と復旧条件を設定する
次に、SSH Agent Itemで取得した値をもとにトリガーを設定します。
- 名前：Cisco Interface Down検知
- 深刻度：重度の障害
- 正常イベントの生成：復旧条件式
- 障害の条件式：
find(/devnetsandboxiosxec9k.cisco.com/ssh.run[interfaces],,"like","GigabitEthernet1/0/1 is administratively down")=1
- 復旧条件式：
find(/devnetsandboxiosxec9k.cisco.com/ssh.run[interfaces],,"like","GigabitEthernet1/0/1 is administratively down")=0
設定できたら追加します。
障害/復旧条件式について
今回は、show interfaces の取得結果に GigabitEthernet1/0/1 is administratively down が含まれているかを判定しています。
この文字列が含まれている場合は 障害 、含まれなくなった場合は 復旧 として扱います。
find() 関数の引数について
| 引数 | 今回の値 | 意味 |
|---|---|---|
| 第1引数 | /devnetsandboxiosxec9k.cisco.com/ssh.run[interfaces] |
対象ホスト・アイテムキー |
| 第2引数 | （空） | 時間範囲。空の場合は最新値1件が対象 |
| 第3引数 | like |
検索方法（部分一致） |
| 第4引数 | GigabitEthernet1/0/1 is administratively down |
検索する文字列 |
=1 |
— | 文字列が含まれていれば1（True）を返す |
復旧条件式は =0（含まれなくなった = 復旧）としています。
障害/復旧動作確認
監視の準備が整ったので実際に動作確認してみましょう！
今回のトリガー条件は「GigabitEthernet1/0/1 が administratively down になったことを検知する」という設定です。
ただし、Cisco DevNet Sandbox のデフォルト状態では GigabitEthernet1/0/1 がすでに administratively down になっています。
このままでは「障害が発生した瞬間」を再現できないため、以下の流れで確認します。
-
no shutdownで正常状態（up）に戻す - その後
shutdownでインターフェースをDownさせる - Zabbixが障害を検知することを確認する
- 再度
no shutdownで復旧し、Zabbixが解決済みになることを確認する
それでは現在のインターフェース状態を確認しましょう。
show ip interface brief
Cat9k_AO_Sandbox#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES NVRAM up down
Vlan10 unassigned YES unset administratively down down
Vlan11 192.168.10.254 YES other down down
GigabitEthernet0/0 <管理IP> YES NVRAM up up
GigabitEthernet1/0/1 unassigned YES unset administratively down down
GigabitEthernet1/0/2 unassigned YES unset administratively down down
GigabitEthernet1/0/3 unassigned YES unset administratively down down
GigabitEthernet1/0/4 unassigned YES unset administratively down down
GigabitEthernet1/0/5 unassigned YES unset administratively down down
GigabitEthernet1/0/6 unassigned YES unset administratively down down
GigabitEthernet1/0/7 unassigned YES unset administratively down down
GigabitEthernet1/0/8 unassigned YES unset administratively down down
Cat9k_AO_Sandbox
GigabitEthernet1/0/1はDownになってますね！
一度no shutでUpさせます！
enable
conf t
interface GigabitEthernet1/0/1
no shutdown
もう一度インターフェースの確認します
Cat9k_AO_Sandbox#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES NVRAM up down
Vlan10 unassigned YES unset administratively down down
Vlan11 192.168.10.254 YES other down down
GigabitEthernet0/0 <管理IP> YES NVRAM up up
GigabitEthernet1/0/1 unassigned YES unset up up
GigabitEthernet1/0/2 unassigned YES unset administratively down down
GigabitEthernet1/0/3 unassigned YES unset administratively down down
GigabitEthernet1/0/4 unassigned YES unset administratively down down
GigabitEthernet1/0/5 unassigned YES unset administratively down down
GigabitEthernet1/0/6 unassigned YES unset administratively down down
GigabitEthernet1/0/7 unassigned YES unset administratively down down
GigabitEthernet1/0/8 unassigned YES unset administratively down down
Cat9k_AO_Sandbox#
Upになりました！
そしたらShutします。
conf t
interface GigabitEthernet1/0/1
shutdown
検知しましたね！
ではUpに戻そうと思います
no shutdown
解決済みとなりました！
まとめ
今回は、Zabbix Proxy経由でCisco DevNet SandboxのNW機器を監視し、インターフェースDownをZabbixで検知するところまで確認しました！
最初はSNMPで監視しようと思っていたのですが、Cisco DevNet Always-On SandboxではSNMPが使えなかったため、今回はSSH Agent Itemで show interfaces を実行する形を取りました。
検証環境として シンプルさを優先した構成 ですが、ZabbixでNW機器の状態を取得して
トリガーで障害判定する流れはできましたね！
次回はこのトリガーをZabbixのActionからWebhookでLambdaへ通知するところまでやろうと思います！