> For the complete documentation index, see [llms.txt](https://docs.qpoint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qpoint.io/release-notes/redis-protocol-support.md).

# Redis Protocol Support

**What if you could see inside your Redis traffic?**

Qtap now captures Redis protocol traffic with full command visibility, enabling security and observability for Redis-based applications. No instrumentation. See every command, argument, response, and timing - with process attribution so you know exactly which service is accessing your cache.

**Released:** Feb 10, 2025

<figure><img src="/files/xfIlrFrF0CSJMK7sbdZw" alt=""><figcaption></figcaption></figure>

{% hint style="success" %}
**Available Now**: Redis protocol support is included in the latest qtap release. Add a `redis` section to your tap configuration to start capturing.
{% endhint %}

***

## The Problem We Solved

Redis is everywhere - caching, sessions, queues, real-time data. But visibility into Redis traffic has been a blind spot:

* **What data is being stored?** Could be PII, credentials, or sensitive business data
* **Which service is accessing the cache?** Multiple containers hitting the same Redis instance
* **Why is Redis slow?** Need per-command latency to identify hot keys or expensive operations
* **Security auditing?** No visibility into what's actually being read/written

Qtap now gives you the same deep visibility for Redis that you've had for HTTP/S.

***

## What It Captures

### Commands & Arguments

Every Redis command with full arguments:

```json
{
  "command": "HSET",
  "args": ["user:1", "name", "John Doe", "email", "john@example.com"]
}
```

See exactly what keys are being accessed and what values are being stored.

### Responses

Full response data including type and value:

```json
{
  "response_type": "integer",
  "response_value": "1"
}
```

**Supported response types:**

| Type            | Description        | Example                         |
| --------------- | ------------------ | ------------------------------- |
| `simple_string` | Status responses   | `OK`, `PONG`                    |
| `bulk_string`   | String values      | Retrieved data                  |
| `integer`       | Numeric responses  | Increment results, list lengths |
| `array`         | Multi-bulk replies | `HGETALL`, `LRANGE` results     |
| `error`         | Error messages     | Full error text                 |

### Latency

Per-command timing with microsecond precision:

```json
{
  "latency": "100.129µs"
}
```

Track command performance, identify slow operations, and catch latency spikes.

### Process Attribution

Every Redis operation is linked to the source:

* Executable path (`/usr/local/bin/python3.11`)
* Container name and image
* Process ID

Know exactly which service made each Redis call.

***

## Configuration

Add a `redis` section to your tap configuration alongside your HTTP capture:

```yaml
version: 2

services:
  event_stores:
    - type: stdout
  object_stores:
    - type: stdout

stacks:
  default_stack:
    plugins:
      - type: http_capture
        config:
          level: summary
          format: json

tap:
  direction: all
  http:
    stack: default_stack
  redis:
    stack: default_stack
```

Redis traffic flows through the same stack and storage configuration as HTTP.

***

## Example Output

**Human-readable format:**

```
■ redis-cli → SET testkey hello from cli OK
■ redis-server ← SET testkey hello from cli OK
```

**JSON format:**

```json
{
  "command": "HSET",
  "args": ["user:1", "name", "John Doe", "email", "john@example.com"],
  "response_type": "integer",
  "response_value": "1",
  "latency": "100.129µs",
  "process": {
    "exe": "/usr/local/bin/python3.11",
    "container": "user-service"
  }
}
```

***

## Use Cases

### Sensitive Data Detection

**Problem:** Is PII being stored in Redis? Credentials? API keys?

**Solution:** Capture Redis traffic and scan for sensitive patterns. Discover that your session store contains unencrypted SSNs, or that API keys are being cached without expiration.

### Performance Monitoring

**Problem:** Redis is slow but you don't know which commands or keys are the problem.

**Solution:** Per-command latency reveals hot keys, expensive `KEYS *` operations, or commands that should be pipelined.

### Security Auditing

**Problem:** Compliance requires knowing what data flows to your cache layer.

**Solution:** Full visibility into every read and write operation, with process attribution showing which services access which keys.

### Debugging

**Problem:** Application behavior is inconsistent - might be a caching issue.

**Solution:** Correlate Redis operations with application requests. See exactly what's being cached, when, and by whom.

***

## What's Next

Redis support uses the same stack and plugin architecture as HTTP. Future releases will add:

* Redis-specific capture rules (filter by command, key pattern)
* PII detection in Redis values via qscan
* Redis traffic in DevTools UI

***

## Feedback

We'd love to hear how you're using Redis protocol support! Share your use cases, feature requests, or bug reports:

* **GitHub Issues**: [qpoint-io/qtap](https://github.com/qpoint-io/qtap/issues)