Deployment Architecture

Deployment Server inputs.conf discussion

chris94089
Path Finder

Greetings,

I'm designing a deployment server component for my team and inputs.conf are a question I haven't fully worked out.

Since inputs are arbitrary, one-off decisions made by a client, would a valid approach be to just make a serverclass configuration for each specific input as our clients request them?

Is there such a thing as grouping inputs?  Right now I'm thinking about having a serverclass for each index, then for the Client Name include the case number, and assign the apps/indexes accordingly. 

I'm curious to learn about about success or failure stories.  Thanks again!

Labels (2)
0 Karma

chris94089
Path Finder

I was referring to deployment apps that a deployment server can provide to universal forwarders, and their corresponding server classes.  

In a multiple cluster scenario, for outputs, it makes sense to create an app's outputs.conf file to match each indexer group.  

With inputs things get more complex.  We don't get to know how our customers are using the indexes they ask us to set up for them.  Our role is to provide the support when stuff breaks.  But it would be nice to provide a one-time on-boarding experience for them and have a deployment server maintain their configurations going forward.  

The question then becomes, what's a logical way to organize deployment apps that have inputs.conf?  Does one exist?  At this point I don't think so.  Unless there's a way implement a standard location for our users to send their log files on their machines, and stuff like that.

0 Karma

richgalloway
SplunkTrust
SplunkTrust
I'm not sure there's a "standard" way to organize deployment apps. There is a naming convention for apps, but I think that's not what you mean.
While there are some common inputs you can give to all customers (Windows event log, Linux logs, etc.), most will be custom for the client. That's especially true for client names in the deployment server. I've yet to see two customers use the same naming scheme for their servers so DS client names are never routine.
---
If this reply helps you, an upvote would be appreciated.
0 Karma

richgalloway
SplunkTrust
SplunkTrust

IMO, one should not be "creative" with sourcetype names.  Many apps rely on common sourcetypes and using different names means those apps will not work until you modify them.  Then you always will be modifying them.  Stick with the common sourcetype names as much as possible.  For less common sourcetypes, try to follow the convention laid out at https://docs.splunk.com/Documentation/AddOns/released/Overview/Sourcetypes#Source_type_naming_conven...

There are 3 main reasons for creating a new index:

  1. Different retention requirements
  2. Different access control requirements
  3. The volume of a data source would cause performance problems if not separated.

Notice "different sourcetype" is not on this list.  That's because it can improve performance if different sourcetypes frequently used together are in the same index.

I'm not sure what you mean by "grouping inputs".

---
If this reply helps you, an upvote would be appreciated.
0 Karma
Take the 2021 Splunk Career Survey

Help us learn about how Splunk has
impacted your career by taking the 2021 Splunk Career Survey.

Earn $50 in Amazon cash!