イベント契約
クエリが期待するフィールド
| フィールド | 種類 | なぜ存在するのか |
|---|---|---|
| timestamp_utc | Timestamp | ロック待ちが観察されたとき。 |
| database_name | Utf8 | 承認された論理データベース名。 |
| blocked_query_fingerprint | Utf8 | ブロックされたアプリケーション操作の正規化されたラベル。 |
| blocking_query_fingerprint | Utf8 | ロックを保持する操作の正規化されたラベル。 |
| lock_type | Utf8 | 制御されたロックのカテゴリ。 |
| wait_ms | Float64 | ミリ秒単位で観測されたロック待機。 |
| resolved | Boolean | 待機がブロックされたままにならずに終了したかどうか。 |
| deadlock_detected | Boolean | データベースがデッドロックの結果を報告したかどうか。 |
| transaction_id | Utf8 | アプリケーションセーフなトランザクション識別子。 |
| environment | Utf8 | 導入環境。 |
クエリをコピーする
SELECT
database_name,
blocked_query_fingerprint,
blocking_query_fingerprint,
COUNT(*) AS lock_wait_incidents,
COUNT(DISTINCT transaction_id) AS affected_transactions,
AVG(wait_ms) AS average_wait_ms,
MAX(wait_ms) AS maximum_wait_ms,
SUM(CASE WHEN NOT resolved THEN 1 ELSE 0 END) AS unresolved_incidents,
SUM(CASE WHEN deadlock_detected THEN 1 ELSE 0 END) AS deadlocks
FROM database_lock_wait_events
WHERE timestamp_utc >= now() - INTERVAL '7 days'
AND environment = 'production'
GROUP BY
database_name,
blocked_query_fingerprint,
blocking_query_fingerprint
HAVING COUNT(*) >= 3
ORDER BY deadlocks DESC, maximum_wait_ms DESC;この読み取り専用クエリは、空の型付きテーブルに対して計画され、実行されます。 アパッチ DataFusion 45.2.0。決定論的なサンプル出力は合成され、個別にレビューされます。フィールド タイプ、しきい値、ビジネス定義を独自のデータと照合して検証します。 テスト方法を読んでください。
クエリ結果
ブロックされた操作による最大ロック待機時間
注文の更新には、待ち時間の延長、未解決のインシデント、検出されたデッドロックが表示されます。
| database_name | blocked_query_fingerprint | blocking_query_fingerprint | lock_wait_incidents | affected_transactions | average_wait_ms | maximum_wait_ms | unresolved_incidents | deadlocks |
|---|---|---|---|---|---|---|---|---|
| app_production | UPDATE orders SET status = ? | SELECT order FOR UPDATE | 8 | 8 | 1,600 | 3,200 | 2 | 2 |
| analytics_production | REFRESH customer_summary | INSERT customer_event | 6 | 6 | 500 | 700 | 0 | 0 |
合成出力例。運用上の決定に使用する前に、独自のイベント スキーマとしきい値に対してクエリを実行します。
例を再現する
パブリックフィクスチャをダウンロードする
JSON バンドルには、型付きイベント コントラクトが含まれています。 reproducible 入力行、正確な SQL、予想される出力、レビューメモ、およびエンジンのバージョン。 CSV には、表示された結果が含まれます。
SQL の仕組み
- 1ブロックされたフィンガープリントとブロッキング フィンガープリントにより、パラメーター化された SQL を収集せずに競合関係が表示されたままになります。
- 2個別のトランザクション数により、同じ待機の繰り返しサンプルから結果が保護されます。
- 3デッドロックや未解決のインシデントは、単に高い平均待ち時間よりも優先されます。
決定すべきエッジケース
- ポーリングでは、1 つのインシデントに対して複数の観測値を出力できます。トランザクションまたはインシデントの識別子を保存します。
- データベース ロック ビューでは、機密性の高いステートメント テキストが公開される可能性があります。イベントを発行する前に収集時に正規化します。
- 予想されるメンテナンス ロックには、セグメント化できるように承認されたワークロード カテゴリが含まれている必要があります。
推奨されるダッシュボード
- バー: maximum_wait_ms by blocked_query_fingerprint
- 表: ブロッカーとブロックされた指紋のペア
- 統計: 未解決のインシデントとデッドロック
レシピを活用する
関連する機器とガイド
分析を続ける
遅いデータベース クエリをフィンガープリントで検出する
生の SQL やパラメーターを保存せずに、正規化されたデータベース操作を低速クエリ レート、平均継続時間、観測された最悪の継続時間によってランク付けします。
レシピを開くデータベース接続プールの飽和状態を測定する
平均プール使用率、キューに入れられた取得待機、タイムアウト、およびアプリケーション サービスごとのアイドル容量を測定します。
レシピを開くデータベーストランザクションのロールバック率の計算
エラー カテゴリ、期間、影響を受けるアカウントを維持しながら、コミットされたトランザクションとロールバックされたトランザクションをサービスごとに比較します。
レシピを開く実際のイベントで実行する
テーブルを作成し、フィールドを調整して、結果を保存します
無料で始めて、構造化されたイベントを送信し、クエリ結果をグラフ、共有ダッシュボード ウィジェット、またはアラート入力として使用します。