動いていても壊れる — 失敗とコストを信号で捉える
パイプラインの上流から下流まで、転送量・実行失敗・BigQueryのスキャン量を別々の信号で監視します。
TL;DR
- STSは「成功」だけでなく、24時間の転送バイト数が0かを見る。
- Cloud Run Job・functions・Workflowsは実行失敗を個別に拾う。
- BigQueryはジョブ失敗とは別に、スキャン量の急増をコスト異常として監視する。
01上流の無音を検知する
STSは成功でも0バイトなら、新しいデータが届いていない可能性がある。
copied_bytes_countを直近24時間で監視し、0なら下流が古いデータを使う前に知らせる。
02実行失敗を経路ごとに見る
functions・Job・Workflowは、失敗の意味と復旧担当が異なる。
Cloud Run functionsの変換失敗、Cloud Run Jobのdbt失敗、Workflowのリトライ枯渇をそれぞれの実行メトリクスで監視する。
要点：functions・Job・Workflowは、失敗の意味と復旧担当が異なる。
03コストを別軸で見る
処理が成功しても、スキャン量が増え続けることがある。
BigQueryのscanned_bytes_billedを集計し、WHERE漏れ・full refresh化・重い定期クエリを早く検知する。
結論
- 監視対象は「実行の失敗」だけでなく「入力が来ない」「コストが増える」も含む。
- アラートは信号ごとに作り、通知チャンネルからSlackへ流す。
- 監視は完成後の付け足しではなく、パイプラインの契約の一部。