オブザーバビリティとスロークエリログで本番を守る

なぜ本番障害は早期に検知しにくいのか

本番はめったに一瞬で「壊れる」わけではありません。多くの場合、静かに劣化します：いくつかのリクエストがタイムアウトし始め、バッチが遅れ、CPUがじわじわ上がり、最初に気付くのは顧客です—あなたの監視はまだ「緑」を示しているのに。

障害は原因ではなく症状として現れる

ユーザーからの報告はたいてい曖昧です：「遅く感じる」。それは多数の根本原因に共通する症状です—データベースのロック競合、新しいクエリプラン、欠けたインデックス、ノイジーネイバー、リトライストーム、あるいは断続的に失敗する外部依存など。

視認性が低いと、チームは推測に頼ることになります：

• 減速は全体的なものか、特定のエンドポイントだけか？
• デプロイ後、設定変更後、またはトラフィック急増の後に始まったか？
• アプリケーション、データベース、あるいはその間のネットワークか？

ダッシュボードはユーザーが感じるものを見ていない

多くのチームは平均値（平均レイテンシ、平均CPU）を追跡します。平均は痛みを隠します。ごく一部の非常に遅いリクエストが体験を台無しにする一方で、全体指標は問題なさそうに見えます。もし「稼働/停止」だけを監視しているなら、システムが技術的には稼働しているが実質的に使えない長い期間を見逃します。

オブザーバビリティ + スロークエリログ：補完関係

オブザーバビリティはシステムがどこで劣化しているか（どのサービス、どのエンドポイント、どの依存）を検出し絞り込むのに役立ちます。スロークエリログは、リクエストが停滞したときにデータベースが何をしていたか（どのクエリ、所要時間、どんな作業を行ったか）を証明するのに役立ちます。

このガイドは実践的です：より早く警告を得る方法、ユーザー向けレイテンシを特定のデータベース作業に結びつける方法、そして安全にクエリを調整する手順を扱います—ベンダー固有の約束に頼らずに。

オブザーバビリティの基本：メトリクス、ログ、トレース

オブザーバビリティとは、システムが生成する信号を見てその状態を理解できること—再現してみないとわからない、という状態から脱することです。ユーザーが遅さを感じていることを知るだけでなく、遅さがどこで起きているのか、なぜ始まったのかを突き止められる違いです。

三本柱（それぞれの利点）

メトリクスは時間経過の数値（CPU％、リクエスト率、エラー率、DBレイテンシ）です。クエリが速く、傾向や急上昇を見つけるのに向いています。

ログは詳細を持つイベント記録（エラーメッセージ、SQLテキスト、ユーザーID、タイムアウト）です。何が起きたかを人間が読める形で説明するのに最適です。

トレースはリクエストがサービスや依存をまたいで移動する様子を追います（API → アプリ → DB → キャッシュ）。どこに時間がかかっているか、どのステップが遅延を引き起こしたかを答えるのに理想的です。

有用なメンタルモデル：メトリクスは「何かが間違っている」と伝え、トレースは「どこで」、ログは「正確に何が」を教えてくれます。

良いオブザーバビリティが答えるべき質問

健全なセットアップはインシデントへの対応を助け、次のような明確な答えを提供します：

• 何が壊れたか？（エラー、タイムアウト、飽和）
• どこか？（どのエンドポイント、サービス、依存、またはクエリか）
• なぜ今か？（デプロイ、トラフィック変化、機能フラグ、データ成長）

監視とオブザーバビリティの違い（よくある混同）

監視は通常、事前定義されたチェックとアラート（「CPU > 90%」）に関することです。オブザーバビリティはさらに一歩進み、異常で未定義の障害モードに対して信号を切り分け、相関させて新しい質問を投げかける能力を提供します（例：ある顧客セグメントだけが遅いのは特定のDB呼び出しに紐づく、など）。

インシデント中に新しい質問をできる能力が、生のテレメトリを迅速で落ち着いたトラブルシューティングに変えます。

スロークエリログとは何か、何を明らかにするのか

スロークエリログは「遅い」と定義した閾値を超えたデータベース操作の記録です。一般的なクエリログ（全てを記録する）と違って、スロークエリログはユーザーに見えるレイテンシや本番障害を引き起こしやすいステートメントを際立たせます。

スロークエリログが通常記録する項目

ほとんどのデータベースは次のようなコアフィールドを取得できます：

• クエリ（多くは正規化されたSQLテキスト）
• 所要時間（合計時間、時には内訳付き）
• タイムスタンプ（開始・終了）
• コンテキスト：データベース／ユーザー、ホスト、アプリケーション名、参照／返却行数、場合によってはクエリプランやプランハッシュ

このコンテキストのおかげで「このクエリが遅かった」から「このサービスからこの接続プール経由でこの時刻に遅かった」に変わり、複数のアプリが同じDBを共有しているときに重要になります。

スロークエリが現れる理由

スロークエリログは通常、単独の「悪いSQL」だけの話ではありません。データベースが余計な作業をしたか、待ちに入ったサインです。一般的な原因：

• 欠けているまたは効果の薄いインデックス：フルスキャンや高コストな結合を強いる
• 悪い実行プラン（パラメータ値、統計の古さ、プランキャッシュ挙動が原因）
• ロック待ち・競合：実行時は速くても待ちが発生する
• 負荷スパイク：通常は問題ないクエリが同時実行やI/O圧迫で遅くなる

便利なメンタルモデル：スロークエリログは「作業（CPU/I/O負荷の高いクエリ）」と「待ち（ロック、飽和）」の両方を捉えます。

「遅い」の定義：閾値とパーセンタイル

単一の閾値（例：「500ms超を記録」）はシンプルですが、典型レイテンシがずっと低い場合に痛みを見逃すことがあります。組み合わせを検討してください：

• 固定閾値で本当に悪い外れ値を捕まえる
• パーセンタイルベースの視点（p95/p99）をメトリクスに加え、絶対時間が「許容範囲」に見えるときでも回帰を検出する

これによりスロークエリログは実行可能なまま、メトリクスはトレンドを表します。

プライバシーノート：機密値のログを避ける

パラメータがインライン化されると（メール、トークン、IDなど）スロークエリログが個人データを捕捉してしまうことがあります。パラメータ化クエリと、クエリ形状を記録する設定を優先してください。避けられない場合は、ログパイプラインで保存や共有前にマスキング／レダクションを加えます。

スロークエリがどのように障害やユーザー目に見えるレイテンシになるか

スロークエリはめったに「ただ遅い」だけでは終わりません。典型的な連鎖は：ユーザーのレイテンシ → APIレイテンシ → データベース圧迫 → タイムアウトです。ユーザーは最初にページのハングや読み込みの回転として感じます。間もなくAPIメトリクスに応答時間上昇が現れますが、アプリコードは変わっていないことがあります。

なぜデータベースの問題がアプリの問題に見えるのか

外から見ると、遅いデータベースは「アプリが遅い」に見えます。APIスレッドがクエリの完了を待ってブロックされるからです。アプリサーバのCPUやメモリは正常に見えても、p95/p99は上がります。アプリレベルのメトリクスだけ見ていると、HTTPハンドラやキャッシュ、デプロイを追いかけてしまい、本当のボトルネックである1つのクエリプランの後退を見逃します。

スロークエリが障害に波及する仕組み

一度クエリが遅れると、システムは対処しようとし、その対処が悪化させることがあります：

• リトライがトラフィックを増幅し、DB負荷を増やす
• 接続プール枯渇：リクエストが接続を長時間保持し、新規リクエストが待たされる
• キューの蓄積：ジョブワーカーやメッセージコンシューマのスループットが低下
• タイムアウトが部分的な失敗を引き起こし、さらにリトライや重複作業を招く

簡単なシナリオ

チェックアウトエンドポイントが SELECT ... FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 1 を呼ぶとします。データ量が増え、インデックスの効果が薄れてクエリ時間が20msから800msに上がったとします。通常時は迷惑ですが許容できます。ピークトラフィック下では、APIリクエストがDB接続を待って積み上がり、2秒でタイムアウトし、クライアントがリトライします。数分で「小さな」スロークエリがユーザー目に見えるエラーになり、本番障害になります。

データベースの痛みを早く示すメトリクス

DBが苦しみ始めると、最初の手がかりは限られたメトリクスセットに現れます。目的はすべてを追うことではなく、変化を早く検出して原因箇所を絞ることです。

ゴールデンシグナルから始める

次の4つは、DB問題かアプリ問題か、あるいは両方かを判断するのに役立ちます：

• レイテンシ：上がるp95/p99は顧客が最初に感じる兆候であることが多い
• トラフィック：トラフィックスパイクは原因（負荷増）でも結果（リトライ）でもあり得る
• エラー：タイムアウト、5xx、DBエラーコードを監視
• 飽和：DBは「稼働中」でも飽和していることがある—CPU、I/O、接続数、ロック競合

監視すべきコアDBメトリクス

いくつかのDB固有チャートが、ボトルネックがクエリ実行、同時実行、またはストレージにあるかを示します：

• クエリレイテンシ分布（平均だけでなく）：テール（p95/p99）の重みや分散の増加を見てください
• 接続とプール利用率：アクティブ接続の増加、プール内のキューイング、頻繁な枯渇
• ロックと待ち時間：ロック待ち時間やデッドロックは突然のレイテンシジャンプと相関することが多い
• キャッシュヒット率／バッファキャッシュ効率：低下は作業セットが合わなくなり、ディスク読みが増えることを意味する

サービスレベルの指標でDBを特定する

DBメトリクスとサービスの体験を組み合わせます：

• リクエスト率とタイムアウト（上流タイムアウト含む）
• エンドポイント別 p95/p99 レイテンシ：単一エンドポイントの劣化は1つのクエリパターンを示唆する
• リトライ率：リトライは負荷を増幅し、本来のトリガーを隠す

適切な質問に答えるダッシュボード設計

ダッシュボードは素早く次を答えられるように設計します：

• これは新しい問題か？ 昨日／先週の同時刻と比較
• 孤立しているか？ 1つのエンドポイントか、1テナントか、1ノードか、1AZか
• 成長しているか？ 飽和が上昇してキューが形成されているか

これらの指標が揃ったら—テールレイテンシの上昇、タイムアウトの増加、飽和の上昇—スロークエリログとトレースに pivot して正確な操作を特定します。

遅い操作を正確に突き止めるためのトレース

スロークエリログはDB内で「何が」遅かったかを示します。分散トレーシングは「誰がそれを要求したか」「どこから」「なぜ重要だったか」を示します。

勘ではなくリクエストを追う

トレースがあると「DBが遅い」アラートは具体的な物語になります：特定のエンドポイント（またはバックグラウンドジョブ）が一連の呼び出しをトリガーし、そのうちの1つがDB操作の待ちに大部分の時間を費やしている、という具合です。

APMのUIでは、高レイテンシのトレースから次を見ます：

• リクエストを開始したルートやジョブ名（例：GET /checkout や billing_reconcile_worker）
• 異常に長いdurationやtime-to-first-rowを持つデータベーススパン
• 遅さが1種類のリクエストに限られるか、広く発生しているか

スパンに安全にタグ付けする（SQLを漏らさない）

トレースにフルSQLを入れるのはリスクがあります（PII、シークレット、大きなペイロード）。実用的な方法は、スパンにクエリ名／操作をタグ付けすることで、フル文を出さずに検索可能にすることです：

• db.operation=SELECT と db.table=orders
• app.query_name=orders_by_customer_v2
• feature_flag=checkout_upsell

これによりトレースは安全で検索可能になり、コードパスを指し示します。

IDで全てを相関させる

「トレース」→「アプリログ」→「スロークエリエントリ」へ橋渡しする最速の方法は共通の識別子です：

• trace ID をアプリログに伝搬させる
• 可能であれば、スロークエリログのコンテキストに trace ID（あるいはリクエストID）を追加する、または安全にサポートされる場合クエリ内コメントに入れる

これで高価値な質問に速く答えられます：

• どの ルート や ワーカー が遅い呼び出しをトリガーしたか？
• 特定の テナント／顧客、リージョン、プラン に紐づくか？
• リリース や設定変更の後に始まったか？
• 1つの高コストなクエリか、多数の小さなクエリのバーストか（N+1）？

データ量に溺れないスロークエリログの設定

スロークエリログは読みやすく実行可能であるときにのみ有用です。目的は「すべてを永遠にログする」ことではなく、クエリが遅い理由を説明するのに十分な詳細を、目立ったオーバーヘッドやコスト問題を起こさずにキャプチャすることです。

アプリの感触に合う閾値を選ぶ

まずユーザー期待とDBの役割に合わせた絶対閾値を設定します。

• 絶対例：OLTP中心なら >200ms、混在ワークロードなら >500ms

次に、システム全体が遅くなったときでも問題を見つけられるよう相対ビューを追加します。

• 相対例：「1分あたり上位100件」や「上位1%の遅いステートメント」

両方を使うと見落としを防げます：絶対閾値は常に悪いものを捕まえ、相対閾値は繁忙時の回帰を検出します。

賢くサンプリングし、実際に使うコンテキストをキャプチャする

ピーク時にすべての遅いステートメントをログするとパフォーマンスやノイズに悪影響を与えます。サンプリング（例：遅いイベントの10–20%を記録）を優先し、インシデント時にのみサンプリング率を上げます。

各イベントに次のようなアクション可能なコンテキストを含めてください：所要時間、参照／返却行数、データベース／ユーザー、アプリ名、可能ならリクエストIDやtrace ID。

クエリを正規化してパターンを浮かび上がらせる

生のSQLは散らかりがちです：異なるIDやタイムスタンプで同一クエリが別物に見えます。クエリフィンガープリント（正規化）を使って類似ステートメントをグルーピングし、例えば WHERE user_id = ? のようにします。

これで「どのクエリ形状が最もレイテンシを引き起こしているか？」に答えられます。

インシデント周りでのプラン保持とコスト

比較（before/after）に十分な期間だけ詳細なスロークエリログを保持します—実用的な開始点は通常 7–30日 です。

ストレージが問題なら古いデータをダウンサンプル（集計と上位フィンガープリントを残す）し、最近のウィンドウだけフルフェデリティを保持します。

顧客が気づく前に遅延を捉えるアラート設計

アラートは「ユーザーがこれを感じる前に」知らせ、最初にどこを見るべきかを教えるべきです。その最も簡単な方法は、症状（ユーザーが感じること）と原因（それを引き起こしているもの）に基づくアラートを組み合わせ、オンコールが無視するように学習しないようノイズを制御することです。

症状に基づくアラート（ユーザー影響）

ユーザーの痛みに相関する高シグナルの指標から始めます：

• 重要エンドポイントごとの 上昇する p95/p99 レイテンシ（平均ではなく）
• タイムアウト率（アプリや上流のタイムアウト）とリトライ率
• キュー深度／ワーカー飽和（スレッドプール、接続プール）
• データベースのロック待ち とブロックされたトランザクション

できればアラートを「ゴールデンパス」（checkout、login、search）に限定し、低重要度ルートでページングしないようにします。

原因に基づくアラート（調査開始を早める）

症状アラートに加えて診断を短縮する原因指向のアラートを出します：

• トップスローフィンガープリントが閾値を超えた（例：p95または総消費時間）
• プラン変化（走査行数の突然のシフト、フルテーブルスキャン、新たに使われなくなったインデックス）
• データベース層のエラー急増（デッドロック、接続過多、クエリキャンセル）

これらのアラートにはできればフィンガープリント、サニタイズしたパラメータの例、関連ダッシュボードやトレースビューへの直接リンクを含めます。

ノイズを減らしつつ実際のインシデントを見逃さない

利用する手法：

• SLOに対するバーンレートアラート（急激な悪化には早いページ、持続的な劣化には遅いページ）
• 複数ウィンドウチェック（例：5分と30分）でフラッピングを避ける
• 重複排除とグルーピング（サービス/DB + フィンガープリントごとに1インシデント）

すべてのページには「次に何をするか？」を含めるべきです—/blog/incident-runbooks のようなランブックへのリンクと最初の3チェック（レイテンシパネル、スロークエリリスト、ロック／接続グラフ）を指定します。

実践的なインシデントワークフロー：スパイクから根本原因へ

レイテンシがスパイクしたとき、迅速な回復と長引く障害との差は繰り返し可能なワークフローを持っているかどうかです。目標は「何かが遅い」から特定のクエリ、エンドポイント、そしてそれを引き起こした変更へと移ることです。

1) 検知 → それが実在するか確認

ユーザー症状（高レイテンシ、タイムアウト、エラー率増）から始めます。

p95/p99 レイテンシ、スループット、データベース健全性（CPU、接続、キュー／待ち時間）のような高シグナル指標で確認します。単一ホストの異常に踊らされず、サービス全体のパターンを見てください。

2) 範囲特定 → 誰と何が影響を受けているか

被害範囲を絞ります：

• どのエンドポイントが遅いか（p95で上位のルート）？
• 全顧客か一部か（テナント、リージョン、プラン）？
• 明確な時刻境界で始まったか（デプロイ、バッチ、トラフィック変化）？

このスコーピングで間違った対象を最適化するのを防げます。

3) 分離 → トレースで遅い操作を見つける

遅いエンドポイントの分散トレースを開き、最も長いもの順に並べます。

リクエストを支配するスパン（DB呼び出し、ロック待ち、または繰り返しのクエリ（N+1））を探します。リリースバージョン、テナントID、エンドポイント名などのコンテキストタグと照らし合わせ、遅延がデプロイや特定の顧客ワークロードと一致するか確認します。

4) 確認 → トレースとスロークエリログを結びつける

疑わしいクエリをスロークエリログで検証します。

フィンガープリント（正規化クエリ）に注目し、総消費時間と件数で最悪のものを見つけます。影響を受けるテーブルや述語（フィルタや結合）を確認してください。ここで欠けたインデックス、新たな結合、クエリプランの変化が判明することが多いです。

5) 緩和 → ユーザー影響を安全に減らす

リスクの低い緩和を最初に選びます：リリースをロールバックする、機能フラグを無効にする、負荷を削る、接続プール上限を増やす（競合を悪化させない場合のみ）等です。クエリを変更するなら、小さく測定可能な変更を行ってください。

配信パイプラインがそれをサポートするなら、ロールバックをヒーロー行為でなく第一選択可能なボタンとして扱ってください。Koder.ai のようなプラットフォームはスナップショットとロールバックワークフローでこれを支援し、遅いクエリパターンを偶発的に導入したリリースでの緩和時間を短くできます。

6) 文書化 → 次のインシデントを短くする

何が変わったか、どう検知したか、正確なフィンガープリント、影響を受けたエンドポイント／テナント、そして何が効いたかを記録します。それをフォローアップに変え、アラート追加、ダッシュボードパネル、パフォーマンスのガードレール（例：「p95でクエリフィンガープリントがX msを超えない」）などを設定します。

本番でスロークエリを安全に直す方法

スロークエリが既にユーザーに影響を与えているときは、まず影響を減らし、その後パフォーマンスを改善します—インシデントを悪化させないことが最優先です。オブザーバビリティデータ（スロークエリサンプル、トレース、主要なDBメトリクス）はどのレバーを引くのが最も安全かを教えてくれます。

1) 低リスクの緩和で安定化

データ動作を変えない変更から始めます：

• 機能フラグ：重いエンドポイントやレポート、検索フィルタ、「最近のアクティビティ」パネルなどを一時的に無効化
• レート制限／クォータ：トレースで最もトラフィックを生成しているルートや顧客を絞る
• キャッシュ：読み取りが多いエンドポイントに短時間のキャッシュ（30–120秒でもDB負荷を劇的に下げる）
• 高コストパスの無効化：オプションのJOINや重いソート、深いページングをフラグで外す

これらの緩和は時間を稼ぎ、p95レイテンシやDBのCPU/I/Oメトリクスで即時の改善が見られるはずです。

2) データベース内の修正：ターゲットを絞って検証可能に

安定化後、実際のクエリパターンを治します：

• インデックス追加：クエリのフィルタ＋ソートに合うインデックスを作る。EXPLAINで検証し、走査行数が減ることを確認する
• クエリ書き換え：走査データを減らす（選択列を減らす、SELECT *を避ける、選択的な述語を追加、相関サブクエリの置換）
• N+1削減：IDをバッチ化、プリフェッチ、または慎重に選んだJOINで単一クエリにまとめる

変更は段階的に行い、同じトレース／スパンとスロークエリ署名で改善を確認します。

3) コード変更がすぐにできない場合の運用的緩和

• キャパシティ増強（リードレプリカ、インスタンスサイズ増）で出血を止める
• 接続プール調整でキューイングとスレッド枯渇を防ぐ
• タイムアウト調整でシステムが素早く失敗して積み上がるのを防ぐ

ロールバック：戻すかホットフィックスか

変更がエラー、ロック競合、負荷シフトを予測できない方法で増やすならロールバックします。ホットフィックスは変更を1つのクエリや1つのエンドポイントに限定でき、前後のテレメトリで安全性を検証できる場合に行います。

再発防止：SLOとパフォーマンスガードレール

スロークエリを本番で直した後、本当の勝利は同じパターンが微妙な形で戻らないようにすることです。明確なSLOといくつかの軽量ガードレールが、1回のインシデントを恒久的な信頼性につなげます。

ユーザーが感じるものに紐づけたSLO

まずユーザー体験に直接結びつくSLIを設定します：

• 主要ルート／テナント別の p95（とp99）エンドポイントレイテンシ
• エラー率（タイムアウト、5xx、キャンセルによる“ソフトエラー”）
• 遅延と相関する飽和指標（DB CPU、接続プール待ち時間）

SLOは完璧さではなく、許容できるパフォーマンスを反映するように設定します。例：「p95 チェックアウトレイテンシを99.9%の分で600ms未満」。SLOが脅かされれば、リスクのあるデプロイを停止しパフォーマンスに注力する客観的理由になります。

リリース単位での回帰追跡

多くの再発は回帰です。各リリースの前後比較を簡単にしておくと発見が早まります：

• 同じエンドポイントのトレースを比較し、新しいスパンが総時間を支配していないか見る
• スロークエリフィンガープリントを比較して、新しいクエリ形状、欠けたインデックス、走査行数の急増を検出する

重要なのは平均ではなく分布（p95/p99）の変化をレビューすることです。

重要パスのパフォーマンステスト

「遅くなってはいけない」エンドポイントとその重要クエリを少数選び、CIにパフォーマンスチェックを入れて閾値や許容ドリフトを超えたら落とすようにします。これによりN+1のバグ、意図しないフルテーブルスキャン、境界のないページングをリリース前に捕まえられます。

高速にサービスを作る場合（例：Reactフロントエンド、Goバックエンド、PostgreSQLスキーマを素早く生成・反復するKoder.ai のようなチャット駆動型アプリビルダー）、これらのガードレールはさらに重要です：速度は機能ですが、最初からテレメトリ（trace ID、クエリフィンガープリント、安全なログ）を組み込まないと意味がありません。

所有権とレビューのリズムを作る

スロークエリレビューを誰かの仕事にします：

• サービス／データベースごとにオーナーを割り当てる
• スロークエリレポートを定期（週次程度で十分）にレビューする
• 短いバックログを保つ：クエリフィンガープリント、疑わしい原因、次のアクション、期待される影響

SLOで「良い状態」を定義し、ガードレールでドリフトを捕まえれば、パフォーマンスは繰り返しの緊急ではなく、配信の管理された一部になります。

データベース向けオブザーバビリティに何を期待するか

DBに焦点を当てたオブザーバビリティセットアップは速く2つの質問に答えられるべきです：「データベースがボトルネックか？」 と 「どのクエリ（どの呼び出し元）が原因か？」。良いセットアップはそれを明らかにします—エンジニアが1時間も生ログをgrepする必要がないように。

実践的チェックリスト

必要なメトリクス（インスタンス、クラスタ、役割／レプリカごとに分けてあるのが理想）：

• クエリレイテンシ（p50/p95/p99）、スループット（QPS）、エラー率
• 接続プール利用率、アクティブ／アイドル接続、待ち時間
• ロック：ロック待ち時間、デッドロック、行ロック競合
• リソース信号：CPU、メモリ、ディスクI/O、キャッシュヒット率
• レプリケーション遅延（該当する場合）

スロークエリログに必要なログフィールド：

• タイムスタンプ、所要時間、データベース／スキーマ、ユーザー／ロール、クライアント／アプリ識別子
• 正規化クエリまたはフィンガープリント、許可される場合にのみフルテキストを安全に見る方法
• 参照／返却行数、クエリプランハッシュ（可能なら）

相関のためのトレースタグ：

• service.name、endpoint/route、environment、version
• db.system、db.name、db.statement のフィンガープリント、db.operation
• ログに渡された request_id / trace_id

期待すべきダッシュボードとアラート：

• “DB痛み”の概要：p95レイテンシ + QPS + 接続待ち + ロック待ち
• トップNクエリフィンガープリント（総消費時間別、p95別）
• 持続的なp95/p99上昇、ロック待ち急増、プール飽和（CPUだけでなく）をアラート

ツールやベンダーに問うべきこと

エンドポイントレイテンシのスパイクを特定のクエリフィンガープリントとリリースバージョンに結びつけられますか？レアで高コストなクエリを保持するためのサンプリングはどう扱いますか？ノイズの多いステートメントをフィンガープリントで重複排除し、時間的回帰をハイライトできますか？

妥協してはいけないデータ処理

組み込みのレダクション（PIIとリテラルの削除）、RBAC、ログとトレースの明確な保持制限を探してください。データをデータウェアハウス／SIEMにエクスポートするときにこれらの制御をバイパスしないことを確認します。

ベンダー評価中なら、要件を早めに揃え内部でショートリストを共有し、ベンダーを巻き込むと良いでしょう。簡単な比較やガイダンスが欲しければ /pricing を参照するか /contact で連絡してください。