Can a "redundancy" forwarder be triggered to send logs if the primary forwarder is down?

[dineshp]

Hi,
Is it possible to configure the indexer to index logs from one forwarder only (say forwarder 1) and if logs from "forwarder 1" stops, start indexing logs from "forwarder 2"

At the moment, we have two universal forwarders (for redundancy purpose) sending same data to one indexer. So we are consuming twice as much the licence. Is there a way to remove duplicate logs before it gets indexed / or listen to one forwarder at a time.

Many Thanks

[ddrillic]

Interesting perspective from @maciep at Is there a way to configure high availability for Splunk Forwarders, so if one is down, another will...

He said -

-- Before my time here we had something kind of similar in active/inactive state. It was actually two syslog servers. Both servers would get the same data in the same folders/files but only one would have the forwarder running at any given time. The trick though was to put the fishbucket on a mount point and then symlink it on both servers from the normal fishbucket location.

So the failover scenario was still manual - meaning we had to start up splunk on the backup server. But when it started, it was using the same fishbucket as primary so it knew where to start reading files from.

I'm not sure how good of a solution that was but it could be an option for you. As long as the forwarders are reading from the same place and share a fishbucket, I guess it would work?

In general though, we don't worry much about HA for forwarders. We have monitoring in place to start splunk if it stops and we get a daily report (from the Deployment Monitor app) of forwarders that haven't checked in to our deployment server. So typically we can address stopped forwarders before the data rolls.

Hope that helps a little

[s2_splunk]

No, and you shouldn't need to be doing this. First of all, your two forwarder instances know nothing about each other wrt where they are in the forwarding process (they have separate _fishbucket indices), so you will have no assurances about data accuracy/completeness.
Forwarders typically don't just quit, so why don't you put a process in place that monitors the forwarder process on the host system and restarts it if it goes down?