RedisTimeSeries: Storing Metrics and Monitoring Data Efficiently

1. Why Time Series Data Needs Its Own Data Model

Metrics such as requests per second or response times differ fundamentally from classic Redis use cases: the point is not the current value of a single key, but a continuous sequence of timestamp-value pairs that grows over hours, days, or months. Without a specialized data model, every single measurement would have to be stored as its own sorted set entry or its own key, which quickly leads to millions of entries at high measurement frequency.

RedisTimeSeries solves this by introducing its own data type for time series that is internally optimized for sequential timestamps and offers functions like downsampling, retention, and aggregation directly in the server, without the application having to implement this logic itself.

2. The Data Model: TS.CREATE and TS.ADD

A time series is created with TS.CREATE and can optionally be given labels, which later enable queries across multiple time series, similar to labels in Prometheus. New data points are added via TS.ADD with a timestamp and a value, where the timestamp can either be specified explicitly or automatically set to the current server time using the asterisk placeholder.

For high-frequency metrics, such as requests per second from multiple application servers, TS.MADD is recommended, which writes multiple data points across different time series in a single command and thereby avoids the overhead of many individual network round trips.

redis-cli TS.CREATE metric:requests:webserver1 LABELS service webserver1 type requests

redis-cli TS.ADD metric:requests:webserver1 '*' 142

redis-cli TS.MADD metric:requests:webserver1 '*' 150 metric:requests:webserver2 '*' 98

3. Downsampling Rules: Maintaining Aggregated Time Series Automatically

Raw data at second-level resolution is important for real-time dashboards, but unnecessarily detailed and memory-intensive for long-term analysis spanning months. RedisTimeSeries solves this with downsampling rules through TS.CREATERULE: a source time series is linked to a destination time series that automatically receives aggregated values over a larger time window, such as a per-minute average or an hourly maximum.

These rules run server side and fully automatically: as soon as a new value is written to the source time series, Redis updates the linked, aggregated destination series in the background. The application neither has to run its own cron job for aggregation nor iterate over historical raw data afterward.

redis-cli TS.CREATE metric:requests:1min AGGREGATION avg 60000

redis-cli TS.CREATERULE metric:requests:webserver1 metric:requests:1min AGGREGATION avg 60000

4. Retention Policies: Discarding Old Raw Data Automatically

Without a cleanup mechanism, raw data at second-level resolution would grow indefinitely and eventually exhaust available memory. RedisTimeSeries solves this through the RETENTION option on TS.CREATE, which specifies how long data points are kept in milliseconds before they are automatically removed from the time series.

In practice, teams combine a short retention window for high-resolution raw data with a long or unlimited retention window for the downsampled destination series: second-level values are kept for only a few hours, minute-level aggregates for several weeks, and hourly aggregates potentially indefinitely. This keeps memory usage under control without having to give up historical trends.

redis-cli TS.CREATE metric:requests:webserver1 RETENTION 21600000 LABELS service webserver1

redis-cli TS.CREATE metric:requests:1min RETENTION 5184000000 LABELS service webserver1 resolution 1min

5. Comparison to Prometheus and InfluxDB

Prometheus follows a pull model: the server periodically scrapes metrics from the monitored services and stores them in its own storage engine optimized for time series. RedisTimeSeries instead works on a push model, applications actively write values via TS.ADD, which is especially suited for event-driven metrics that do not fit into a fixed scrape interval, such as individual cart events.

InfluxDB, with its own query language and mature continuous queries, offers functionally more options for complex time series analysis and is usually the more economical choice for very large, long-term metric volumes, since it is designed for disk persistence rather than in-memory storage. RedisTimeSeries, in turn, scores with the low latency of Redis and the ability to run metrics right alongside already existing Redis data such as sessions or caches, without setting up an additional system.

6. Practical Example: Requests per Second and Cart Events

In a Magento shop, two different kinds of metrics map well to RedisTimeSeries: technical metrics such as requests per second per web server, written at regular intervals from a middleware hook, and business events such as completed cart abandonment events, which arrive irregularly but with high priority for real-time dashboards.

Both kinds of metrics benefit from automatic downsampling: requests per second are kept at second-level resolution for a live dashboard, but additionally aggregated into hourly averages for capacity planning. Cart events can be tracked as a simple counter series with TS.INCRBY, making it possible to spot trends such as a rising abandonment rate during a checkout deployment immediately.

redis-cli TS.INCRBY metric:cart:abandoned 1

redis-cli TS.RANGE metric:requests:1min - + AGGREGATION avg 3600000

7. Aggregation Queries with TS.RANGE and TS.MRANGE

For analysis, TS.RANGE offers a filtered query over a time range, optionally with its own aggregation function computed at query time, independent of the fixed downsampling rules configured on the series. TS.MRANGE extends this to multiple time series at once, filtered by labels, which is particularly practical with many individual web server instances, for example to combine all request metrics of a given service into a single query.

This flexible query layer makes it possible to use the same raw data both for granular single-server views and for aggregated service overviews, without having to create a dedicated downsampling rule for every use case. For standard aggregations that are needed permanently, fixed rules via TS.CREATERULE still make sense, because they shift the computational cost from query time to write time.

redis-cli TS.MRANGE - + FILTER service=webserver1 AGGREGATION avg 60000

8. Integration with Alerting and Monitoring Stacks

In most setups RedisTimeSeries does not replace a full monitoring stack, but it works well as a fast, already available data source for event-driven business metrics. Through a Prometheus exporter or custom query scripts, RedisTimeSeries values can periodically feed existing alerting systems without duplicating the actual metric collection.

For simple threshold alerts, a cron job that queries the last few minutes via TS.RANGE and triggers a notification when a limit is exceeded is often already enough. For more complex alerting rules with multi-stage conditions and escalation paths, however, a dedicated alerting tool like Alertmanager remains the more robust foundation.

9. Operational Limits in Production Use

The in-memory nature of Redis also applies to RedisTimeSeries: without consistent retention policies, memory usage grows uncontrollably, and a full Redis server affects not just metrics but also all other use cases, such as cache or session storage, that might share the same instance. For production setups, a dedicated RedisTimeSeries instance, separate from the cache backend, is therefore recommended.

Failure resilience also deserves a closer look: metric data is naturally less critical than session data, and a brief data loss during a failover is usually tolerable. Anyone who needs long-term, immutable historical data for compliance purposes should treat RedisTimeSeries more as a fast operational buffer and leave long-term archiving to a classic time series database or a data warehouse.

10. Summary

11. FAQ: RedisTimeSeries: The Essentials at a Glance