Should I split inputs and props into distinct apps?

[spl_aficionado]

Our custom here is to create a props app and an inputs app. The inputs apps are being deployed on the on-prem side, while for the props apps we usually deploy on the cloud. I wonder whether to consolidate inputs and props into one app for simpler administration.

[gcusello]

Hi @spl_aficionado ,

separating inpus and props is a recommended PS best practices even if I don't understand why to use two different add-ons.

As @PickleRick said, I use two custom apps only on UFs, on HFs I use to create a custom app for inputs and I use standard (from Splunkbase) TAs for the props, so I can easily upgrade them.

Ciao.

Giuseppe

[PickleRick]

This is a kinda "religious" question. There are some people who prefer having more small apps, others like having bigger, consolidated ones. I'd probably try to keep a typical add-on/app split (add-on containing the "technical" part of stuff for given solution - inputs, props and so on, app containing dashboards and such). I'd push the app with inputs disabled by default and I'd locally push an additional app enabling selected inputs.

But it's not "the only right solution".

There can be exceptions - for example if the input part is heavy (like containing modular inputs with a lot of code) I could consider splitting it into another app so that it doesn't end up on SHs (and replicated in knowledge bundle to indeers).

[richgalloway]

I vote in favor of maintaining the split - not as an input/props split, but as an on-prem/cloud split.  Inputs that work on-prem probably don't work (at least not the same) in the cloud and props in one may not apply to the other.

[spl_aficionado]

Thank you @richgalloway, in general, would you combine the inputs and props apps?

[richgalloway]

I would consider putting inputs.conf and the props associated with the sourcetypes in those inputs into the same app.  I also would ensure all inputs are disabled by default.

If multiple input.conf file reference the same sourcetype (like "syslog", to use a bad example) then I would move the props to a separate app.  This should help future maintainers realize the props are not specific to any one input.