壊れる前に発報するデータベースアラートを設定する

公開 2026-09-02

見に行くことを覚えていなければならない監視は、監視ではありません。アラートの意義は、サーバのことを一切考えていないときに届くことです。そして通知に値する障害は、ダッシュボードが明示してくれるものとは限りません。

重要な障害

予告なく停止を招く頻度の高い順に、おおよそ次のとおりです。

• サービスの停止。自明ですが、依然として最も多い原因です。稼働していないデータベースはメトリクスを出さないため、数値を描画するだけの監視系は、全停止中でも安心できる横ばい線を表示し得ます。
• 接続の枯渇。サーバは正常ですが、これ以上クライアントを受け付けられません。アプリは接続エラーとして報告するため、ネットワーク障害と誤診されがちです。
• ディスクの逼迫。容量が尽きるとデータベースは深刻な壊れ方をし、失敗する書き込みはたいていトランザクションログです。完全に予測可能であり、驚かされるのは弁解の余地がありません。
• バックアップの静かな失敗。最悪の分類です。バックアップが必要になる日まで、目に見える異常が何もありません。
• レプリケーション遅延。エラーが出るずっと前から、読み取りが古いデータを返し始めます。

設定する

フリートにホストを追加し、データベースヘルスを向けると、チェックが定期実行されます。失敗はアラートに記録され、配信もそこで設定します。発報したチェックが、見ていないペインに留まるのではなく、実際に届くようになります。

配信は想像以上に重要です。アプリ内にだけ現れるアラートは、次にアプリを開いたとき（月曜かもしれません）に見るアラートです。通知・メール・チャットチャンネルで届けられ、Slack 連携はチームが既に会話している場所にサーバアラートを置き、同じスレッドから AI 管理者に問題を引き渡せます。

意図的にテストする

テストされていないアラート経路は推測にすぎません。ステージングホストでデータベースを停止し、期待どおりに届くか確認してください。アラート配信の失敗自体も追跡され、チャンネルがメッセージを受け付けなくなるとバッジが表示されます。配信できない通知系は、無いより悪いからです。誤った安心を生みます。

初動はアシスタントに任せる

アラートが発報したら、AI 管理者が初期切り分けを行えます。プロセス一覧を読み、設定を確認し、ログを見て、見つけたことを伝えます。承認しない限り読み取り専用のため、午前 3 時でも、合意していない変更を加えずに調査できます。

アプリ内のどこにあるか

実際の作業は データベース ▸ データベースヘルス ペインが担います。対象を選ぶと、稼働中の接続をすべて一覧表示し、注意すべきものを強調し、MySQL と PostgreSQL については、ログから推測するのではなく稼働中のサーバに対して「なぜ遅い／固まっているのか」を診断します。

データベースホストにエージェントをインストールする必要はありません。FrontierStack は既存の鍵を使って SSH でリンク済みサーバに接続し、データベース自身の管理インターフェース経由で読み取ります。

必要になる前にアラートを設定する

監視が役立つのは、壊れる前の瞬間です。フリートにホストを追加し、データベースヘルスを向け、チェックを定期実行させます。停止したデータベースは「問題なし」ではなく「データなし」として現れるため、明示的なアラートこそが、静かな障害を実際に届く通知へと変えます。