あなたのシステムが不調になる“その瞬間”、最初に悲鳴をあげるのはどこか？
多くの場合、それはデータベースです。
CPUが突然100％に張り付く。クエリの応答が極端に遅くなる。接続数が異常に増える。ディスクがいっぱいになる――そのどれもが、最悪の場合システム全体のダウンにつながります。
しかしこれらは、いきなり起きたわけではありません。予兆はあったのです。
その予兆をつかみ、素早く対応するために必要なのが、DB監視とアラートの設計です。
この記事では、現場で役立つデータベース監視のベストプラクティスを解説します。
監視とアラート設計の目的とは？
まず大前提として、「監視＝通知を飛ばすこと」ではありません。
本来の目的は次の3つです。
- 異常の早期検知（壊れる前に気づく）
- 根本原因の特定支援（何が問題だったのかを分析）
- パフォーマンス改善（将来の問題を未然に防ぐ）
「とりあえずアラートが出れば安心」ではなく、「どの値がどう変化すれば危ないのか」を理解して、的確に設計することが肝心です。
監視すべきDBの代表的メトリクス
DBMSによって項目は異なりますが、共通して見るべき重要な指標は以下の通りです。
1. 接続数（Connections）
- 増加しすぎるとリソースを食いつぶし、DBが応答しなくなります。
- 「最大接続数」に近づいている場合、コネクションプールの設定やリークの疑いをチェック。
2. クエリ応答時間（Query Latency）
- 平均だけでなく**P95/P99（95/99パーセンタイル）**を見ることでスパイクを見逃さない。
- 遅いクエリのログ（slow query log）も併用して監視。
3. ロック競合・デッドロック
- 特定のクエリやトランザクションが長くロックを保持している場合、他のクエリがブロックされやすくなる。
- PostgreSQLなら
pg_stat_activity、MySQLならINFORMATION_SCHEMAを定期チェック。
4. ディスク容量・バッファ使用率
- 監視が甘いと、ディスク満杯＝書き込み不能＝DBクラッシュの三段落ち。
- ディスクI/Oやバッファキャッシュのヒット率も確認し、性能劣化の兆候を早期に察知。
5. レプリケーションの遅延（複数台構成時）
- フェイルオーバー時に最新データが反映されていなければ、大事故につながる。
- PostgreSQLなら
replication lag、MySQLならSeconds_Behind_Masterを要監視。
アラート設計の鉄則：通知≠騒音
監視の次は、アラートの閾値と通知方法の設計です。
アラートは「異常」のみ通知せよ
- 常に通知が飛ぶ＝誰も見なくなる＝無視されるの悪循環。
- 「Warning（警告）」と「Critical（重大）」で通知先・チャネルを分ける。
- 例）Warning：Slack通知、Critical：PagerDuty連携で即時対応
閾値は「状態変化」を意識して設計する
- 接続数が“100超えたら通知”ではなく、“10分で急増したら通知”のように変化のトレンドを基準に。
- 一時的なスパイクと恒常的な異常を区別するため、連続回数や平均値を条件に組み込む。
アラートは「対応フロー」とセットで作る
- 通知が来た時点で「次に何をすればいいか」がわかるようにする。
- 通知内容に対応手順・ログリンク・関連チケットなどを含めておくと吉。
ベストプラクティス：ツール活用と文化の構築
Prometheus + Grafana は鉄板
- Prometheusでメトリクス収集 → Grafanaで可視化＆アラート設定。
- PostgreSQL用のExporter（pg_exporter）やMySQL用のExporterを導入すれば、主要指標を即監視可能。
障害対応はチームの「資産」にする
- 障害報告書（Postmortem）を必ず残す。
- 「なぜ検知できなかったか」「アラート設計のどこに穴があったか」を見直すことで、監視精度はどんどん上がっていく。
まとめ：監視は“見張り”ではなく“未来予測”
優れた監視・アラートは、単に異常を報せるだけではありません。
それはシステムの未来を予測し、運用者の判断を助けるナビゲーションなのです。
- 何を見張るか（メトリクス）
- どう知らせるか（アラート設計）
- どう動くか（対応手順）
この3点が設計された監視体制こそ、障害に強く、成長し続けるシステムの土台となります。
“運用は地味”とあなどるなかれ。そこに本当のプロフェッショナルの仕事がある。
