Redis observability with Grafana, Mimir, Loki, Tempo, and Alloy

The main metrics path is Redis -> Alloy -> Mimir -> Grafana.

This stack runs one authenticated Redis container with append-only persistence enabled. Grafana reads Redis and node metrics from Mimir, so throughput, client pressure, memory, keyspace growth, latency, persistence, and host resources can be investigated from the same UI as logs and application traces.

Alloy runs one embedded Redis exporter component, connects it to redis:6379 with the configured password, labels the instance and member as redis, and remote-writes the samples to Mimir. In the same process, Alloy collects node metrics, forwards Docker logs to Loki, accepts OTLP telemetry, and sends application traces to Tempo.

count by(__name__) ({__name__=~"redis_.+"})

The Redis dashboard is organized around operational questions: whether the instance is reachable, which commands dominate its workload, whether clients are blocked or rejected, how memory and keyspace behave, which commands are slow, whether persistence is healthy, what Redis logs report, and whether the host has enough resources.

The dashboard uses stat, gauge, table, bar chart, pie chart, heatmap, logs, and time-series visualizations instead of forcing every metric into a line chart. Its standalone rendering replaces replica-only panels with a clear topology note rather than empty or fabricated replication data.

Alloy reads Docker container logs, adds project, service, container, and container_id labels, and forwards the streams to Loki. The dashboard uses those labels for Redis log views covering slow operations, latency, authentication, warnings, errors, and persistence activity.

For OTLP traffic, Alloy exposes gRPC on 4317 and HTTP on 4318. OTLP logs are converted for Loki, OTLP metrics are converted to Prometheus remote write for Mimir, and OTLP traces are batched and sent to Tempo. Tempo is reserved for application traces; the Redis dashboard does not depend on traces.