2026/04/09
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"}'
デプロイフローに組み込むパターン
- デプロイ前: メンテナンスウィンドウを設定してアラートを抑制
- デプロイ実行: CI/CDパイプラインでコードをデプロイ
- デプロイ後: メンテナンスウィンドウ終了後に監視が自動再開
- 障害検知時: 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もあわせてご確認ください。