Deployment Server inputs.conf discussion

[chris94089]

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!

[chris94089]

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.

[richgalloway]

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.

[richgalloway]

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".