zeekay
6994cf05aa
We do not use Redis. The client was a go-redis fork and still said so
everywhere: `package redis`, `redis.NewClient`, `redis://`, `extra/redisotel`.
Consumers wrote `redis.Client` against a Valkey-backed store called KV.
package redis -> package kv (93 decls)
redis.X -> kv.X (2,794 call sites)
"redis: …" errors -> "kv: …" (206)
extra/redis{otel,cmd,prometheus,census} -> extra/kv{otel,cmd,prometheus,census}
redis:// , rediss:// -> kv:// , kvs:// (ParseURL)
Redis*/*Redis* idents -> KV*/*KV*
REDIS_VERSION, REDIS_ENDPOINTS_CONFIG_PATH -> KV_*
I previously argued this rename was unsafe because much of it was "wire
contract". That was wrong, and the categorisation shows why: RESP command names
are GET/SET/HSET — they never contain the word. Of 5,771 occurrences only two
kinds were server-visible at all: the ParseURL scheme (we choose what we pass;
our configs already use kv://) and the CLIENT SETINFO lib-name label, which the
server merely records. Nothing here changes a byte of protocol.
Two things deliberately keep the old spelling:
RediSearch — names a specific external module the FT.* commands map to.
StoreDist — contains the letters by accident (sto-reDis-t), not the word.
Breaking for consumers by design: every import site must move redis.X -> kv.X.
Minor bump, never a major — this module stays v9 forever.
3.0 KiB
go-kv OpenTelemetry Monitoring with Uptrace
This example demonstrates how to instrument and monitor KV operations in Go applications using OpenTelemetry and Uptrace, providing comprehensive observability into your KV performance and operations.
Overview
This integration provides:
- Distributed tracing for KV operations
- Performance monitoring with latency and throughput metrics
- Error tracking and debugging capabilities
- Visual dashboards for KV health monitoring
- Production-ready observability stack with Docker
Prerequisites
- Go 1.19+
- Docker and Docker Compose
- Basic understanding of KV and OpenTelemetry
Quick Start
1. Clone and Navigate
git clone https://github.com/kv/go-kv.git
cd example/otel
2. Start the Monitoring Stack
Launch KV and Uptrace services:
docker compose up -d
This starts:
- KV server on
localhost:6379 - Uptrace APM on
http://localhost:14318
3. Verify Services
Check that Uptrace is running properly:
docker compose logs uptrace
Look for successful startup messages without errors.
4. Run the Example
Execute the instrumented KV client:
go run client.go
You should see output similar to:
trace: http://localhost:14318/traces/ee029d8782242c8ed38b16d961093b35
Click the trace URL to view detailed operation traces in Uptrace.
5. Explore the Dashboard
Open the Uptrace UI at http://localhost:14318 to explore:
- Traces: Individual KV operation details
- Metrics: Performance statistics and trends
- Logs: Application and system logs
- Service Map: Visual representation of dependencies
Advanced Monitoring Setup
KV Performance Metrics
For production environments, enable comprehensive KV monitoring by installing the OpenTelemetry Collector:
The OpenTelemetry Collector acts as a telemetry agent that:
- Pulls performance metrics directly from KV
- Collects system-level statistics
- Forwards data to Uptrace via OTLP protocol
When configured, Uptrace automatically generates a KV dashboard:
Key Metrics Monitored
- Connection Statistics: Active connections, connection pool utilization
- Command Performance: Operation latency, throughput, error rates
- Memory Usage: Memory consumption, key distribution
- Replication Health: Master-slave sync status and lag
Logs and Debugging
View service logs:
# All services
docker compose logs
# Specific service
docker compose logs kv
docker compose logs uptrace