Prisma ORM Database Telemetry: 境界から検証された行まで
制御されたアプリケーション境界で Prisma ORM Database Telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
Prisma 操作のレイテンシ
- 2
契約を定義する
query_fingerprint、prisma_model、prisma_operation、およびワークフロー
- 3
境界を計測する
発行された SQL を転送する代わりに、User.findMany.active などの明示的なフィンガープリントを使用して製品レベルの Prisma 呼び出しをラップします。
- 4
証拠を検証する
Exercise a known fixture, then inspect database_query_completed for one correctly typed terminal row.
始める前に
前提条件と境界
- サーバー上で Prisma クライアントが初期化されました
- アプリケーション呼び出しサイトで選択される安定した操作名
- サーバー側 TELEMETRY_API_KEY
配信設定
サーバー側のインストールと初期化
サーバー専用コードで telemetry-sh をインポートし、process.env.TELEMETRY_API_KEY で一度初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install telemetry-sh- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Prisma ORM Database Telemetryイベント
import telemetry from "telemetry-sh";
const SAFE_DATABASE_ERROR_CODES = new Set(["P2024", "P2034"]);
function classifyDatabaseError(error) {
return error && typeof error === "object" &&
"code" in error &&
SAFE_DATABASE_ERROR_CODES.has(String(error.code))
? String(error.code)
: "database_error";
}
async function observePrismaOperation({
queryFingerprint,
model,
operation,
workflow,
run,
}) {
const startedAt = performance.now();
try {
const result = await run();
await telemetry.log("database_query_completed", {
query_fingerprint: queryFingerprint,
prisma_model: model,
prisma_operation: operation,
workflow,
database_name: "app_production",
status: "success",
duration_ms: Math.round(performance.now() - startedAt),
rows_returned: Array.isArray(result) ? result.length : 1,
release: process.env.APP_RELEASE,
environment: process.env.NODE_ENV,
});
return result;
} catch (error) {
await telemetry.log("database_query_completed", {
query_fingerprint: queryFingerprint,
prisma_model: model,
prisma_operation: operation,
workflow,
database_name: "app_production",
status: "failed",
duration_ms: Math.round(performance.now() - startedAt),
error_type: classifyDatabaseError(error),
release: process.env.APP_RELEASE,
environment: process.env.NODE_ENV,
});
throw error;
}
}
const users = await observePrismaOperation({
queryFingerprint: "User.findMany.active",
model: "User",
operation: "findMany",
workflow: "account_directory",
run: () => prisma.user.findMany({ where: { active: true } }),
});イベント契約
query_fingerprint、prisma_model、prisma_operation、およびワークフロー
ステータス、duration_ms、rows_returned、制御対象 error_type、および account_id
database_name、リリース、環境、および安全な相関識別子
実装のチェックポイント
チェックポイント 1
発行された SQL を転送する代わりに、User.findMany.active などの明示的なフィンガープリントを使用して製品レベルの Prisma 呼び出しをラップします。
チェックポイント 2
データベースの回帰を顧客の目に見える行動に結びつけることができるように、モデル、オペレーション、ワークフローを分離しておきます。
チェックポイント 3
PrismaのクエリイベントはSQLとパラメーターを公開します;どちらのフィールドも Telemetry に送信しないでください。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Prisma ORM Database Telemetry 検証クエリ
SELECT *
FROM database_query_completed
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
生産境界
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの開始点
このワークフローのイベント コントラクト
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します SQL クエリ API
構造化イベント テーブルに対して読み取り専用 DataFusion SQL を実行し、結果を再利用します。
関連する SQL レシピ
SQL で次の質問に答えてください
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
遅いデータベース クエリをフィンガープリントで検出する
調査するには十分なほど常に遅いデータベース操作はどれですか?
レシピを開くデータベースクエリを合計時間の影響でランク付けする
どのデータベース操作が最も累積リクエスト時間を消費しますか?
レシピを開くデータベーストランザクションのロールバック率の計算
異常な割合のデータベース トランザクションをロールバックするサービスはどれですか?
レシピを開く長時間実行されるデータベース トランザクションの測定
どのアプリケーション トランザクション クラスが最も長く開いたままになりますか?
レシピを開くデータベースのロック待機とデッドロックの検索
最も深刻なロック競合を引き起こすデータベース操作はどれですか?
レシピを開くSQLSTATEとリリースによるデータベースエラーの分析
アプリケーションのリリース後に増加したデータベース エラー クラスはどれですか?
レシピを開くデータベース移行の失敗をリリースごとに追跡する
失敗したデータベース移行またはロールバックされたデータベース移行はどのリリースに含まれていますか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
node-postgres プールとクエリ Telemetry
SQL パラメーターをログに記録することなく、ノード Postgres クエリのフィンガープリント、接続の取得、プールの圧力、タイムアウト、トランザクションの結果、データベース エラーを計測します。
オープンガイドMongoDB 操作 Telemetry
ドキュメントやクエリ値を収集せずに、名前付き MongoDB 操作、レイテンシ、結果数、再試行、トランザクション結果、リリース回帰を追跡します。
オープンガイドMySQL クエリとプール Telemetry
生の SQL やパラメータを保存せずに、正規化された MySQL 操作、プール待機、トランザクション結果、制御されたエラー カテゴリを追跡し、リグレッションをリリースします。
オープンガイド