monitoring-setup

モニタリングのセットアップ

2 つのレイヤーがあります。アプリケーションの健全性（エラー、ユーザーの行動）と、運用の健全性（キューが処理されているか、データベースが追いついているか）です。Sentry 上では問題がなくても、キューが滞留していたり、リクエストごとにテーブルスキャンが発生していたりすれば、ユーザーにとっては依然として障害です。両方をカバーしてください。

使用する場面

• エラー追跡（Sentry）を設定したい
• Google Analytics を設定したい
• 本番アプリケーションのモニタリングが必要
• アプリケーションのエラーやユーザーの行動を追跡したい
• 運用シグナル（キューの深さ、遅いクエリ、接続の飽和状態）と、それらに対するアラートが必要

Sentry のセットアップ

NestJS バックエンド

1. インストールします：bun add @sentry/node @sentry/profiling-node
2. アプリケーションの作成前に main.ts で初期化します
3. SENTRY_DSN 環境変数で DSN を設定します
4. 本番環境に適したサンプルレートを設定します

Next.js フロントエンド

1. インストールします：bun add @sentry/nextjs
2. 実行します：bunx @sentry/wizard@latest -i nextjs
3. クライアント／サーバー／エッジの設定を行います
4. クライアント側では NEXT_PUBLIC_SENTRY_DSN を設定します

Google Analytics のセットアップ

Next.js のセットアップ

1. ルートレイアウトに Google Analytics のスクリプトを追加します
2. NEXT_PUBLIC_GA_MEASUREMENT_ID を使用します（形式：G-XXXXXXXXXX）
3. イベント追跡用の分析ユーティリティ関数を作成します
4. ページビューの追跡を設定します

一般的なイベント

• ユーザー登録／ログイン
• 購入／コンバージョン
• 機能の利用状況
• カスタムのビジネスイベント

運用モニタリング

アプリケーションエラーからは何が例外を発生させたかが分かりますが、運用シグナルからは何がひそかに劣化しているかが分かります。負荷によってプロダクトが停止する原因となる 3 つを計測してください。

BullMQ のキューの深さ

キューへの追加が処理を上回って増え続ける状態は、ゆっくり進行する障害です。ジョブがタイムアウトするまでエラーは発生しません。

• キューごとに waiting（バックログ）、active、failed、completed rate（完了率）を追跡します。これらは Queue.getJobCounts() で取得できます。一定間隔でスクレイピングするか、bullmq-prometheus を介して取得します。
• 重要なのは傾向です。waiting が増加する一方で completed が横ばいの場合、ワーカーが処理に追いついていません（ワーカーまたは Redis 接続をスケールします）。
• デッドレター／failed セットを監視します。再試行を使い切ったジョブは、気づかれないままデータ損失につながります。

Postgres の遅いクエリと接続

• pg_stat_statements を有効にし、合計時間と平均時間の上位クエリを表示します。個々の実行は高速でも、1 分間に 1 万回実行されるクエリが実際のコストになります。
• しきい値を超えたクエリを記録し（log_min_duration_statement）、新たに該当したクエリに対してアラートを設定します。遅いクエリは、多くの場合、インデックスの不足か N+1 が原因です。
• 接続の飽和状態（active / max_connections）を追跡します。サーバーレスで上限に近づいている場合、プーラーのサイズが不足しています。postgres-ops を参照してください。

Redis

• maxmemory に対するメモリ使用量、エビクション率、コマンドのレイテンシーを監視します。エビクションが発生している場合はキャッシュが小さすぎて、ヒット率がひそかに低下しています。

アラート

誰も確認しない計測データは、モニタリングとは言えません。上記の各シグナルにしきい値を定義し、午前 3 時でも担当者の目に留まる場所（PagerDuty、Opsgenie、ページ通知を行う Slack チャンネル）に通知してください。遅行指標（ジョブがすでにタイムアウトした、500 エラーをすでに返した）だけでなく、先行指標（キューの waiting が増加している、接続数が上限に近づいている）に対してアラートを設定します。各アラートには実行すべきランブックの手順を明記してください。そうでなければ、ただのノイズです。

ベストプラクティス

• 開発環境と本番環境では異なる DSN を使用します
• 適切なサンプルレートを設定します
• ユーザーのプライバシーを尊重します（GDPR／CCPA）
• 機密データは追跡しません
• 事後に発生したエラーだけでなく、先行する運用指標に対してアラートを設定します
• すべてのアラートにランブックの対応手順をリンクします。孤立したアラートは作りません

統合

このスキルは、自動セットアップワークフロー用の /monitoring-setup コマンドと連携します。postgres-ops（プーリング、DR）および nestjs-queue-architect（キュー設計）と組み合わせて使用します。