Databricks JobsのWebhookと通知で失敗通知・運用自動化

Databricksのジョブが失敗した場合、いかに素早く検知して対応できるかが運用品質を左右します。 「朝出社したら夜間バッチが全部失敗していた」「障害に気づくのが数時間遅れた」といった事態は 通知の仕組みが不十分なことが原因です。

この記事では、Databricks Jobsで利用できる通知チャネル（Email/Slack/Teams/PagerDuty/Webhook）の比較、 Webhookの設定方法と実装例、失敗検知からチケット起票までの自動化フロー、 そしてSystem Tablesを使ったジョブ実行のモニタリングを解説します。

通知チャネルの比較

Databricks Jobsでは、ジョブの開始・成功・失敗・タイムアウト・リトライなどのイベントに対して 通知を設定できます。利用可能な通知チャネルの特性を比較します。

実務では複数のチャネルを組み合わせるのが一般的です。 例えば「成功はメール（記録用）」「失敗はSlack＋PagerDuty（即時対応）」のように設定します。

通知イベントの種類

ジョブの通知は以下のイベントに対して個別に設定できます。

ジョブ通知の設定方法

ジョブの通知設定はUI・REST API・DABsのYAMLから行えます。 REST APIでの設定例を示します。

# ジョブ作成時に通知を設定
curl -X POST \
  "https://<workspace-url>/api/2.1/jobs/create" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "nightly_etl_pipeline",
    "tasks": [...],
    "email_notifications": {
      "on_start": [],
      "on_success": ["[email protected]"],
      "on_failure": ["[email protected]", "[email protected]"],
      "no_alert_for_skipped_runs": true
    },
    "webhook_notifications": {
      "on_failure": [
        {
          "id": "<notification-destination-id>"
        }
      ]
    },
    "notification_settings": {
      "no_alert_for_skipped_runs": true,
      "no_alert_for_canceled_runs": false
    }
  }'

通知先（Notification Destinations）の設定

Webhook、Slack、Microsoft Teams、PagerDutyへの通知はNotification Destinationsとして 事前に登録しておき、ジョブ側からIDで参照する仕組みです。

# Slack Notification Destinationの作成
curl -X POST \
  "https://<workspace-url>/api/2.0/notification-destinations" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Data Platform Slack Channel",
    "config": {
      "slack": {
        "url": "https://hooks.slack.com/services/T00000000/B00000000/XXXX"
      }
    }
  }'

# PagerDuty Notification Destinationの作成
curl -X POST \
  "https://<workspace-url>/api/2.0/notification-destinations" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Data Platform PagerDuty",
    "config": {
      "pagerduty": {
        "integration_key": "xxxx-xxxx-xxxx-xxxx"
      }
    }
  }'

汎用Webhookによるカスタム通知フロー

Slack/Teams/PagerDuty以外のシステムに通知する場合は、汎用Webhookを使います。 DatabricksがPOSTリクエストを送信し、受信側がそのペイロードを処理して任意のアクションを実行します。

# 汎用Webhook Notification Destinationの作成
curl -X POST \
  "https://<workspace-url>/api/2.0/notification-destinations" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Custom Ticket System Webhook",
    "config": {
      "generic_webhook": {
        "url": "https://automation.example.com/databricks-webhook",
        "username": "databricks",
        "password": "secure-password"
      }
    }
  }'

Webhookのペイロードには、ジョブID、ジョブ名、実行ID、実行ステータス、開始/終了時刻などの情報が含まれます。 受信側ではこの情報をパースして、チケット起票・ダッシュボード更新・後続ジョブのトリガーなどを行えます。

失敗検知→チケット起票の自動化フロー

本番環境のETLジョブが失敗した場合の理想的な自動化フローは以下の通りです。

1. ジョブ失敗: Databricks Jobがエラーで終了
2. Webhook通知: on_failureイベントでWebhookが発火
3. 中継サービスで処理: Azure Logic Apps / AWS Lambda / n8nがWebhookを受信
4. チケット起票: Jira / ServiceNow / GitHubのIssue APIを呼び出してチケットを自動作成
5. Slack通知: 同時にSlackチャネルにチケットリンク付きの通知を送信
6. PagerDuty: 重要度の高いジョブの場合はPagerDutyでオンコール担当に即時通知

この構成では、ジョブの失敗から数秒以内にチケットが起票され、担当者にアラートが届きます。 手動での障害検知を完全に排除できるため、夜間バッチの失敗にも即座に対応可能になります。

System Tablesを使ったジョブモニタリング

DatabricksのSystem Tablesには、ジョブの実行履歴や監査ログがDelta Table形式で保存されています。 Webhook通知と組み合わせることで、より高度な監視・分析が可能になります。

-- 過去7日間で失敗したジョブの一覧
SELECT
  job_id,
  run_id,
  result_state,
  start_time,
  end_time,
  TIMESTAMPDIFF(MINUTE, start_time, end_time) AS duration_minutes
FROM system.lakeflow.job_run_timeline
WHERE result_state = 'FAILED'
  AND start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
ORDER BY start_time DESC

-- ジョブごとの失敗率（過去30日）
SELECT
  job_id,
  COUNT(*) AS total_runs,
  SUM(CASE WHEN result_state = 'FAILED' THEN 1 ELSE 0 END) AS failed_runs,
  ROUND(
    SUM(CASE WHEN result_state = 'FAILED' THEN 1 ELSE 0 END) * 100.0 / COUNT(*),
    1
  ) AS failure_rate_pct
FROM system.lakeflow.job_run_timeline
WHERE start_time > CURRENT_TIMESTAMP() - INTERVAL 30 DAYS
GROUP BY job_id
HAVING failed_runs > 0
ORDER BY failure_rate_pct DESC

-- 実行時間の異常検知（平均の2倍以上かかったジョブ）
WITH stats AS (
  SELECT
    job_id,
    AVG(TIMESTAMPDIFF(MINUTE, start_time, end_time)) AS avg_duration,
    STDDEV(TIMESTAMPDIFF(MINUTE, start_time, end_time)) AS stddev_duration
  FROM system.lakeflow.job_run_timeline
  WHERE result_state = 'SUCCESS'
    AND start_time > CURRENT_TIMESTAMP() - INTERVAL 30 DAYS
  GROUP BY job_id
)
SELECT
  t.job_id,
  t.run_id,
  TIMESTAMPDIFF(MINUTE, t.start_time, t.end_time) AS duration_minutes,
  s.avg_duration AS avg_minutes,
  s.avg_duration + 2 * s.stddev_duration AS threshold_minutes
FROM system.lakeflow.job_run_timeline t
JOIN stats s ON t.job_id = s.job_id
WHERE t.start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
  AND TIMESTAMPDIFF(MINUTE, t.start_time, t.end_time) > s.avg_duration + 2 * s.stddev_duration
ORDER BY t.start_time DESC

System TablesクエリをDatabricks SQLアラートと組み合わせると、 「失敗率が閾値を超えたら通知」「実行時間が異常に長いジョブを検知」といった プロアクティブな監視を構築できます。

DABsでの通知設定

Databricks Asset Bundles（DABs）でジョブを定義する場合、YAML内で通知設定を宣言的に記述できます。

# databricks.yml
resources:
  jobs:
    nightly_etl:
      name: "nightly_etl_pipeline"
      email_notifications:
        on_failure:
          - "[email protected]"
        on_success:
          - "[email protected]"
      webhook_notifications:
        on_failure:
          - id: "${var.slack_notification_destination_id}"
      notification_settings:
        no_alert_for_skipped_runs: true
      tasks:
        - task_key: "ingest"
          notebook_task:
            notebook_path: "./notebooks/ingest.py"

DABsで管理すると、通知設定もコードレビュー・バージョン管理の対象になり、 「誰がいつ通知設定を変更したか」が追跡可能になります。

試験で問われるポイント

• 「ジョブ失敗時にチームに即時通知するには」→ Webhook通知（Slack/Teams）またはPagerDuty
• 「ジョブの実行履歴をSQLで分析するには」→ System Tables（system.lakeflow.job_run_timeline）
• 「on_duration_warning_threshold_exceededの用途は」→ ジョブ実行時間が閾値を超えた場合の検知
• 「通知先を複数のジョブで共有するには」→ Notification Destinationsに登録してIDで参照

問題で確認

よくある質問