Deployment Architecture

Index assignment for related sub-networks

sdwilkerson
Contributor

An enterprise network has many sub-networks each with UniversalForwarders forwarding to a central pool of Indexers.
The data from each sub-network should be contained within it's own index, e.g.:

  • index=site1-windows
  • index=site1-unix
  • index=site2-windows
  • index=site2-unix

Since managing many hundreds of IPs in the blacklist/whitelists on a single Deployment Server is painful, what is the recommended approach to ensure the deployment-clients from one subnet properly assign the data to the correct index?

Here are two possibilities, but am certainly open to other suggestions (or a confirmation that one of these is best-practice):

  • A separate Deployment Server for each sub-network. This is a lot of extra work and duplication, but allows use of "machineTypes" and requires less ongoing *list maintenance.
  • Parsing configs on the Heavy Forwarders to assign the correct index based on subnet via regexes

Thanks in advance.

0 Karma

gkanapathy
Splunk Employee
Splunk Employee

You can set the "clientName" item in the deploymentclient.conf file when you initially install the forwarders, then use that in your whitelist/blacklists to distinguish broad classes of machine like this. Each site will have a base install package that differs only in that setting, but can all go back to the same Deployment Server.

0 Karma

sdwilkerson
Contributor

Thanks gkanapathy.
Using clientName means blacklists/whitelists will still need to be used, but only on the base install package stanza. This will make the serverclass.conf cleaner, but still has the same complication of managing the *lists. Correct?
Also, this still requires separate deployment-apps for each "index" variation. Is there a simple way around this, that I am missing?

0 Karma
Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.
Get Updates on the Splunk Community!

Data Persistence in the OpenTelemetry Collector

This blog post is part of an ongoing series on OpenTelemetry. What happens if the OpenTelemetry collector ...

Introducing Splunk 10.0: Smarter, Faster, and More Powerful Than Ever

Now On Demand Whether you're managing complex deployments or looking to future-proof your data ...

Community Content Calendar, September edition

Welcome to another insightful post from our Community Content Calendar! We're thrilled to continue bringing ...