2026/04/09

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": "mon_abc123",
    "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"}'

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

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

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

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

# MiterlのWebhook通知先にPagerDutyのエンドポイントを設定
curl -X POST https://api.miterl.com/v1/channels \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "webhook",
    "name": "PagerDuty連携",
    "webhook_url": "https://events.pagerduty.com/v2/enqueue",
    "headers": {
      "Content-Type": "application/json"
    }
  }'

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

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

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

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

セキュリティ

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

信頼性

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

まとめ

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

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