ESXi 監視の3つのアプローチ — ネイティブアラームを最初に選んだ理由
最初の ESXi クラスターを担当したとき、「どうせ自動化されているから追加設定は要らない」と思い込んでアラームを後回しにしていた。結果、ある月曜日の朝、メール通知ではなく上司からの電話で叩き起こされた。前夜からデータストアが満杯になっていて、3台の VM がデータを書き込めない状態になっていたのだ。それ以来、アラームの設定をオプションとは思わなくなった。
ESXi の CPU・RAM・Datastore を監視してタイムリーに通知を受け取るには、主に3つのアプローチがある。
アプローチ 1：vSphere ネイティブアラーム（vCenter 組み込み）
vCenter Server に標準搭載されており、追加インストール不要。条件を定義してアクション（メール送信・SNMP トラップ・スクリプト実行）を設定するだけ。セットアップは 15 分で完了する。
アプローチ 2：サードパーティ監視スタック（Zabbix / Prometheus）
Zabbix には VMware テンプレートが用意されており、Prometheus は vmware_exporter でメトリクスを収集できる。ダッシュボードの視認性は大幅に優れており、アラートルールの柔軟性も高い。ただし別途監視サーバーを構築する必要があり、既存の ESXi 環境と並行してメンテナンスし続けることになる。
アプローチ 3：PowerCLI スクリプト + Windows タスクスケジューラー
PowerCLI で定期的にメトリクスを取得し、閾値と比較してアラートを送信する — メール、Slack、Teams など任意の手段で。完全なカスタマイズが可能。代償として、コードをゼロから書いて VMware が API を変更するたびに自分でメンテナンスする必要がある。
実際の比較：環境に応じたアプローチの選び方
- vSphere ネイティブアラーム：15 分で完了、追加のサーバーやソフトウェアは不要。20 台未満のホストを管理していて専用監視スタックがないチームに最適。弱点：通知メールはプレーンテキスト、ダッシュボードなし、長期的なメトリクス保存なし。
- Zabbix / Prometheus：直感的なダッシュボード、6〜12 ヶ月分のメトリクス保存によるトレンド分析、アラートルールの柔軟なカスタマイズが可能。大規模な本番環境への投資価値は十分ある。ただし初期セットアップに 2〜3 日かかり、並行してメンテナンスできる担当者も必要になる。
- PowerCLI スクリプト：Slack でアラートを受けたい、レポートのフォーマットを自由に設定したい場合はこれ一択。トレードオフ：PowerShell の知識が必要で、VMware が API を変更したら自分で更新が必要。
個人のラボ環境を VMware から Proxmox に移行した際、興味深い違いに気づいた。Proxmox のビルトインアラートシステムはかなり基本的で、vSphere Alarms ほど細かい設定はできない。一方で Grafana/Prometheus との連携は最初からスムーズだった。プラットフォームごとにそれぞれトレードオフがある。
実践的なアドバイス：チームが新しく環境規模も中程度なら、まず vSphere ネイティブアラームから始めよう。すぐに動作し、Zabbix 専用サーバーが別途必要な理由を上司に説明する手間も省ける。規模が大きくなってから専用の監視スタックへ移行すれば十分だ。
vSphere アラームの実践的なセットアップ — SMTP 設定から最初の受信メールまで
ステップ 1：vCenter の SMTP 設定
メールサーバーを設定しなければ、vCenter はメールを送れない。これが最もよく見落とされるステップで、アラームが発火してもメールボックスが静まり返ったままになる最大の原因でもある。
vSphere Client にログインし、インベントリの vCenter Server をクリック → Configure タブ → Settings → General → Edit ボタン。Mail セクションまでスクロールダウン：
- SMTP Server：メールサーバーのアドレス（例：
smtp.gmail.comまたは社内 Exchange の IP） - SMTP Port：TLS は
587、SSL は465、暗号化なしリレーは25 - Sender account：送信元メールアドレス（例：
[email protected]）
Gmail を使う場合は追加手順が必要になる。まず 2FA を有効にしてから、myaccount.google.com → セキュリティ → アプリパスワード で vCenter 専用のパスワードを生成する。社内 Exchange の場合はよりシンプルで、メールサーバーの IP とリレーポートを入力するだけで追加認証は不要だ。
ステップ 2：ESXi ホストの CPU 使用率アラームを作成する
vSphere Client で Hosts and Clusters タブに切り替える。ESXi ホストを右クリック（またはデータセンター/クラスターをクリックして配下の全ホストにアラームを適用）→ Alarms → New Alarm Definition。
General タブ：
- Alarm name：
ESXi CPU Usage High - Monitor：
Hostを選択 - Monitor for：
Specific conditions or stateを選択
Triggers タブ → Add をクリック：
- Trigger Type：
Host CPU Usage (%) - Operator：
Is Above - Warning (Yellow)：
80 - Critical (Red)：
90 - Tolerance：
5（使用率が閾値付近で変動した際のフラッピングを防ぐ） - Condition length：
5 minutes（10 秒の CPU スパイクではなく、継続的な高負荷状態のみでトリガー）
Actions タブ → Add をクリック：
- Action：
Send a notification email - To：
[email protected]（個人のメールアドレスではなく共有メールボックスを推奨） - Repeat this action：警告状態が続く間、30 分ごとにリマインダーを受け取りたい場合はチェックを入れる
OK をクリックして保存。
ステップ 3：RAM 使用率アラームを作成する
手順は CPU と同じ。トリガーの種類と閾値のみ変更する：
- Alarm name：
ESXi Memory Usage High - Trigger Type：
Host Memory Usage (%) - Warning：
85% | Critical：95%
RAM の閾値は CPU より高めに設定することが多い。ESXi にはバルーンドライバーとメモリスワップがあるため、RAM 88% で稼働しているホストは CPU 88% が継続する状況よりはるかに安定している。vSphere のパフォーマンスグラフでバルーンメモリも確認しよう。それが継続的に高い場合、85% が適切な警告閾値となる。
ステップ 4：Datastore アラームを作成する
重要な違いがある：データストアのアラームはホストではなく Datastore オブジェクトに対して作成する必要がある。vSphere Client で Storage タブに切り替え → データストアを右クリック → Alarms → New Alarm Definition：
- Alarm name：
Datastore Disk Usage High - Monitor：
Datastore - Trigger Type：
Datastore Disk Usage (%) - Warning：
75% | Critical：85%
データストアの満杯は最悪のシナリオで、自動回復の仕組みはない。書き込み中の VM はその場でクラッシュする。そのため CPU・RAM より低い閾値を設定する。75% の時点で早めに警告を受け取り、危険な 85% に達する前にストレージのクリーンアップや拡張に十分な時間を確保する。
ステップ 5：本番稼働前にテストする
実際に問題が起きるまでアラームが動作するか分からない、という状態は避けよう。最もシンプルな方法：閾値を一時的に下げてすぐアラームをトリガーさせる。
作成したアラームを → Edit → Warning 閾値を 10% に変更 → 5〜10 分待つ → メールを確認。件名は [vCenter Alarm] ESXi CPU Usage High on esxi01 - Warning のような形式になる。受信できれば、SMTP とアラームの両方が正常に機能している。確認後は元の閾値に戻す。
PowerCLI を使ってアクティブなアラームの一覧を取得することもできる — 多数のホストを管理する際に便利だ：
# vCenter に接続
Connect-VIServer -Server vcenter.company.com -User [email protected] -Password "YourPassword"
# 有効な全アラーム定義を確認
Get-AlarmDefinition | Where-Object { $_.Enabled -eq $true } | Select-Object Name, Entity, Enabled | Format-Table -AutoSize
# Warning または Critical 状態のアラームを確認
Get-VMHost | Get-AlarmAction | Where-Object { $_.Alarm.AlarmState -ne "Green" }
# 特定ホストのトリガー済みアラームを確認
$vmhost = Get-VMHost "esxi01.company.com"
$alarmMgr = Get-View AlarmManager
$alarmMgr.GetAlarmState($vmhost.ExtensionData.MoRef) | Where-Object { $_.OverallStatus -ne "green" }
ステップ 6：アラート疲れを防ぐためのチューニング
以前、常時 75〜80% で稼働している本番サーバーに CPU アラームを 70% で設定して、1 日に 200 件以上のメールを受け取ったことがある。メールボックスがアラームで溢れ、読まずに既読にするようになった。これが最悪のシナリオだ。監視が足りないのではなく、多すぎて誰も気にしなくなる状態である。
1〜2 週間分の実データが集まったら見直しを行おう：
- ベースラインに基づいて閾値を調整する — サーバーが通常 75% で稼働しているなら Warning を 80% ではなく 90% に設定する
- アラームは個人のメールに直接送らず、共有メールボックスや Slack/Teams チャンネルに送る
- 問題が解決したことを把握するため「green」アクションも設定する — アラームが自動でクリアされたかどうか確認するために重要
- 5 台以上のホストを管理している場合：クラスターまたはデータセンターレベルでアラームを作成することを検討する — 一度の設定で配下の全ホストに適用される
本番稼働前のチェックリスト
- SMTP の設定が完了し、テストメールを少なくとも 1 件受信済み
- CPU アラーム：Warning 80%、Critical 90%、Tolerance 5%、Condition length 5 分
- RAM アラーム：Warning 85%、Critical 95%
- Datastore アラーム：Warning 75%、Critical 85%（データストアごとに個別作成）
- 通知先は共有メールボックスまたはチームチャンネル
- 問題解決時の通知のための「green」アクションを設定済み
- 1 週間の観測後、実際のベースラインに基づいて閾値を見直し済み
