Redis and node-redis telemetry でイベントを送信して確認する
制御されたアプリケーション境界で Redis and node-redis telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
Redis キャッシュの信頼性
- 2
契約を定義する
操作、cache_name、ステータス、ヒット、および fallback_used
- 3
結果で発行する
Delivery is best-effort with a two-second fetch timeout. Ingestion failure preserves the application result or original error; verify the event with a query and use a durable outbox when loss is unacceptable.
- 4
証拠を検証する
Exercise a known fixture, then inspect cache_operation_completed for one correctly typed terminal row.
始める前に
始める前に
- An initialized node-redis client で a trusted Node.js runtime with fetch, AbortSignal.timeout, and a server-side Telemetry key
- 生のキーとコマンド引数を除外する限定された操作分類法
- コマンドの失敗、接続イベント、テレメトリ配信の失敗に対する個別のポリシー
配信設定
サーバー側のインストールと初期化
このサーバー側の例では、サーバー側のキーと時間制限付き fetch リクエストで Log API にイベントを送信します。Telemetry SDK の初期化は不要です。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install redis- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Redis and node-redis telemetryイベント
async function recordOutcome(data) {
try {
const receipt = await fetch("https://api.telemetry.sh/log", {
method: "POST",
headers: {
Authorization: process.env.TELEMETRY_API_KEY,
"Content-Type": "application/json",
},
body: JSON.stringify({ table: "cache_operation_completed", data }),
signal: AbortSignal.timeout(2_000),
});
if (!receipt.ok) console.warn("Telemetry ingestion failed", receipt.status);
} catch {
console.warn("Telemetry ingestion unavailable");
}
}
async function readCachedProject(projectId) {
const startedAt = performance.now();
let status = "success";
let errorType;
try {
const value = await redis.get(`project:${projectId}`);
await recordOutcome({
operation: "get_project",
key_namespace: "project",
status,
hit: value !== null,
latency_ms: Math.round(performance.now() - startedAt),
release: process.env.APP_RELEASE,
});
return value;
} catch (error) {
status = "failed";
errorType = "redis_error";
await recordOutcome({
operation: "get_project",
key_namespace: "project",
status,
hit: false,
latency_ms: Math.round(performance.now() - startedAt),
error_type: errorType,
release: process.env.APP_RELEASE,
});
throw error;
}
}イベントスキーマ
操作、cache_name、ステータス、ヒット、および fallback_used
latency_ms、error_type、再接続、リリース、および環境
key_namespace 顧客由来のキーではなく固定カテゴリの場合のみ
設定を確認する
チェックポイント 1
Delivery is best-effort with a two-second fetch timeout. Ingestion failure preserves the application result or original error; verify the event with a query and use a durable outbox when loss is unacceptable.
チェックポイント 2
測定する必要があるアプリケーション操作をラップします。 Redis クライアントにモンキーパッチを適用したり、デフォルトですべてのコマンドを発行したりしないでください。
チェックポイント 3
Redis URL、資格情報、生のキー、値、コマンド引数、チャネル メッセージ、または Lua ソースを決して送信しないでください。
チェックポイント 4
Node-Redis に必要な Redis エラー リスナーを維持しますが、再接続ストームによって 2 番目の過負荷が発生しないように、接続テレメトリのレート制限を行います。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Redis and node-redis telemetry 検証クエリ
SELECT *
FROM cache_operation_completed
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
イベントを記録する場所
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの例
このワークフローのイベントスキーマ
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
その他のSQL例
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
キャッシュミスとスタンピードのリスクを見つける
どのキャッシュ キー パターンが低いヒット率とバックエンドの同時作業を組み合わせていますか?
レシピを開く依存関係の比較 p95 レイテンシー
テール レイテンシーと失敗率が最も悪いダウンストリームの依存関係はどれですか?
レシピを開くローリングベースラインによるエラー率のスパイクの検出
最近のベースラインを大幅に上回っている時間単位のエラー率バケットはどれですか?
レシピを開くインシデントの検出と復旧時間を計算する
各サービスがインシデントを検出して回復するまでにどれくらいの時間がかかりますか?
レシピを開くイベント名によるTelemetryボリュームの測定
どのイベント コントラクトが最も多くの取り込み量を生み出しますか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
OpenTelemetry 構造化イベントのコンテキスト
ワークフロー境界で安全なトレースとスパン識別子を記録することで、Telemetry ビジネス イベントを既存の OpenTelemetry トレースに接続します。
オープンガイドGitHub アクション ワークフロー Telemetry の統合
実行、試行、ジョブ、結論、期間、リリース コンテキストを含む GitHub アクションから、制限されたターミナル ワークフロー結果を送信します。
オープンガイドKafka コンシューマ ラグと処理分析
Kafka コンシューマの結果、パーティション ラグ、処理遅延、再試行、構造化イベントによる有害メッセージの処理を監視します。
オープンガイド