vSphere APIでVMのpower_stateを監視し、POWERED_OFF時にZabbixからEmail通知する


検証の概要

vSphere APIを使って特定のVMのpower_stateを定期的に取得し、VMがPOWERED_ONになった際にZabbixからEmail通知を送信します。

今回の構成では、ZabbixのScript ItemでvCenter APIを2段階で呼び出し、対象VMのpower_stateを取得します。その後、Zabbixのトリガー機能でpower_stateの値を評価し、トリガーアクションで事前に設定したユーザにメール通知を発報します。

1. POST /api/session → APIセッションTokenを発行 2. GET /api/vcenter/vm/{vm} → 対象VMの power_state を取得 3. Zabbix Dependent item → レスポンスから power_state を抽出 4. Trigger + Action → POWERED_ON検知でEmail送信

利用するvSphere APIについて

APIでTokenを発行する

vSphere Automation APIのセッションエンドポイントに、Basic認証でアクセスします。以下は動作確認用の例です。パスワードはコマンドへ直接記述せず、環境変数や秘密情報管理機能から渡すことを推奨します。

bash

VCENTER_URL='https://vcenter01.demo.local'
VCENTER_USER='administrator@vsphere.local'
read -rsp 'vCenter password: ' VCENTER_PASSWORD
printf '\n'

ACCESS_TOKEN=$(curl -ks -X POST "${VCENTER_URL}/api/session" \
  -H 'Content-Type: application/json' \
  -u "${VCENTER_USER}:${VCENTER_PASSWORD}" \
  | tr -d '"')

/api/sessionのレスポンスは、JSON文字列としてTokenを返します。tr -d '"'は、レスポンスの前後にある引用符を取り除くために使用しています。

ラボ環境であるため、-kによるTLS証明書検証の無効化を利用しています

対象VMのpower_stateを取得する

今回は、VM名ではなくMOID形式のvm-55009を指定します。

VM情報はGET /api/vcenter/vm/{vm}で取得します。セッションTokenは、先のAPIで取得したTokenを、リクエストヘッダーのvmware-api-session-idに指定します。

bash

curl -ks -X GET \
  'https://vcenter01.demo.local/api/vcenter/vm/vm-55009' \
  -H "vmware-api-session-id: ${ACCESS_TOKEN}"

power_stateには、主に次の値が返ります。

  • POWERED_ON: 電源オン
  • POWERED_OFF: 電源オフ
  • SUSPENDED: サスペンド

MOIDとは

MOID（Managed Object ID）は、vCenterが管理対象オブジェクトを識別するためのIDです。VMの場合、vm-55009のような値で表されます。

APIでVMを取得するときは、sample-vmのような表示名ではなく、APIが要求するVM識別子を指定します。VM名やIPなどの他の情報からMOIDを検索して活用する方法もありますが、今回は事前に取得したMOIDを直接利用しています。

なお、対象VMのMOIDはvSphere Clientで該当VMを選択している状態のURLに表示されます。


Zabbixの準備と設定手順

今回の設定手順は、次の流れです。

  1. Zabbix Applianceをインストールする
  2. Email通知を設定する
  3. 監視対象ホストを登録する
  4. Script itemを作成する
  5. Dependent itemを作成する
  6. トリガーを作成する
  7. トリガーアクションを作成する
  8. VMを起動・停止して動作をテストする

Zabbix Applianceのインストール

Applianceを利用する理由

Zabbix Applianceを利用すると、Zabbix Server、Webフロントエンド、データベースを含む監視環境を比較的短時間で構築できます。vSphere環境では、配布されているOVF形式のイメージを利用できます。Zabbix Applianceのダウンロード

ただし、Zabbix公式ドキュメントではApplianceは評価用途を想定しているため、本番環境では監視対象数、保存期間、データベース性能、バックアップ方式を考慮して構成を検討してください。Zabbix 7.0 Applianceマニュアル

インストール手順の概要

  1. ダウンロードページから、利用するバージョンのApplianceイメージを取得します。
  2. 任意の仮想環境にデプロイします。
  3. コンソールからデフォルトのパスワードでログイン可能です。
  4. デフォルトはDHCPです。必要に応じてStaticに変更します
  5. Zabbix Webインターフェースへログインします（デフォルトパスワード）

Email通知の設定

ZabbixのEmail通知では、次の3つを設定します。

  • Emailメディアタイプ
  • 通知先ユーザーのメディア
  • トリガーアクション

Emailメディアタイプ

ZabbixのWebインターフェースで、Alerts > Media types > Emailを開き、SMTP環境に合わせて次の項目を設定します。

  • SMTP server / SMTP server port
  • Connection security
  • Authentication
  • SMTP helo / From

SMTPサーバーが認証を要求する場合は、専用の送信用アカウントを使用し、パスワードを設定ファイルや記事へ直接記載しないようにします。Zabbix公式ドキュメント: Email

通知先ユーザーのメディア

Usersから通知先ユーザーを開き、MediaタブでEmailを追加します。

  • Type: Email
  • Send to: 通知先メールアドレス
  • When active: 通知を許可する時間帯
  • Use if severity: 通知対象の深刻度
  • Enabled: 有効

設定後、Emailメディアタイプのテスト機能でテストメールを送信します。テストメールが届くことを確認してから、トリガーアクションを設定します。メール通知の設定に関しては、Qiitaの参考記事を参考にさせていただきました。

監視対象ホストの登録

今回はVMへZabbix Agentをインストールしません。vCenter APIを監視するための論理ホストをZabbixへ登録します。

  1. Data collection > Hostsを開きます。
  2. Create hostをクリックします。
  3. Host nameにvCenterなど、監視用途が分かる名前を入力します。
  4. Host groupsにHypervisorsなどのグループを指定します。
  5. Agent interfaceは、Agent監視を行わない場合は追加しません。
  6. ホストを保存します。

添付画像の最初の画面は、Data collection > HostsからCreate hostを選択し、vCenterホストを作成する例です。公開時は、画面内のユーザー名やパスワードなどの情報をマスキングしてください。



Script itemの作成

HTTP AgentではなくScript itemを使う理由

今回のREST APIは、一度Tokenを生成してから、そのTokenを使って本来のVM APIを呼び出す必要があります。

HTTP Agentでも単純なHTTPリクエストは実行できますが、今回のような「セッション取得」と「VM情報取得」の2段階処理を1つのアイテムで行うには、Script itemを使う方が実装しやすくなります。

ZabbixのScript itemはシェルスクリプトではなく、JavaScriptで記述します。HttpRequestオブジェクトでHTTPリクエストを送信し、レスポンスを返します。Zabbix公式ドキュメント: Script item

Script itemの設定

対象ホストのItemsでCreate itemをクリックし、次のように設定します。

項目設定例
Name任意
TypeScript
Key任意
Type of informationText
Update interval1m




curlコマンドをJavaScriptへ書き換える

以下は、Tokenを取得してからVM情報を取得するScript itemの例です。冒頭のAPIはCurlコマンドで例を示しました。vSphere ClientのAPI ExplorerでもサンプルはCurlで出してくれます。しかし、ZabbixのScript itemはJavascript形式で記述する必要がありますので、生成AI等で書き直してもらいましょう。/api/sessionのレスポンスはJSON文字列で返るため、外側の引用符を取り除いてからvmware-api-session-idヘッダーへ設定します。

※検証用の簡便さ重視で認証情報などをそのまま記載していますが、実際に実装する際の認証情報取り扱いにはご注意ください。

javascript

var p = JSON.parse(value);
var request = new HttpRequest();
var session;
var result;

// vCenter API のセッション取得
request.setHttpAuth(HTTPAUTH_BASIC, 'administrator@vsphere.local', '<Password>');
request.addHeader('Content-Type: application/json');

session = request.post(
    'https://vcenter01.demo.local/api/session',
    ''
);

if (request.getStatus() != 201) {
    throw 'Failed to get vCenter session. HTTP status: ' + request.getStatus();
}

// /api/session のレスポンスは JSON 文字列なので、引用符を除去
session = session.replace(/^"|"$/g, '');

// VM API 用にヘッダーを設定
request.clearHeader();
request.addHeader('vmware-api-session-id: ' + session);

// VM情報取得
result = request.get(
    'https://vcenter01.demo.local/api/vcenter/vm/vm-55009'
);

if (request.getStatus() != 200) {
    throw 'Failed to get VM information. HTTP status: ' + request.getStatus();
}

return result;
vSphere APIと API ExplorervSphere APIの仕様についてはドキュメントからだけでなくvSphere ClientのMenu -> Developer Center -> API Explorerからも確認できます。


Script itemのテスト

Script itemを保存したら、アイテムのTestまたは機能で記述に問題がないか（ちゃんと取得できるか）を確認できます。


※この時点ではAPIのレスポンス全体を保存します。power_stateだけを取り出す処理は、次に作成するDependent itemで行います。

Dependent itemの作成

Dependent itemを使う理由

Script itemで取得したJSONをそのまま保存し、Dependent itemで必要な値だけを抽出します。

この構成にすると、vCenter APIへのアクセスはMaster itemで1回だけ実行し、power_stateやVM名など複数の値を別々のDependent itemとして利用できます。対象項目が増えた場合にも、APIアクセスを増やさずに監視項目を追加できます。



作成手順

  1. Data collection > Hosts > 対象ホスト > Itemsを開きます。
  2. Script item（例: vm55009-item）のメニューからCreate dependent itemを選択します。
  3. 次のように設定します。
項目設定例
Namevm5509-power_state（任意）
TypeDependent item
Keyvm5509.power_state（任意）
Type of informationText
Master item親となるItemを選択
  1. Preprocessingタブで処理を追加します。
  2. 処理にJSONPathを選択します。
  3. Parametersに$.power_stateを入力します。
  4. 保存します。




これでAPI Responseの中から必要となるpower_stateだけを取り出して評価できるようになります。
この段階では、定期的に該当VMのpower_stateを取得しているだけです。
次にトリガーを作成して、情報取得時にpower_stateの値を評価して正常・異常の判定を行わせます。

トリガーの作成

Dependent itemのメニューからCreate triggerを選択するか、対象ホストのTriggersから作成します。



項目設定例
Namevm5509-power_state_trigger（任意）
SeverityHighまたは環境に合わせた深刻度
Expressionlast(/vCenter/vm5509.power_state)="POWERED_OFF"



正常・異常の判定はExpressionの項目で定義します。

Function に last()、Result に = POWERED_ON を設定しています。

ここで評価する値は、Master itemのJSONではなく、JSONPathでpower_stateを抽出したDependent itemです。VMが電源オフになると、直近値がPOWERED_ONになり、問題イベントが生成されます。

注意今回の目的は電源オンの検知なので、条件値はPOWERED_ONにします。

トリガーアクションの作成

トリガーが問題イベントを生成したときにEmailを送信するため、トリガーアクションを作成します。

  1. Alerts > Actions > Trigger actionsを開きます。
  2. Create actionをクリックします。
  3. Action nameにvm5509-power_on_actionなど、用途が分かる名前を入力します。
  4. Conditionsに対象トリガーを指定します。
  5. OperationsタブでSend messageを追加します。
  6. 通知先ユーザーまたはユーザーグループを指定します。
  7. Send to Media typeでEmailもしくはAll available指定します。
  8. 必要に応じてRecovery operationにも復旧通知を追加します。
  9. 保存します。

以下の画像は、Alerts > Actions > Trigger actionsからアクションを作成し、対象トリガーへEmail送信オペレーションを追加する流れです。






電源オン検知のテスト

  1. 対象VMがPOWERED_OFFであることを確認。
  2. Script itemの値がJSONとして取得できることを確認。（Latest Data）
  3. Dependent itemの現在地値がPOWERED_OFFであることを確認。（Latest Data）
  4. 対象VMを起動します。
  5. 次回の更新間隔後、Script itemがJSONを取得できていることを確認。
  6. Dependent itemがPOWERED_ONになったことを確認。
  7. トリガーがPROBLEMになることを確認します。
  8. Emailが通知先へ届くことを確認します。



トラブルシューティング

Script itemがUnsupportedになる

  • Zabbix Serverからvcenter01.demo.localへ接続できるか確認する
  • TCP 443が通信可能か確認する
  • vCenterのCA証明書を信頼できる状態か確認する
  • ユーザー名、パスワード、権限を確認する
  • /api/sessionのHTTPステータスコードがScriptの判定値と一致しているか確認する
  • vm-55009が対象VMの正しい識別子か確認する

Dependent itemの値が取得できない

  • Master itemの最新値がJSONになっているか確認する
  • JSONPathが$.power_stateになっているか確認する
  • vCenterのレスポンスにpower_stateが含まれているか確認する
  • Type of informationがTextになっているか確認する

Emailが届かない

  • Emailメディアタイプのテストを実行する
  • 通知先ユーザーのMediaが有効か確認する
  • 通知時間帯と深刻度の条件を確認する
  • アクションの条件が対象トリガーに一致しているか確認する
  • Problems画面のActions欄で、Email送信が実行されたか確認する

まとめ

今回のポイントは、vCenter APIのレスポンス全体をScript itemで取得し、Dependent itemでpower_stateを抽出することです。

  • /api/sessionでvCenter APIのTokenを取得する
  • vm-55009のようなVM識別子でVM情報を取得する
  • HTTP Agentではなく、2段階のAPI呼び出しが可能なScript itemを使う
  • Script itemはシェルスクリプトではなくJavaScriptで記述する
  • Dependent itemのJSONPathで$.power_stateを抽出する
  • POWERED_ONを条件にトリガーを発生させる
  • トリガーアクションでEmailを送信する
  • 本番環境での接続時の認証情報や証明書検証オプションの扱いに注意

参考にした記事や動画

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む