Getting Data In

How To Collect Event Viewer Logs On Deployment Servers?

Gregski11
Contributor

so we have a rather complicated Splunk environment with an Index Cluster and about half a dozen search heads, and all that is fine and good, however I want to collect the Application logs from the Windows Event viewer on our two Splunk Deployment servers and I want that data to go into the central EventLog Index, however I do not see that as a choice in the pulldown on our two Deployment Servers like I do on our Search Head servers, and I forgot how to set that up

we use Microsoft Windows 2019 to run all of our Splunks and I like to use the Web UI for as much as possible, though I aint afraid to touch the config text files, you know what I'm sayin'

So in the Web UI on the Deployment servers I find this under Settings \ Data Inputs \ Local Event Log Collection and here I can select the Application, Security, and or System Event Logs just fine, however down below under the Index (Set the destination index for this source) section I only see the 15 local Indexes for that server and not those on our Index Cluster

so is it wise to point the Deployment servers at our Index Cluster, and if so how do I accomplish this, or is there a better way to gather the Application log off the Deployment servers

Labels (1)
0 Karma

PickleRick
SplunkTrust
SplunkTrust

Well, that's because gui is... well, it's good for some entry-level administration and generally, mostly for all-in-one setups.

When you're creating an input, server presents you with list of indexes that the server knows and these are the indexes defined in indexes.conf. That's why you want that file to be distributed across your environment so SHs know what to hint in the search window and HFs (in your context a DS is essentially a HF in this case) can present a list of destination indexes to choose from.

And that's one of the reasons why gui administration is not enough in a more complicated setup.

gcusello
SplunkTrust
SplunkTrust

Hi @Gregski11 ,

I don't know your infrastructure, but a Windows DS can be used without issues if you have to manage only Windows servers, if you want to manage Linux servers, using a Windows DS you lose the grants configurations so you cannot use scripts inputs.

Anyway, all the Splunk servers should directly send their logs to the Indexers (also DS) and you can do this by GUI in [Settings > Forwarding and Receiving > Forwarding], setting up the destination Indexers.

If you are using to deploy an outputs.conf to your managed servers, you can use it (uploading) without making a manual configuration (I prefer this solution, than manually manage!).

You don't need to access conf files if you send clear text logs, if you are using a certificate (even if Splunk auto generated)), you need to manually modify a conf file.

About how to configure inputs, I don't like to use the Settings > Inputs feature, because you need to manually manage it, it's better to use the same Splunk_TA_Windows that you deployed to the Windows Servers, and you can manually upload it, without accessing the CMD environment.

Ciao.

Giuseppe

0 Karma

richgalloway
SplunkTrust
SplunkTrust

The Deployment Servers should be connected to the indexers already so they can index their logs. 

To tell the DSs what indexes are available, install the same indexes.conf file (in an app) that you put on the search heads.  That should let you select the desired destination index from the UI.  If that doesn't work, just edit inputs.conf (in an app).

---
If this reply helps you, Karma would be appreciated.
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...