Good morning everyone,
I have a question. We have Enterprise apps like Microsoft Exchange and we would like specific application log data on it.
Now as i understand you have two options:
1) change your input.cfg on every machine (functionality specific, DC, Exchange, etc..)
2) Use a SPLUNK app.
With 1500 servers it's not manageble to have different input.conf for each functionality (number of servers, 12 exchange servers, 3 McAfee servers, 16 domain controllers etc..).
So my question is does a SPLUNK app solve my problem here. Can this be central managed from the SPLUNk application instead of changing a config file?
Kind regards,
André
Hi aborgeld,
Deployment Server is the solution you require:
using a DS you can centrally manage all you servers, in other words, as you require, you can modify only one configuration and it's deployed to all your perimeter.
In addition, I suggest to use as you can the standard apps (especially TAs) to ingest logs but also to create custom TAs for all you needs: I usually create a specialized TA for each environment to monitor (e.g. Windows Servers, SQL-Server, Domain Controllers, Linux Servers, etc...).
I have many Splunk installations with thousands of monitored servers, the only way to perform this is an heavy organization of the requirements and the following configurations, in other words each new input or modification of an old one must be planned, verified and registered before implementing.
I don't understand why you say "With 1500 servers it's not manageble to have different input.conf for each functionality", I usually have situations like you and i manage them with many TAs (one for each functionality), Deployment Server and organization.
I hope to be useful for you.
Bye.
Giuseppe
Hi aborgeld,
Deployment Server is the solution you require:
using a DS you can centrally manage all you servers, in other words, as you require, you can modify only one configuration and it's deployed to all your perimeter.
In addition, I suggest to use as you can the standard apps (especially TAs) to ingest logs but also to create custom TAs for all you needs: I usually create a specialized TA for each environment to monitor (e.g. Windows Servers, SQL-Server, Domain Controllers, Linux Servers, etc...).
I have many Splunk installations with thousands of monitored servers, the only way to perform this is an heavy organization of the requirements and the following configurations, in other words each new input or modification of an old one must be planned, verified and registered before implementing.
I don't understand why you say "With 1500 servers it's not manageble to have different input.conf for each functionality", I usually have situations like you and i manage them with many TAs (one for each functionality), Deployment Server and organization.
I hope to be useful for you.
Bye.
Giuseppe
Hi Cusello,
Thanks for your answer
Two questions
1)
With this solution (deployment server) can i minimize (scope) what i want to see from a security log so i don't get everything?
2)
Is it true that if i do that in an input.conf on a server that i get everyting of a specific log (for example a security log)?
Your right with your solution it is manageble. I meant with our solution (doing things with an input file) on specific servers it's not manageble.
Kind regards,
André
Deployment Server permits to you to deploy specific TAs to the servers in a defined ServerClass, in other words you have a table that defines which TAs must be deployed to which Servers.
The logs to ingest are managed in inputs.conf file, so you have to work to exactly define the logs in scope and than create your inputs.conf stanzas to take only the logs you need, not others.
Beware to duplication stanzas because in Splunk a log file is read only one time, so if you want to read a file and put logs in different indexes or assigning different sourcetypes, you'll have only one of them!
In addition, you can also filter logs on indexers http://docs.splunk.com/Documentation/Splunk/latest/Forwarding/Routeandfilterdatad
One additional suggest: manage also outputs.conf using Deployment Server and one or more TAs.
Bye.
Giuseppe
Thanks Giuseppe. We are going to implement it like the way you said!