単に「サイトが開くか？」だけを確認する監視では不十分だ。
ログインページ自体が開いても、実際のログイン処理で問題が起きればユーザーはサービスを利用できない。

Zabbix の Web シナリオ（Web Scenario）機能を使えば、ログインリクエストを実際に送信し、レスポンスを検証してログイン成功の可否を監視できる。
単純な HTTP 死活監視 は設定も難しくなく、検索すればガイドも多い。
しかし、ログインを含む機能監視となると参考資料はほとんど見つからない。

ここでは実際の環境で適用した手順をまとめる。

1. ログイン URL と Payload の確認

まず、ログインリクエストがどの URL に送信され、どの値が送られているかを確認する必要がある。
これは Chrome 開発者ツール（F12） で簡単に確認できる。

ログインページにアクセス
F12 → Network タブを開く
「Fetch/XHR」フィルタをオン
ログインボタンをクリック
最初に発生した sign-in リクエストを選択
URL と Method（POST）を確認
Request Headers で Content-Type を確認
Payload で実際に送信されているフィールドを確認

例（任意値）

URL: https://example.com/member-user/auth/sign-in
Method: POST
Content-Type: multipart/form-data; boundary=—-WebKitFormBoundary6x5o981HvBL2rDUC
Payload:
- clientname: example
- username: test_user@example.com
- password: MySecurePassword123!

👉 重要ポイント

clientname → サービス識別。必ず本番値を確認
username → 監視専用アカウント推奨
password → そのパスワード

2. curl で動作テスト

Zabbix に設定する前に、curl でログイン成功の可否を確認する。

curl -X POST https://example.com/member-user/auth/sign-in \
  -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary6x5o981HvBL2rDUC" \
  -F "clientname=example" \
  -F "username=test_user@example.com" \
  -F "password=MySecurePassword123!"

200 OK → 正常
401 / 403 / 500 → URL または payload・header が誤っている可能性あり

Tip. もしうまく動作しない場合は、boundary の不整合を防ぐため -H オプション（Content-Type）を削除し、curl の自動処理に任せて試してみてください。

3. Zabbix Web シナリオの設定

(1) シナリオ基本情報

名前: ログインチェック
URL: https://example.com/member-user/auth/sign-in
更新間隔 / 試行回数: 任意
エージェント: Zabbix server

(2) Step の追加

名前: ログイン試行
URL: 上記で確認したログイン処理 URL
POST フィールド → Raw データ を選択
Raw データ入力内容（boundary で囲む）:

------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="clientname"

example
------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="username"

test_user@example.com
------WebKitFormBoundaryTest123
Content-Disposition: form-data; name="password"

MySecurePassword123!
------WebKitFormBoundaryTest123--

👉 注意（重要）
Raw データを入力する際、各フィールドの間には必ず 空行（改行） を入れること。
改行が不足すると、リクエストが正しく認識されない場合がある。

ヘッダ設定

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryTest123
user-agent: curl/7.68.0

boundary は Raw データと完全に一致させる
user-agent は任意

タイムアウト & ステータスコード

タイムアウト: 15 秒
期待ステータスコード: 200

4. ログイン方式ごとの注意点

ログイン方式	対応可否
単純なフォームログイン	✅ 今回の方法で対応可能
セッションクッキー型	Step を複数にし cookie を引き継ぐ必要あり
CSRF トークン必須	トークンを Step1 で取得し Step2 で送信
JS 暗号化 / CAPTCHA	❌ Web シナリオのみでは不可

5. まとめ

開発者ツールで URL / Header / Payload を正確に確認
curl で事前に 200 OK を確認
Zabbix Web シナリオで Raw データ + Header をそのまま再現
boundary は Header と Raw データで一致必須
サイトのログイン方式によっては Web シナリオでは対応不可な場合あり

これにより、単なる HTTP 死活監視 を超え、
実際にログインが成功するかどうか を Zabbix で監視できる。

Zabbix Web シナリオ：ログインチェックのトリガー設定

Web シナリオでログイン監視を作成したら、次は トリガー（Trigger） を設定してアラートを受け取る。
Web シナリオの 鍵となるアイテム は web.test.fail だ。

0 → 正常（ログイン成功）
1 → 障害（ログイン失敗）

この値を使ってトリガーを作成する。

1. トリガー設定

(1) 名前

portal.example.com ポータル Web ログインに問題が発生しています。

(2) 障害条件式（Problem Expression）

last(/Host/web.test.fail[portal web モニタリング])=1

(3) 復旧条件式（Recovery Expression）

last(/Host/web.test.fail[portal web モニタリング])=0

(4) 深刻度

深刻（Critical）または High を推奨

2. その他オプション

正常イベント生成: 有効
障害イベント生成モード: Single
正常イベント閉鎖: すべての障害
手動クローズ: 必要であれば有効

3. 最終設定例

トリガー名
portal.example.com ポータル Web ログインに問題が発生しています。
障害条件
last(/Host/web.test.fail[portal web モニタリング])=1
復旧条件
last(/Host/web.test.fail[portal web モニタリング])=0
深刻度
Critical

4. まとめ

web.test.fail → 0 は正常 / 1 は障害
=1 で障害発生 / =0 で復旧
Web シナリオにより「実ログイン成功可否」を Zabbix で正確に監視可能

🛠 마지막 수정일: 2025.12.02

💡 お困りですか？
Zabbix、Kubernetes、各種オープンソースインフラの構築・運用・最適化・障害解析が必要であれば、いつでもご連絡ください。

📧 メール: jikimy75@gmail.com
💼 サービス: 導入支援 | 性能チューニング | 障害解析コンサルティング

Zabbix Web シナリオで Web ログイン監視を構築する