Deployment Architecture

What is the best naming convention for serverclasses?

yaye
Explorer

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 😄

Labels (1)
0 Karma
1 Solution

gcusello
SplunkTrust
SplunkTrust

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:

  • a serverclass for each omogeneous group of targets, in this way each target is in only one serverclass,
  • create different serverclasses for different scopes.

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

View solution in original post

0 Karma

gcusello
SplunkTrust
SplunkTrust

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:

  • a serverclass for each omogeneous group of targets, in this way each target is in only one serverclass,
  • create different serverclasses for different scopes.

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

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi @yaye ,

good for you, see next time!

Ciao and happy splunking

Giuseppe

P.S.: Karma Points are appreciated by all the contributors 😉

0 Karma

ITWhisperer
SplunkTrust
SplunkTrust

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!

0 Karma
Get Updates on the Splunk Community!

Fastest way to demo Observability

I’ve been having a lot of fun learning about Kubernetes and Observability. I set myself an interesting ...

September Community Champions: A Shoutout to Our Contributors!

As we close the books on another fantastic month, we want to take a moment to celebrate the people who are the ...

Splunk Decoded: Service Maps vs Service Analyzer Tree View vs Flow Maps

It’s Monday morning, and your phone is buzzing with alert escalations – your customer-facing portal is running ...