2026年4月9日

Webhook連携で監視を自動化｜DevOpsに活かす死活監視の実践ガイド

Webhook DevOps 自動化死活監視

監視アラートを「受け取るだけ」で終わっていませんか？

死活監視ツールを導入して、Slackやメールにアラートが届くようにした。しかし、障害の検知後に人が手動で対応していると、復旧までの時間が長くなりがちです。

Webhook連携を活用すれば、障害検知をトリガーにして自動復旧やエスカレーションを実現できます。この記事では、MiterlのWebhook通知を使った自動化の実践例を紹介します。

Webhookとは

Webhookは、イベント発生時に指定したURLへHTTPリクエストを送信する仕組みです。死活監視の文脈では、以下のイベントで通知されます。

monitor.down: サイトがダウンした
monitor.recovery: サイトが復旧した
ssl.expiring: SSL証明書の期限が近い

// Webhookペイロードの例
{
  "event": "monitor.down",
  "monitor": {
    "id": 1,
    "name": "[ABC商事] コーポレートサイト",
    "url": "https://abc-corp.example.com"
  },
  "incident": {
    "started_at": "2026-04-09T14:30:00+09:00",
    "status_code": 503,
    "response_time_ms": null
  }
}

活用例1: 自動復旧スクリプトの実行

Webアプリケーションのプロセスがハングした場合、再起動で復旧するケースは多いです。Webhookを受け取ったサーバー側で自動的にサービスを再起動できます。

#!/bin/bash
# webhook-handler.sh — Webhookを受信して自動復旧を試みるスクリプト

EVENT=$(echo "$REQUEST_BODY" | jq -r '.event')
MONITOR_URL=$(echo "$REQUEST_BODY" | jq -r '.monitor.url')

if [ "$EVENT" = "monitor.down" ]; then
  echo "[$(date)] ダウン検知: $MONITOR_URL — 自動復旧を試行"
  
  # アプリケーションサーバーの再起動
  sudo systemctl restart php-fpm
  sudo systemctl restart nginx
  
  echo "[$(date)] サービス再起動完了"
fi

注意点

自動復旧は一時的な対処であり、根本原因の調査は別途必要です
無限ループを防ぐために、短期間に複数回の再起動が走らないようガードを入れましょう
自動復旧の履歴をログに残して、後から確認できるようにします

活用例2: CI/CDパイプラインとの連携

デプロイ後にサイトがダウンした場合、自動でロールバックする仕組みを構築できます。

# GitHub Actionsのワークフロー例（自動ロールバック）
# .github/workflows/auto-rollback.yml

# Webhookを受信するエンドポイントから呼び出す
curl -X POST \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  "https://api.github.com/repos/owner/repo/actions/workflows/rollback.yml/dispatches" \
  -d '{"ref": "main"}'

デプロイフローに組み込むパターン

デプロイ前: メンテナンスウィンドウを設定してアラートを抑制
デプロイ実行: CI/CDパイプラインでコードをデプロイ
デプロイ後: メンテナンスウィンドウ終了後に監視が自動再開
障害検知時: Webhookでロールバックをトリガー

活用例3: インシデント管理ツールとの連携

PagerDutyやOpsgenieなどのインシデント管理ツールにWebhookを送ることで、オンコール担当者への自動エスカレーションが可能です。

Webhook通知先（PagerDutyのエンドポイントなど）はダッシュボードの「アラート連絡先」から追加します。作成した通知先はAPIから一覧・IDを取得でき、各モニターの alert_contact_ids に紐付けて通知の宛先として利用します。

# 登録済みの通知先（アラート連絡先）の一覧とIDを取得
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, type, name}'

活用例4: カスタムダッシュボードへのデータ連携

Webhookのペイロードを自社のデータベースに蓄積すれば、独自のダッシュボードやレポートを構築できます。

障害の傾向分析: 曜日・時間帯ごとの障害発生パターン
MTTR（平均復旧時間）の追跡: 月次でMTTRの改善を確認
クライアント別レポート: ステータスページと連動した詳細レポート

Webhook設定のベストプラクティス

セキュリティ

署名検証: Webhookリクエストに含まれる署名を検証し、正規の送信元であることを確認する
HTTPS必須: Webhook受信エンドポイントは必ずHTTPSで公開する
IPホワイトリスト: 可能であれば送信元IPを制限する

信頼性

リトライ対応: 受信側が一時的にダウンしている場合に備え、Miterlはリトライを行います
べき等性: 同じWebhookが複数回届いても問題ない設計にする
タイムアウト: 受信側は5秒以内にレスポンスを返すようにする

Webhook署名検証の実装例

Webhookを受信するエンドポイントは、インターネットに公開されているため、第三者が偽のリクエストを送ってくる可能性があります。署名検証を実装することで、Miterl以外からのリクエストを弾けます。

<?php
// PHP での Webhook 署名検証例

function verifyWebhookSignature(string $payload, string $signature, string $secret): bool
{
    $expected = 'sha256=' . hash_hmac('sha256', $payload, $secret);
    return hash_equals($expected, $signature);
}

// リクエスト受信時
$payload   = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '';
$secret    = getenv('WEBHOOK_SECRET');

if (!verifyWebhookSignature($payload, $signature, $secret)) {
    http_response_code(401);
    exit('Unauthorized');
}

$data = json_decode($payload, true);
// 処理を続ける...

署名検証のポイントは hash_equals() を使うことです。通常の文字列比較（===）ではタイミング攻撃（timing attack）に脆弱になる可能性があるため、定数時間比較の hash_equals() を使います。

よくある活用パターン：サマリーを定期レポートに含める

Webhookで収集した障害データ（発生時刻・ダウンタイム・復旧時刻）を蓄積しておくと、月次のSLAレポートに活用できます。手動でダッシュボードを確認してコピーする作業を自動化できるため、10件・20件のクライアントサイトを管理する制作会社には特に効果的です。SLAレポートの自動化については「稼働率レポートの作り方」で詳しく解説しています。

まとめ

Webhook連携により、死活監視は「通知を受け取る」だけのツールから、「自動で対応する」仕組みへと進化します。自動復旧、CI/CD連携、エスカレーションなど、運用の自動化を推進することで、障害対応の速度と品質を大幅に向上できます。

Webhookの詳しい設定方法はドキュメントをご覧ください。通知チャンネルの設定手順は「Slack・Chatwork・LINEへの通知設定」でも解説しています。Miterlの機能を試すなら無料登録からお試しください。FAQもあわせてご確認ください。