Getting Data In

Universal forwarder from a MS SQL cluster

grahamkenville
Engager

We have a number of MS SQL Server clusters with the Splunk Universal Forwarder installed.

We would like to index the SQL Server ERRORLOG and SQLAGENT.OUT files, which live on a disk shared by the cluster members. Only the active member of the cluster will see the shared disk where the errorlog and sqlagent.out files live. The shared disk will always have the same drive letter on whichever node is active.

In this case, I am guessing the correct thing to do is to have an identical forwarder configuration on each cluster node. Is that correct? If so, in the case of a failover, will the universal forwarder on a previously inactive node notice that it can suddenly read the errorlog and sqlagent.out files and happily start forwarding events to the indexing host? Or would a restart of the forwarder be required?

I understand we would end up with some duplicate events in this case, but we could control that by configuring the earliest indexable event to be very recent.

Comments?

Thanks!

0 Karma

dwaddle
SplunkTrust
SplunkTrust

Windows complicates this a bit (I am no Windows expert by any means) -- but I would suggest best practice is three forwarder instances.

  1. One for files JUST on server1
  2. One for files JUST on server2
  3. One for files on the shared disk

It is this #3 instance that is the important one - it needs to live on the shared disk, and be started/stopped as part of a cluster node bringing the shared resources in the cluster online.

Get Updates on the Splunk Community!

Splunk Enterprise Security 8.x: The Essential Upgrade for Threat Detection, ...

 Prepare to elevate your security operations with the powerful upgrade to Splunk Enterprise Security 8.x! This ...

Get Early Access to AI Playbook Authoring: Apply for the Alpha Private Preview ...

Passionate about security automation? Apply now to our AI Playbook Authoring Alpha private preview ...

Reduce and Transform Your Firewall Data with Splunk Data Management

Managing high-volume firewall data has always been a challenge. Noisy events and verbose traffic logs often ...