Deployment Architecture

Do big implementations break down the serverclass.conf into multiple files?

ddrillic
Ultra Champion

We wonder if it makes sense to break down the serverclass.conf into multiple smaller files.
As it grows into five or six thousand lines, we wonder if it makes sense to keep growing it up.

Any thoughts?

Tags (1)
1 Solution

koshyk
Super Champion

Very good question and absolutely is the answer. It all depends on how much automation you require for your organisation and how your load balancing & firewall is enabled.

Let's take a large organisation and assume the hosts/clients are part of CMDB. So the simple 1 level iteration we could do is
1. Collect hostname, operating_system from cmdb (into a CSV)
2. Using a script, split this into minimum of 2 serverclass . (eg Windows, Unix). Details of machineTypesFilter in here

So your script/automation can generate two serverclass (MY_windows_serverclass, MY_nix_serverclass) and put stanza automatically something like (example of MY_windows_serverclass)

[serverClass:WindowsMachineTypes]
machineTypesFilter=windows*
whitelist.0=winhost1
whitelist.1=winhost2
..
whitelist.3012=winhostSomeOther3012

[serverClass:WindowsMachineTypes:app:AppsForDesktops]
[serverClass:WindowsMachineTypes:app:AppsForWindowsOnly2]

This way, your Windows Serverclass App will contain settings for Windows and deployment-app to be pushed only for Windows etc.
You can split this further into more chunks depending on how much automation you need (like Win 2012, Win2008) on what you get from CMDB

The more modular you make, better the automation and management of whitelists

View solution in original post

ddrillic
Ultra Champion

From the SE -

-- How many files of one type (inputs, props, transforms, server class) doesn't matter to Splunk, it's all read into memory as one object.

If breaking them into multiple files makes your job easier though, go for it. Doesn't matter to Splunk.

0 Karma

koshyk
Super Champion

Very good question and absolutely is the answer. It all depends on how much automation you require for your organisation and how your load balancing & firewall is enabled.

Let's take a large organisation and assume the hosts/clients are part of CMDB. So the simple 1 level iteration we could do is
1. Collect hostname, operating_system from cmdb (into a CSV)
2. Using a script, split this into minimum of 2 serverclass . (eg Windows, Unix). Details of machineTypesFilter in here

So your script/automation can generate two serverclass (MY_windows_serverclass, MY_nix_serverclass) and put stanza automatically something like (example of MY_windows_serverclass)

[serverClass:WindowsMachineTypes]
machineTypesFilter=windows*
whitelist.0=winhost1
whitelist.1=winhost2
..
whitelist.3012=winhostSomeOther3012

[serverClass:WindowsMachineTypes:app:AppsForDesktops]
[serverClass:WindowsMachineTypes:app:AppsForWindowsOnly2]

This way, your Windows Serverclass App will contain settings for Windows and deployment-app to be pushed only for Windows etc.
You can split this further into more chunks depending on how much automation you need (like Win 2012, Win2008) on what you get from CMDB

The more modular you make, better the automation and management of whitelists

Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

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

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...