> 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)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.qpoint.io/release-notes/redis-protocol-support.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.