Tair (Redis® OSS-Compatible):Latency insights

How it works

Redis 2.8.13 introduced built-in latency monitoring. It covers a limited set of events, retains data for only 160 seconds, and stores just one record per second (the highest-latency event).

Latency insights extends this with:

• Persistence — data is stored for three days and latency spikes are traceable across that window

• High precision — full events are monitored within milliseconds

• Low overhead — implemented asynchronously with minimal impact on instance performance

• Real-time queries — data is available for immediate query and aggregation

• Multiple analysis dimensions — slice data by event type, time range, or latency value

Only commands and events that exceed a defined threshold are recorded. Thresholds vary by event type (30 ms, 50 ms, or 100 ms). See Appendix: Common special events for the full list.

Prerequisites

Before you begin, ensure that:

• The instance minor version meets the minimum requirement for your edition: For instructions on updating a minor version, see Update the minor version of an instance.

  Edition	Minimum minor version	Notes
  Tair (Enterprise Edition) memory-optimized	1.6.9	For Tair module command statistics, use 1.7.28 or later
  Redis Open-Source Edition 5.0	5.1.4
  Redis Open-Source Edition 6.0	0.1.15
  Redis Open-Source Edition 7.0	7.0.0.6

View latency statistics

1. Log on to the console and go to the Instances page. In the top navigation bar, select the region where your instance is deployed. Find the instance and click its ID.

2. In the left navigation pane, click CloudDBA > Latency Insights.

3. On the Latency Insights page, select a time range and click Search. The default view shows statistics from the last 5 minutes. Queries can span up to three days of data, but a single query cannot cover more than one hour. For cluster and read/write splitting instances, use the Data Node and Proxy Node tabs to view statistics separately by node type.

4. Click an event name or a count in the list to open its latency trend chart. In the chart, select additional metrics to overlay their trends.

   

   Only commands and events that exceed their configured threshold are recorded. If you see high-latency events, see Suggestions for handling common latency events for remediation guidance.

Metrics reference

The Latency Insights table displays the following columns:

Metric	Description
Event	The event name. Examples: ExpireCycle, EventLoop, Ping, Scan, Commands, Info. See Appendix: Common special events.
Total	Total number of recorded occurrences.
Average Latency (us)	Mean latency across all recorded occurrences, in microseconds.
Maximum Latency (us)	Highest latency observed, in microseconds.
Aggregated count (< 1 ms)	Count of events with latency below 1 ms. Click the icon to expand into sub-ranges: \<1 us, \<2 us, \<4 us, \<8 us, \<16 us, \<32 us, \<64 us, \<128 us, \<256 us, \<512 us, \<1 ms.
\<2 ms, \<4 ms, ..., >33s	Count of events in each latency range.

Counting rules: Each range is exclusive at the lower bound and inclusive at the upper bound. For example, \<2 us counts events with latency between 1 us and 2 us. \<2 ms counts events with latency between 1 ms and 2 ms. >33s counts events with latency above 33 seconds.

What's next

• Suggestions for handling common latency events — remediation steps for each event type

• Update the minor version of an instance — update the instance to meet version requirements

Appendix: Common special events

Events are grouped by the Redis subsystem they relate to. The threshold column shows the minimum latency that triggers recording.