Hello,
I'm currently trying to update our Splunk environment, but one problem I'm having is getting our server classes named correctly to make them future-proof and easy to use.
Currently my server class naming convention looks something like this:
<name> (general serverclass)
<name>_<location>(location based)
<name>_<machine type> (machine type based)
<name>_<machine type>_<location> (location and machine type based)
Example:
clients
clients_munich
clients_berlin
clients_linux
clients_linux_munich
clients_linux_berlin
clients_windows
clients_windows_munich
clients_windows_berlin
I would also use this convention for all other "groups" that need server classes.
Server, Services, Appliances, Network, ...
If you need examples for them just ask me 😄
Hi @yaye,
as @ITWhisperer hinted, the first thing id define (on paper) what each serverclass has to do.
In other words if the clients of Munich and paris must have the same apps you don't need to have two serverclasses.
So at first identify what each serverclass have to do in terms of apps to deploy, avoiding unuseful serverclasses that deploy exactly the same apps.
You could do this also defining a logic to use, and you can follow two approaches:
I prefer the second one:
for example, I create a serverclass to deploy the TA_Forwarders that contains outputs.conf and deploymentserver.conf and I created one serverclass for each group of targets that points to the same destination, on other words, one for the targets that point to one heavy Forwarder in a closed subnet, another for the targets that directly points to indexers and so on.
Then I created a serverclass for targets that need one or more special apps (e.g. syslog inputs or SAP, etc...)
In this way I can reduce the serverclasses and each target can be in more than one serverclasses.
Choose the logic you like!
then you can define a naming convention related to the logic you choosed: geografic, applications, ect...
Ciao.
Giuseppe
Hi @yaye,
as @ITWhisperer hinted, the first thing id define (on paper) what each serverclass has to do.
In other words if the clients of Munich and paris must have the same apps you don't need to have two serverclasses.
So at first identify what each serverclass have to do in terms of apps to deploy, avoiding unuseful serverclasses that deploy exactly the same apps.
You could do this also defining a logic to use, and you can follow two approaches:
I prefer the second one:
for example, I create a serverclass to deploy the TA_Forwarders that contains outputs.conf and deploymentserver.conf and I created one serverclass for each group of targets that points to the same destination, on other words, one for the targets that point to one heavy Forwarder in a closed subnet, another for the targets that directly points to indexers and so on.
Then I created a serverclass for targets that need one or more special apps (e.g. syslog inputs or SAP, etc...)
In this way I can reduce the serverclasses and each target can be in more than one serverclasses.
Choose the logic you like!
then you can define a naming convention related to the logic you choosed: geografic, applications, ect...
Ciao.
Giuseppe
Hi @yaye ,
good for you, see next time!
Ciao and happy splunking
Giuseppe
P.S.: Karma Points are appreciated by all the contributors 😉
How are you expecting to use the serverclass? How are you expecting it to change? What is important to you about the serverclass?
Whatever you choose, the important thing is probably picking one convention and sticking to it!