Monitoring + Alert + BillingObservability & budget
本番運用で「異常があれば気付ける」状態を整えました。Cloud Monitoring（Google Cloud 標準の監視基盤）で通知チャネル・アラートポリシーを、Cloud Billing（請求）で月予算と段階通知を、Cloud Error Reporting（エラー自動集約）で新規エラー時のメール通知を設定しました。
本構築時点では「箱（通知チャネル + 代表アラート + 月予算）」のみを先に整えています。詳細な閾値（5xx の比率が一定以上になった場合等）は本物のアプリイメージがデプロイされた後の Step 99 で詳細化します。
通知チャネルとアラートChannel & alert policy
メールアドレス system-admin@example.com を通知チャネルに登録し、最初のアラートとして「Cloud Run の 5xx エラー検出」を作成しました。
| 項目 | 値 |
|---|---|
| 通知チャネル | メール · system-admin@example.com |
| アラートポリシー名 | Cloud Run 5xx 検出 |
| 指標 | Cloud Run Revision · Request count |
| フィルタ | response_code_class = "5xx" |
| 集計 | 一定時間のウィンドウの sum、複数リビジョン合算 |
| しきい値 | 一定時間内に一定件数以上 → メール通知（仮値） |
| 本番値（Step 99） | リクエスト総数に対する比率ベースに詳細化予定 |
本構築時点での閾値は仮置きです。本物のアプリイメージが動き始めると、件数だけを基準にした低いしきい値では誤発火が頻発するため、Step 99 で「総リクエストに対する比率」のように比率ベースに修正します。先に「箱」を作っておくことで、後から指標を追加する際の作業を最小化しています。
月予算と 4 段階通知Monthly budget
異常コスト（攻撃による DDoS や、無限ループのバッチによる暴走など）を早期に検知するため、月予算を設定し、4 段階で通知を出します。これは強制停止ではなく通知のみで、運用者が判断する材料を提供する設計です。
| 設定項目 | 値 |
|---|---|
| 予算名 | matsuba-budget-monthly |
| 対象 | プロジェクト Matsuba · 全サービス |
| 目標金額 | 指定額方式（金額は非掲載） |
| 通知しきい値 | 4 段階（予算に近づいたとき〜超えたとき） |
| 通知先 | 請求管理者・請求ユーザ + system-admin@example.com |
| アクション | 通知のみ（自動停止は しない） |
「自動停止しない」設計の理由: 月末にちょうど超過した場合、自動停止だと本番サービスが落ちて利用者に影響が出ます。予算を超えた段階の通知を運用者が見て、影響範囲を判断した上で対処する方が安全です。一方、構造的な暴走防止は別レイヤで担保しています（Cloud Run の max-instances 上限、Cloud Armor のレート制限、min=0 ジョブのアイドル課金 0 円、等）。
Cloud Error ReportingError auto-aggregation
アプリが構造化エラーログ（severity: ERROR または CRITICAL）を Cloud Logging に出力すると、Error Reporting が自動でグルーピングし、新しいエラー種別が出た瞬間にメールが飛びます。「同じエラーが大量に出ても 1 通だけ」のため、運用者の通知疲労を防げます。
| 項目 | 値 |
|---|---|
| 新規エラー通知 | ON |
| 通知先 | §1 で作成した通知チャネル |
| 連動するログ | Cloud Run 全 4 サービス + Jobs の構造化ログ |
| 本構築時点の状態 | 「エラーがありません」（空デプロイのため） |
Cloud Logging の保持期間Log retention
| バケット | 保持期間 | 用途 |
|---|---|---|
_Default | 30 日（既定） | アプリの操作ログ・エラーログ |
_Required | 400 日（固定） | 監査関連の必須ログ（変更不可） |
業務監査ログ（audit_logs テーブル）は別系統です。Postgres 上で月次パーティション分割し、25 ヶ月超のデータを Cloud Storage に退避する audit-log-partition-rotator バッチで 20 年運用を見据えた長期保管を担保します（Step 4b で実装予定）。
本構築の総括と次のステップWrap-up & next
手順 00 から 10 まで、松葉 / Matsuba の本番クラウド基盤を構築しました。本手順以降は、各 Cloud Run サービスに本物のアプリイメージを順次デプロイしながら、機能タスクごとに必要な Pub/Sub サブスクリプション・Cloud Scheduler ジョブを追加していきます。
| 次フェーズ | 概要 |
|---|---|
| 共通基盤タスク T01〜T11 | モノレポ枠 + 共通パッケージ + Better Auth 基盤 + scanner スタブ等 |
| Step 1 認証 / Box / ファイル基盤 | 業務機能の中核（サインイン・Box 作成・アップロード） |
| Step 99 T01 監視詳細化 | 本ページの「箱」に本番閾値を設定（5xx 比率 / scan_status 滞留 / DLQ 件数 等） |
本構築の意義: 本日完成した基盤は、20 年運用を見据えた長期前提・本番 = テスト・ステージング兼用の 1 環境運用・キーレス認証・多層防御 を初期構築の段階から組み込んでいます。後から「セキュリティを足す」「監視を足す」のではなく、最初から組み込まれている状態でアプリ実装フェーズに入れます。