Redis

Synopsis

Creates a Pub/Sub subscriber that connects to Redis servers and processes messages from specified channels. Supports authentication, TLS encryption, and multiple workers with automatic message handling.

Schema

- id: <numeric>
  name: <string>
  description: <string>
  type: redis
  tags: <string[]>
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    address: <string>
    port: <numeric>
    username: <string>
    password: <string>
    channel: <string>
    reuse: <boolean>
    workers: <numeric>
    tls:
      status: <boolean>
      cert_name: <string>
      key_name: <string>
      passphrase: <string>
      ca_name: <string>
      server_name: <string>
      min_tls_version: <string>
      max_tls_version: <string>
      insecure_skip_verify: <boolean>

Configuration

The following fields are used to define the device:

Device

Field	Required	Default	Description
id	Y	-	Unique numeric identifier
name	Y	-	Device name
description	N	-	Optional description
type	Y	-	Must be redis
tags	N	-	Optional tags
pipelines	N	-	Optional pre-processor pipelines
status	N	true	Enable/disable the device

Connection

Field	Required	Default	Description
address	N	"0.0.0.0"	Redis server address
port	Y	-	Redis server port
username	N	-	Authentication username
password	N	-	Authentication password
channel	Y	-	Channel pattern to subscribe to (supports * wildcard, e.g. logs.*)

TLS

Field	Required	Default	Description
tls.status	N	false	Enable TLS encryption
tls.cert_name	Y*	cert.pem	Client certificate for mutual TLS
tls.key_name	Y*	key.pem	Client private key for mutual TLS
tls.passphrase	N	-	Passphrase for an encrypted private key
tls.ca_name	N	-	CA bundle used to verify the server certificate. When unset, the host trust store is used.
tls.server_name	N	-	SNI hostname override for the TLS handshake
tls.min_tls_version	N	tls1.2	Minimum accepted TLS version (tls1.0, tls1.1, tls1.2, tls1.3)
tls.max_tls_version	N	-	Maximum accepted TLS version. When unset, the highest mutually supported version is negotiated.
tls.insecure_skip_verify	N	false	Skip server certificate verification. Use only for testing.

* = Required when tls.status is true.

note

TLS material fields (cert_name, key_name, ca_name, client_ca_name) accept any of the following:

• File name — resolved relative to the service root directory. Nested paths such as certs/prod/server.pem are supported.
• Absolute path — honored only if it resolves inside the service root. Any path that escapes the root is refused.
• Inline PEM content — used verbatim when the value contains -----BEGIN.
• Environment variable — ${ENV_VAR}.
• Vault reference — $secret{id=...} or $secret{store=...,ref=...}.

Performance

Field	Required	Default	Description
reuse	N	false	Enable multi-worker mode
workers	N	4	Number of worker processes when reuse enabled (capped at the number of available CPU cores)

Examples

Basic

Creating a simple Redis Pub/Sub subscriber on a single channel...

- id: 1 name: basic_redis type: redis properties: address: "redis.example.com" port: 6379 channel: "logs"

Secure

Connecting with authentication and TLS encryption...

- id: 2 name: secure_redis type: redis properties: address: "redis.example.com" port: 6379 username: "subscriber" password: "secret" channel: "secure.logs" tls: status: true cert_name: "redis.crt" key_name: "redis.key"

High-Volume

Multi-worker mode for high-throughput consumption...

- id: 3 name: performant_redis type: redis properties: address: "redis.example.com" port: 6379 channel: "high-volume" reuse: true workers: 4

Pattern Subscription

Pattern-based subscription using a wildcard channel...

- id: 4 name: pattern_redis type: redis properties: address: "redis.example.com" port: 6379 channel: "logs.*" reuse: true workers: 2

tip

Redis channel patterns support the * wildcard character for matching multiple channels.

Pipelines

Applying custom processing to messages...

- id: 5 name: pipeline_redis type: redis pipelines: - json_parser - field_extractor properties: address: "redis.example.com" port: 6379 channel: "raw.logs"

note

Pipelines are processed sequentially, and can modify or drop messages before ingestion.