SQL によるデータベース信頼性監視

データベースの症状は、サーバー メトリックで明らかになる前にアプリケーションに現れることがよくあります。呼び出し元が接続を待機する、ワン オペレーションのフィンガープリントが遅くなる、トランザクションがロールバックする、ロックがユーザーの作業をブロックする、レプリカが遅れをとる、リリース中に移行が失敗するなどです。構造化されたアプリケーション イベントは、これらの結果をサービス、リリース、ルート、テナントへの影響、および対応に必要な制御されたエラー カテゴリに結び付けます。

アプリケーション境界で制限されたイベントを発行する

データベース操作または論理トランザクションごとに 1 つの完了イベントを記録します。未加工の SQL の代わりに、制御された操作名または正規化されたフィンガープリントを使用します。影響分析をサポートする場合にのみ、期間、結果、データベースの役割、サービス、リリース、およびプライバシー審査済みのアカウント ID を含めます。

クエリ パラメーター、接続文字列、資格情報、承認データ、または無制限の SQL テキストを決してログに記録しないでください。次のようなエラー カテゴリ deadlock, serialization_failure、そして connection_timeout 生の例外メッセージよりも安全で、グループ化が簡単です。

{
  "event_name": "database_query_completed",
  "query_fingerprint": "checkout.select_with_line_items",
  "service": "checkout-api",
  "database_name": "app_production",
  "status": "success",
  "duration_ms": 842,
  "rows_returned": 4,
  "release": "2026.07.2",
  "environment": "production"
}

を使用します。 ノードとPostgresの統合 または プリズマの統合 まず開始点として、ラッパーを一元化して、すべての操作で同じフィールド名、クロック、ステータス値、リダクション ポリシーが使用されるようにします。

信頼性に関する質問を分離する

1 つの一般的な「データベースの健全性」スコアには、さまざまな障害モードが隠されています。以下の場合には、フォーカスされたイベント テーブルまたは安定したイベント名を使用します。

1. クエリの完了: 期間、正規化されたフィンガープリント、行、結果、リリース。
2. プールの状態: アクティブ、アイドル、設定された最大値、取得待機、およびタイムアウト。
3. トランザクション: 論理トランザクション識別子、コミットまたはロールバック、および制御されたエラーのタイプ。
4. ロック待機: ブロックされている指紋とブロックされている指紋、待機期間、解決策、およびデッドロックの検出。
5. レプリケーションまたは CDC: コンシューマ、リージョン、遅れている秒数とバイト数、および現在のステータス。
6. 移行: 移行識別子、リリース、期間、終了ステータス、およびロールバック カテゴリ。

の データベース信頼性レシピ集 スキーマ、テストされたクエリ、決定論的な結果、視覚化、エッジ ケース、ダッシュボード プラン、および各質問のアラート ガイダンスが含まれています。付属のフィクスチャは読み取り専用で実行できます。 ブラウザ SQL プレイグラウンド それらを適応させる前に。

OpenTelemetry データベース フィールドを意図的にマップする

アプリケーションがすでに OpenTelemetry データベース スパンを発行している場合は、競合する語彙を作成する代わりに、フィールドの安定した意味を再利用します。現在の OpenTelemetry データベース クライアントのスパン規則 定義する db.system.name、カーディナリティが低い db.operation.name, db.namespace, db.collection.name, db.query.summary、およびデータベース応答ステータスのコンテキスト。また、クエリ テキストはカーディナリティが高く、サニタイズが必要になる可能性があることも警告しています。

実際の構造化イベント マッピングは次のとおりです。

マッピングは、フィールドが安全であることを自動的に証明するものではありません。一部のシステムでは、クエリの概要、コレクション名、名前空間、および応答メッセージによってテナントまたはスキーマの詳細が公開される可能性があります。実際に出力された値を確認し、カーディナリティを制限し、生のクエリ テキストとバインドされた値をデフォルトで除外します。

順番に調べてみる

まず、顧客が認識できる期間と障害率から始めて、プールの取得によってレイテンシが説明できるかどうかを確認します。 p95 の期間と合計クエリ時間の両方によって操作をランク付けします。中程度に遅いクエリが何千回も実行されると、まれな外れ値よりも多くのアプリケーション時間が消費される可能性があります。生のメッセージをグループ化するのではなく、操作およびリリースごとに SQLSTATE または別の制御されたドライバー コードを比較します。

エラーがトランザクション的な場合は、予想される再試行可能なロールバックを端末エラーから分割し、長時間実行されるトランザクション クラスを個別に確認します。同時ライターが関係する場合のロック待機イベントとデッドロック イベントを検査します。プールの飽和をサイジングの問題として解釈する前に、接続のオープン、クローズ、取得タイムアウト、影響を受けるリクエストを比較してください。ダウンストリーム読み取りモデルを信頼する前に、アプリケーションで観察された古い読み取りとフェイルオーバーの結果に加えて、レプリカまたは CDC ラグを確認してください。移行の失敗を展開のタイムスタンプと一致させます。

使用率だけで接続プールの制限を増やさないでください。プールが大きくなると、データベースに競合が発生する可能性があります。待機中の呼び出し元またはタイムアウトを要求し、データベース容量を確認し、変更を監視します。

アプリケーション側の境界を知る

これらのイベントは、どのアプリケーション ワークフロー、リリース、リージョン、または顧客向けリクエストにデータベースの症状が発生したかを示します。これらは、データベース独自の診断システムに代わるものではありません。データベース ネイティブ ツールは次の目的で使用します。

• クエリ プラン、オプティマイザの推定、バッファとキャッシュの動作、テーブルの統計、バキュームまたは圧縮の状態。
• サーバー待機イベント、ロック グラフ、アクティブ セッションの検査、ストレージの待機時間、およびリソースの飽和。
• レプリケーション トポロジ、先行書き込みログ保持、フェイルオーバー オーケストレーション、バックアップ検証、ポイントインタイム リカバリ。
• データベースまたはセキュリティ プログラムに必要な、権威ある監査、アクセス制御、暗号化、およびコンプライアンスの証拠。

調査中に 2 つのビューを結合します。構造化されたアプリケーション イベントを使用して影響と所有権を特定し、次に制限されたデータベース診断を使用してサーバー側の原因を説明します。結合を便利にするためだけに、機密のサーバー診断を広範な分析テーブルにコピーすることは避けてください。

検証されたクエリをオペレーションに変換する

ダッシュボードは、すべてのレートに加えてボリュームを維持し、完全な UTC バケットを使用し、集計から最近の安全なイベントへのパスを保存する必要があります。アラートには、継続的な状態、最小ボリューム、所有者、および文書化された応答が必要です。単一の遅いクエリ、短期間のラグスパイク、または予想されるロールバックによってページが正当化されることはほとんどありません。

クエリに依存する前に、合成の成功、タイムアウト、デッドロック、重複、遅延イベントのケースをテストします。ダッシュボードの横にイベントのバージョンとしきい値を記録します。の SQL 方法論 自動レシピチェックについて説明します。の データベースの信頼性のユースケース 結果の信号を実装ワークフローに接続します。