# Logstash config file and Redis
**URL:** https://discuss.elastic.co/t/logstash-config-file-and-redis/47530
**Category:** Logstash
**Created:** [April 15, 2016, 6:22pm UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530 "2016-04-15T18:22:42Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@lhorsky1](https://discuss.elastic.co/u/lhorsky1)
#### Post date: [April 15, 2016, 6:22pm UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/1 "2016-04-15T18:22:42Z")
Previously, we have been running 6 different logstash processes on each Logstash server (5 shippers and 1 indexer) and 1 Redis process. The shippers each had their own configuration file, listening for data incoming on specific ports, and the output section was configured to send to one of two Redis servers (for load balancing and failover protection). The indexer process then had an input of Redis and output to Elasticsearch.
With ES 2.x, we decided to standardize and use a single logstash.conf file and therefore a single logstash process + 1 Redis process. Which should make things easier to manage, handle, and monitor. But I can't find any examples of using Redis in the middle like this.
But how do I specify multiple options for the output section. Specifically, what values can I key off of to specify that the shippers (syslog, snmptraps, beats, logs, etc) all ship their data to Redis first. Then only redis output gets sent to Elasticsearch.
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [April 16, 2016, 8:21pm UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/2 "2016-04-16T20:21:58Z")
You should use two instances, one for incoming events into redis, one for outgoing into ES.
But what you want is conditionals - [https://www.elastic.co/guide/en/logstash/current/event-dependent-configuration.html#conditionals](https://www.elastic.co/guide/en/logstash/current/event-dependent-configuration.html#conditionals)
---
### Author:  [@lhorsky1](https://discuss.elastic.co/u/lhorsky1)
#### Post date: [April 18, 2016, 1:15pm UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/3 "2016-04-18T13:15:23Z")
So just to confirm. The standard process, if you are using Redis, would be to have a shipper config that has the inputs for all incoming streams, appropriate filters, and an output to Redis. Along with a separate indexer config that has an input of Redis with an output of Elasticsearch.
Thanks!
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [April 18, 2016, 8:40pm UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/4 "2016-04-18T20:40:47Z")
No, the other way.
Input and then output to redis, and then input, filters and output to ES.
---
### Author:  [@lhorsky1](https://discuss.elastic.co/u/lhorsky1)
#### Post date: [April 19, 2016, 1:52am UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/5 "2016-04-19T01:52:07Z")
So, the shipper config shouldn't have any filters and the data should just be passed to Redis. Then the indexer config takes care of the filters and sending the data to Elasticsearch?
Wouldn't that put events that should be dropped through Redis unnecessarily? What are the benefits of putting the filters in the indexer config?
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [April 19, 2016, 2:59am UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/6 "2016-04-19T02:59:55Z")
> [@lhorsky1](#):
>
> So, the shipper config shouldn't have any filters and the data should just be passed to Redis. Then the indexer config takes care of the filters and sending the data to Elasticsearch?
Yep 🙂
> [@lhorsky1](#):
>
> Wouldn't that put events that should be dropped through Redis unnecessarily? What are the benefits of putting the filters in the indexer config?
You get the events into your broker layer ASAP. If you have filters on the incoming part you may end up slowing things upstream down. Where as putting it after means they just queue if your existing instances are busy, and it allows you to easily scale (it's harder to scale inbound).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 5:01am UTC](https://discuss.elastic.co/t/logstash-config-file-and-redis/47530/7 "2017-07-06T05:01:43Z")