I have designed my scripts to be generic so that when passed different variables, the result will be different. Take for instance the case of monitoring UNIX filesystems. I want the result of the script run for each filesystem to contain certain pieces of information about that particular filesystem including such things as the mount point, size info, inode info, mount status, related devices, configuration options, etc.
To accomplish the above, I write a script that will accept a passed variable which is the mount point for that filesystem. The above information is then gathered and fed back to SAM for display and evaluation. Hence the script is generic and will be reused for each filesystem on a server. Additionally, to make implementation of a new server quicker, every filesystem I would expect to see in our environment has an associated Component Monitor within the Application Monitor Template. This is done so that I can generically control default thresholds for each filesystem across all servers. I then only turn on the Component Monitors that exist on the node to which the Application Monitor will be assigned. If a filesystem on a particular server has different thresholds from the default in the Template, I adjust it within the Assigned Application Monitor.
I also separate out categories of filesystems into different App Monitors. So for example I have an App Monitor for OS filesystems, another for filesystems related to the DB engine we use, one for each of the apps we develop and others for 3rd party apps we use.
This all adds up to a lot of instances of that same generic script. In fact, for the filesystem script alone, it is currently used in 227 Component Monitors within our environment. This means that each time that generic script is changed, we have to copy it into SAM 227 times in order for all filesystems to be using the most recent script. Mind you this is not the only monitor designed this way. In fact, most are this same design.
So here is my thought on this... Why not have a Script Library within SAM where scripts that will be used more than once will be stored. Then in the Component Monitors, in addition to the current method of adding a script directly into the Component Monitor, provide the ability to browse the Script Library and select which script you want associated with the particular Component Monitor. Then when the script is updated, you just replace it in one place, within the Script Library, and all Component Monitors are automatically updated to use the latest version. I know for me this would save me many, many hours of work.
There is one more concern with this and that is if the generic script in the Script Library is updated to change the output fields in some way, this will affect all of the Component Monitors related to this script. Obviously then you may need to go and touch each of those Component Monitors to update the output fields and any thresholds that might be affected. If there was a way to force the new output fields out to all related Component Monitors from within the Script Library, that would be nice but then you have to also address thresholds that would disappear or new thresholds that would be needed for added sub-components on a per Component Monitor basis.
Maybe that process could keep using the previous script while walking you through each of the affected Component Monitors so that you could adjust where needed. As each Component Monitor has been evaluated, the process would then switch that Component Monitor to use the new script while moving you to evaluation of the next Component Monitor.
Have not thought this part through too far. If you have ideas, please post here. I just know I could really use the Script Library for changes that don't change the output fields. In most cases, my script updates do not.
