Deployment Architecture

Where Should Trigger Scripts Be Placed In A Search Head Cluster

peacher17
Explorer

Hi,

Can anyone confirm where the scripts should be placed in a Search Head Cluster that are used as an alert action in a saved search. I know that they are normally located in $SPLUNK_HOME/bin/scripts, but is this still the same for Search Head clusters (does the script still sget placed in the same location on each of the search heads in the cluster or somewhere else)?

Thanks

0 Karma
1 Solution

lguinn2
Legend

Yes, the scripts still get placed in the same locations. The two allowed locations are

$SPLUNK_HOME/bin/scripts
$SPLUNK_HOME/etc/apps/<AppName>/bin/scripts

I would put the script in the same app as the search that is being used as the alert.

There is a potential problem here. If you create the search/alert using the Splunk UI on any clustered search head, it will be replicated on all the search heads within the cluster. However, when you manually add the script to one search head - it will not be replicated. And there isn't a way to create the script in the Splunk UI; manual is the only way. Now you must copy the script to all the search heads manually yourself. Now, you have just skirted the rules by manually updating the apps in the cluster - and how will you maintain this? It could get tricky, especially if you add more search heads to the cluster, etc.

The best practice is to create the alert and the script on a test system and make sure it works. Then update the appropriate app on the deployer and use the deployer to push the app (which contains both the alert and the script) to all search heads. This is why I suggest that you use $SPLUNK_HOME/etc/apps//bin/scripts - it's part of an app and therefore can be managed.

Alerts are a special animal - they are more than just scheduled searches because they have triggers and actions and suppression rules. Hopefully this will get easier in subsequent versions - Splunk 6.2 is the first release for search head clustering and everything is not as smooth as I would like.

View solution in original post

pj_elia
Engager

does anyone know if this issue was addressed in 6.3?

0 Karma

lguinn2
Legend

Yes, the scripts still get placed in the same locations. The two allowed locations are

$SPLUNK_HOME/bin/scripts
$SPLUNK_HOME/etc/apps/<AppName>/bin/scripts

I would put the script in the same app as the search that is being used as the alert.

There is a potential problem here. If you create the search/alert using the Splunk UI on any clustered search head, it will be replicated on all the search heads within the cluster. However, when you manually add the script to one search head - it will not be replicated. And there isn't a way to create the script in the Splunk UI; manual is the only way. Now you must copy the script to all the search heads manually yourself. Now, you have just skirted the rules by manually updating the apps in the cluster - and how will you maintain this? It could get tricky, especially if you add more search heads to the cluster, etc.

The best practice is to create the alert and the script on a test system and make sure it works. Then update the appropriate app on the deployer and use the deployer to push the app (which contains both the alert and the script) to all search heads. This is why I suggest that you use $SPLUNK_HOME/etc/apps//bin/scripts - it's part of an app and therefore can be managed.

Alerts are a special animal - they are more than just scheduled searches because they have triggers and actions and suppression rules. Hopefully this will get easier in subsequent versions - Splunk 6.2 is the first release for search head clustering and everything is not as smooth as I would like.

peacher17
Explorer

Thanks Iguinn, just what I was looking for.

0 Karma
Get Updates on the Splunk Community!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...