Sending Filebeat events to Redis inserts a queue or pub/sub hop between log collection and the next processing stage. That buffer helps when Logstash or another consumer slows down, restarts, or needs to scale independently from the hosts that are producing logs.
Filebeat publishes to Redis through the output.redis block in /etc/filebeat/filebeat.yml. Current Elastic docs still support Redis lists and channels: datatype: list writes events with RPUSH so consumers can drain a backlog, while datatype: channel uses PUBLISH for live pub/sub delivery without queue depth.
Only one Filebeat output can be enabled at a time, so Elasticsearch, Logstash, or other output.* blocks must stay disabled when output.redis is active. Keep Redis credentials and TLS settings aligned with the target server, and remember that a healthy Redis output still stays idle until at least one Filebeat input or module is producing new events.
$ sudo nano /etc/filebeat/filebeat.yml
Package installs normally keep the active configuration in /etc/filebeat/filebeat.yml.
#output.elasticsearch: # hosts: ["https://es.example.net:9200"] output.redis: hosts: ["redis-1.example.net:6379"] # hosts: ["rediss://redis-1.example.net:6379"] # password: "filebeat-redis-password" key: "filebeat" db: 0 datatype: list timeout: 5 # ssl.certificate_authorities: ["/etc/filebeat/certs/redis-ca.crt"]
Only one output.* block can be enabled, or Filebeat will fail to start with conflicting publisher settings.
datatype: list is the safer default when you need queue depth and retry-friendly buffering. Use datatype: channel only when a live subscriber is always present and backlog is unnecessary.
Store the Redis password in the Filebeat keystore instead of leaving it in cleartext YAML, and use either the rediss:// scheme or explicit ssl.* settings when the server requires TLS.
Related: How to add a secret to a Filebeat keystore
Related: How to configure Filebeat for TLS
$ sudo filebeat test config -c /etc/filebeat/filebeat.yml Config OK
With output.redis enabled, current Filebeat releases still return redis output doesn't support testing for filebeat test output, so the practical validation path is the service journal plus a direct Redis key check.
Related: How to test a Filebeat configuration
Related: How to test Filebeat output connectivity
$ sudo systemctl restart filebeat
$ sudo journalctl --unit=filebeat --since "5 min ago" --no-pager --lines=20
Apr 02 20:27:57 host filebeat[2147]: {"log.level":"info","@timestamp":"2026-04-02T12:27:57.962Z","log.logger":"publisher_pipeline_output","message":"Connecting to redis(tcp://127.0.0.1:6379)","service.name":"filebeat","ecs.version":"1.6.0"}
Apr 02 20:27:57 host filebeat[2147]: {"log.level":"info","@timestamp":"2026-04-02T12:27:57.964Z","log.logger":"publisher_pipeline_output","message":"Connection to redis(tcp://127.0.0.1:6379) established","service.name":"filebeat","ecs.version":"1.6.0"}
The Connection to redis(…) established message confirms that Filebeat switched to the configured Redis output.
Look for authentication failures, TLS verification errors, or repeated reconnect messages when publishing still fails after the restart.
$ redis-cli -n 0 LLEN filebeat 1
This queue-length check applies to datatype: list. A channel output has no backlog to measure, so validate that mode with a live subscriber instead of LLEN.
Add -h, -p, -a, or -u rediss://... when the Redis server is remote, authenticated, or using TLS.
If the length stays at 0, make sure at least one Filebeat input or module is enabled and generate a fresh log line before assuming the output is broken. A healthy consumer can also drain the list before you sample it.