APM templates are designed to be centrally managed to avoid the issues you describe above. A properly written script body should have variables or switches that can be defined as the template is applied to a node. This is the only area that should be unique if you're trying to monitor different properties on a given machine (drive letters for example that may be unique per-machine). The script body itself should be static and easily updated by modifying the master template itself. Any node that has this template applied will inherit these changes automatically unless inheritance has been blocked/overridden at the node level.
Thanks for the response alterego.
The way templates are currently implemented works fine in many cases; however, there are some instances where stand alone templates can become bulky with poor organization.
This issue first came about for us when we had to write script monitors to check website data for a third party vendor hosting one of our resources. They have a page setup that displays critical information that can be monitored via scripts to check for application health. Additionally, there are three separate servers hosted for us all with individual IPs and app helath data.
Currently we have to include an HTTP monitor, AppHealth1 monitors (8 individual items on the page), and AppHealth2 monitors (16 individual items on the page). The scripts for AppHealth1 and AppHealth2 or wholly different due to some vagaries in the way the page is setup, but for each individual item in each all that is required is a different command line argument. We currently have AppHealth1 setup as its own template with 8 script components added to it, and AppHealth2 setup as its own template with 16 script components added to it. These templates are then applied to each of the 3 servers for monitoring.
If we did as was suggested in your post, using only 1 template for each, then there would be a total of 25 APM monitors on each server which leads to poor organization and a rather ugly and overwhelming interface for the powers that be when they need to look at server health. By breaking it down into 3 APM monitors with 1, 8, and 16 components respectively we are able to provide a much more polished and organized interface along with easier maintenance and setup. Even in the current state, initial setup can be ponderous by requiring multiple copy/pastes to not only the script body but for the thresholds as well. Granted, after the template has been created it simply requires us to go in and modify the command line wherever we apply the template and what I'm requesting with the ability to create standalone components won't change that aspect of it at all.
The ability to create a component would limit the time investment for template creation as well as any future changes that are required to the script itself. There are also cases where we use the same script applied to different application monitors for specific devices. By having the ability to create this as its own component it provides for a much cleaner organization as well as setup/maintenance of the script.
It sounds like you would appreciate the multi-value script support included in APM 4.2. This could simplify your life a little and provide you the level of organization you are looking for.
Release Candidate signup and information see our previous post below:
For a more detailed description of multi-value script monitors see our earlier blog posting here:
The multi-value script looks like it would definitely alleviate some of the issues I've had with some of the more complicated script monitors. I'll definitely be keeping an eye out for the final release of APM 4.2, much to the dismay of our server upgrade manager - 50 sites and he hasn't finished upgrading them all to 4.1.
It would still be nice to be able to create stand alone script components that can be added to any template though, but the multi-value scripts definitely reduces the need for this feature.