Send and verify events with Redis and node-redis telemetry
Use Redis and node-redis telemetry where your app knows the final result. Collect only the fields you need, then verify a test event before building charts.
- 1
Choose the outcome
Redis cache reliability
- 2
Define the contract
operation, cache_name, status, hit, and fallback_used
- 3
Log the final result
Wrap the application operation you need to measure; do not monkey-patch the Redis client or emit every command by default.
- 4
Check the stored event
Exercise a known fixture, then inspect cache_operation_completed for one correctly typed terminal row.
Before you start
Before you start
- node-redis and telemetry-sh initialized once in a trusted Node.js process
- A fixed list of operation names that excludes raw keys and command arguments
- Separate policies for command failures, connection events, and telemetry delivery failures
Delivery setup
Install and initialize server-side
Import telemetry-sh in server-only code and initialize it once with process.env.TELEMETRY_API_KEY. Keep ingestion credentials out of browser bundles, client-visible environment variables, source control, logs, and exception messages.
npm installation
npm install telemetry-sh- 1Create one reusable server-side client. Set its timeout and retry limit.
- 2Log an event when the operation succeeds, fails, retries, or times out.
- 3Send test events with known results and inspect the stored rows before enabling an alert.
Snippet
Start with one structured event
Add this shape where the workflow completes, fails, or retries. Then build the dashboard from real fields.
Redis and node-redis telemetry event
async function readCachedProject(projectId) {
const startedAt = performance.now();
let status = "success";
let errorType;
try {
const value = await redis.get(`project:${projectId}`);
await telemetry.log("cache_operation_completed", {
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 = classifyRedisError(error);
await telemetry.log("cache_operation_completed", {
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;
}
}Event schema
operation, cache_name, status, hit, and fallback_used
latency_ms, error_type, reconnecting, release, and environment
key_namespace only when it is a fixed category rather than a customer-derived key
Check your setup
Checkpoint 1
Wrap the application operation you need to measure; do not monkey-patch the Redis client or emit every command by default.
Checkpoint 2
Never send Redis URLs, credentials, raw keys, values, command arguments, channel messages, or Lua source.
Checkpoint 3
Keep the Redis error listener required by node-redis, but rate-limit connection telemetry so a reconnect storm cannot create a second overload.
Verification
Prove the event arrived
Run this after exercising known success and failure cases. Replace the fallback table name if your final event contract differs from the snippet.
Redis and node-redis telemetry verification query
SELECT *
FROM cache_operation_completed
ORDER BY timestamp_utc DESC
LIMIT 20;Implementation references
Review the event contract, data-safety guidance, and upstream primary documentation before enabling a new production path.
Where to log
Keep the outcome event small and recoverable
This pattern provides
- Record the outcome as an event you can query with SQL.
- Stable fields for dashboards, alerts, and cross-event correlation.
- Test events for checking success, failure, retries, and timeouts.
This pattern does not provide
- An OTLP exporter, automatic collection pipeline, or replacement for detailed traces and diagnostic logs.
- Exactly-once delivery merely because the payload contains an event ID.
- Permission to collect raw provider payloads, user content, credentials, or regulated data.
Example event schemas
Event schemas for this workflow
Check what each event records, when to send it, and which field types it needs. Review the example payload and privacy checklist before using it in production.
Use these queries in Telemetry
Learn about Alerts
Add a threshold and recipients to your reliability query to get alerts.
Related SQL recipes
More SQL recipes
Run the query using this workflow's event fields and check the example result. Save the result to a dashboard or set up an alert.
Find cache misses and stampede risk
Which cache-key patterns combine a poor hit rate with concurrent backend work?
Open recipeCompare dependency p95 latency
Which downstream dependencies have the worst tail latency and failure rate?
Open recipeDetect error-rate spikes with a rolling baseline
Which hourly error-rate buckets are far above their recent baseline?
Open recipeCalculate incident detection and recovery time
How long does each service take to detect and recover from incidents?
Open recipeMeasure Telemetry volume by event name
Which event contracts create the most ingestion volume?
Open recipeBrowse by implementation family
Compare related integration patterns
Templates to pair with this integration
API error and latency monitor
Watch request volume, status codes, route latency, failed endpoints, and customer-impacting API incidents.
Open templateEvent tracking plan template
Document what each event means, who owns it, which fields it contains, and which queries depend on it. Include privacy, retention, and validation rules.
Open templateMore integrations
OpenTelemetry context in structured events
Connect Telemetry business events to existing OpenTelemetry traces by recording safe trace and span identifiers at workflow boundaries.
Open guideGitHub Actions workflow telemetry integration
When a GitHub Actions workflow finishes, send its run, attempt, job, conclusion, duration, and release fields.
Open guideKafka consumer lag and processing analytics
Monitor Kafka consumer outcomes, partition lag, processing latency, retries, and poison-message handling with structured events.
Open guide