Archive

Splunk TA Add-ins

Path Finder

Hi All,

I've recently been looking at Splunk again after a few months away and have decided to look at using some TA add-ins.

I understand in order to work the configuration files in a more managable way it is possible to extract (for example) the inputs.conf from several TA add-ins and combine in a custom app.

Say for example I have the Splunk_TA_Windows add-in and the Splunk_TA_Cisco, both have an indexes.conf so rather than distributing two differnt files I could create an 'indexes' App and combine all settings in one file.

Is that also possible with the inputs.conf file? Are there any issues breaking out input files from their original bundle into new Apps or should they be kept with their source files generally ?

Thanks in advance,

M

Tags (1)
0 Karma
1 Solution

It's possible to take the approach you're suggesting, but it's certainly not the recommended route. If you combine all these configuration files together and later decide you no longer need the settings from a given app, you'll have to do all the work of manually finding which settings came from that app and remove them. You'll lose the traceability that allows you to answer questions like, "Why is this extraction here in the first place? What purpose does it serve?"

But moreover, you will lose the ability to update an add-on in a straightforward manner. The modularity of Splunk add-ons is a feature, not a bug. It may seem early on that you would benefit from having one single inputs.conf file that rules them all (insert Lord of the Rings reference here), but trust me - you will be in far better shape six months from now if you maintain the usual app/add-on structure and distribute apps as bundles rather than appending little bits and pieces here and there.

That said - if you are finding that you only need one extraction here, another single input specification from there, etc...you can definitely pull the bits you like and put them together. I just don't think you'll get as much benefit as you expect from doing this wholesale across many add-ons.

View solution in original post

0 Karma

It's possible to take the approach you're suggesting, but it's certainly not the recommended route. If you combine all these configuration files together and later decide you no longer need the settings from a given app, you'll have to do all the work of manually finding which settings came from that app and remove them. You'll lose the traceability that allows you to answer questions like, "Why is this extraction here in the first place? What purpose does it serve?"

But moreover, you will lose the ability to update an add-on in a straightforward manner. The modularity of Splunk add-ons is a feature, not a bug. It may seem early on that you would benefit from having one single inputs.conf file that rules them all (insert Lord of the Rings reference here), but trust me - you will be in far better shape six months from now if you maintain the usual app/add-on structure and distribute apps as bundles rather than appending little bits and pieces here and there.

That said - if you are finding that you only need one extraction here, another single input specification from there, etc...you can definitely pull the bits you like and put them together. I just don't think you'll get as much benefit as you expect from doing this wholesale across many add-ons.

View solution in original post

0 Karma

Path Finder

OK, thanks for responsing to this.

I can certainly see the pitfalls and I think you've made a good case here for not doing what I'm suggesting with inputs.conf files. I have perhaps misunderstood some advise I received on extracting things like the outputs.conf and indexes.conf into custom Apps. I suppose these are likely to be more common throughout a deployment...

M

0 Karma