Archive

what are your Deployment App naming conventions?

Contributor

looking for some inspiration or guidelines about namespaces whilst deploying apps from Deployment Server.

1 Solution

Path Finder

I have been selling splunk for about 6 years, and now I will be using Splunk for my new Job. I'm going to follow this convention.


Acme_DC_InfoSec_nix_HWFwd_inputs
Acme_NYC_IT_Win_IntFwd_outputs
Acme_SF_InfoSec_nix_EPFwd_deployclient
Acme_DC_Sales_MAC_HWFwd_limits

  • This will ensure that if two companies with Splunk Merge your time will be made easier
  • In case you want to have different files per location (Think of a multi-site cluster with outputs.conf)
  • This gives you the ability to understand who has requested this app so you can ask them questions
  • This is often useful if there are setting that are needed for a given OS
  • This is for the type of machine. EndPointFwd, HeavyWeightFwd, IntermediateFwd
  • The name of the app or file that will be target. base is often used to imply inputs.conf, web.conf, server.conf, outputs.conf

View solution in original post

Path Finder

While similar to the accepted answer above, I find it easier to see what is/should be deployed where if there is a slightly different order to the parts of the app name.

We create apps based on functionality -- "Internal App for our main webapp cluster" will be the user-facing name of it (functionality to monitor the J2EE stacks that back our production website), but on the back end, I have 3 apps^W^W 6 apps defined:

  1. int_webapp_prod_data
  2. int_webapp_prod_ui
  3. int_webapp_prod_agent
  4. int_webapp_test_data
  5. int_webapp_test_ui
  6. int_webapp_test_agent

(See the pattern, and how things would line up in the Deployment Server interface?)

The _data apps contain the index definitions and any index-time extractions (indexes.conf, fields.conf, etc.) This is deployed (via DS) to all of my indexers
The _ui app has search-time configurations-- saved searches, dashboards, search-time extractions, and other things that influence the user interface
The _agent app gets sent via the DS to the relevant forwarders (in this example, it would be deployed to the internal app servers. This contains (basically) 2 pieces: inputs.conf and outputs.conf. What to look for, and where to send it, but sometimes the inputs require a python script or something in .../bin

And of course, you have a test environment, right? 😉

A couple of code-requirements I've found useful in the apps:

  • Make a macro that abstracts the index names in the UI app. So instead of having "index=webapp_perf" as the search, put that in macros.conf and search webapp_index instead. Just in case your index needs to be renamed (or the app published)
  • Specify output locations for your data, even if the default would work. Much better for migration when you need a different indexer (like when you move your app from the test index to the production one)
  • Use version control (I use git) to move changes from "developer-sandbox" to "test" to "prod".
0 Karma

Esteemed Legend

Will you give an example macro and and example search that uses it? I would probably use eventtypes for this abstraction instead.

0 Karma

Path Finder

sorry for the delay:

defaults/macros.conf

[int_webapp_idx1]
definition= index=the_real_index_name

defaults/savedsearches.conf

[Event count by host last 15 minutes]
search = `int_webapp_idx1` 
dispatch.earliest_time = -7d

The macro name gets enclosed in backquotes in the query, which turns that bit of the answer into "code" and mangles my answer

0 Karma

Communicator
  1. Renaming apps almost always works fine. I have seen issues (I'm guessing where the UF crashes on restart) where the old app gets left behind, and is now unmanaged. In my case I tend to use a naming scheme with the config/file or function at the beginning. This might be 'monitor_' or 'parsing_'. In the case of apps sourced from splunkbase I use them without renaming, with as few mondifications as possible. This makes matching them back with splunkbase downloads and doing upgrades easier. The specific configurations go in a second app that overrides the configs in the first. (e.g: Splunk_TA_windows from splunk base, and Splunk_TA_windows_datacentre3 with some mods)
  2. I also have added a scripted input that runs btool on inputs each day. This outputs enough information to figure out the name of all the apps on an endpoint, and pickup if you have more deployed than you want. This also allows us to pick up if someone has deployed their own app manually on an endpoint. UNIX sh: $SPLUNK_HOME/bin/splunk btool --debug check >/dev/null 2>&1 $SPLUNK_HOME/bin/splunk btool --debug inputs list > $SPLUNK_HOME/var/log/splunk/btool_inputs.log Windows bat: ECHO OFF "%SPLUNK_HOME%\bin\splunk" btool --debug check > nul "%SPLUNK_HOME%\bin\splunk" btool --debug inputs list > "%SPLUNK_HOME%\var\log\splunk\btool_inputs.log"
  3. Avoid configs in system/local where possible, as otherwise you can never override them.

Contributor

awesome insight @Colin Humphreys! thanks man!

0 Karma

Path Finder

I have been selling splunk for about 6 years, and now I will be using Splunk for my new Job. I'm going to follow this convention.


Acme_DC_InfoSec_nix_HWFwd_inputs
Acme_NYC_IT_Win_IntFwd_outputs
Acme_SF_InfoSec_nix_EPFwd_deployclient
Acme_DC_Sales_MAC_HWFwd_limits

  • This will ensure that if two companies with Splunk Merge your time will be made easier
  • In case you want to have different files per location (Think of a multi-site cluster with outputs.conf)
  • This gives you the ability to understand who has requested this app so you can ask them questions
  • This is often useful if there are setting that are needed for a given OS
  • This is for the type of machine. EndPointFwd, HeavyWeightFwd, IntermediateFwd
  • The name of the app or file that will be target. base is often used to imply inputs.conf, web.conf, server.conf, outputs.conf

View solution in original post

Path Finder

I have a rule to minimize rate of change when possible, so I would follow a 5 step process.

1) Add NewApp (cp OldApp NewApp)
2) Using the Deployment GUI, map the NewApp to the same set of clients as the OldApp was mapped to
Wait-Verify
3) Remove the OldApp from clients
Wait-Verify
4) Remove the OldApp from the CLI
5) Modify NewApp as needed

On to your next question... If you are moving something from system-local then you are correct. That would be step 4 above - then you would still need a service restart.

If you would like to understand where you are getting configurations from use the btool command.

./splunk cmd btool props list --debug

Contributor

cheers @williamwar! 2 follow-ups for you:

  1. any caution about renaming existing apps? like if i have one called "foo_indexes", any issues if i rename it to "acme_NYC_foo_indexes" to match my new naming convention?
  2. just confirming - but following Configuration File Precedence - if i split these out from already-existing system-local files, i'll need to 1) also blow away system/local copies of those entries on each system and 2) restart splunk.
0 Karma
State of Splunk Careers

Access the Splunk Careers Report to see real data that shows how Splunk mastery increases your value and job satisfaction.

Find out what your skills are worth!