cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Custom Variables within Application Monitor Templates

Custom Variables within Application Monitor Templates

0 Kudos

I just posted another idea here on a similar topic.  Please review that idea as well as this idea.

Using the same example where I am writing filesystem monitors, there happens to be a certain customer specific identification directory in the path.  Each filesystem path contains that ID.  If the Application Monitor had the ability to either use customer variables, which are assigned values in the assigned Application Monitor, or to use Custom Properties for that purpose, then this would help to make it less work when assigning an Application Monitor to a node.

For example, let's say I have an Application Monitor with several Component Monitors using the same script for monitoring filesystems mounted all mounted below the path of /usr/opt/abc/4567 where 4567 is the customer ID.  Within the Component Monitor, I either add a Custom Variable or, if they could be used, a Custom Property which is called "Customer_ID".  Now in the Command Line field I add something similar to "perl ${SCRIPT} /usr/opt/abc/${Customer_ID}/bin".  When I assign the Application Monitor to a node at customer 4567, I place "4567" in the "Customer_ID" Customer Variable/Property.  Now that value is automatically substituted into the command line everywhere the variable assignment is found.

This was a simple example but I think you can, as I do, see the possibilities to make our lives easier if this functionality existed.  In my other idea post, I mentioned about 60 filesystem monitors.  In this case those Component Monitors are related to 4 different Application Monitors.  So therefore, once again, 4 changes could me made to adjust all 60 monitors saving quite a bit of time.

THANKS FOR YOU TIME...

Mike

25 Comments
Product Manager
Product Manager

Both Node and Application Custom Properties are available for use in script monitors with SAM 6.0.

Level 12

Let me just clarify...  I am still on SAM 5.5.0 and will be upgrading both NPM and SAM next week.  Node Custom Properties have been available for a while and also in SAM 5.5.0 I know and use Application Custom Properties.

My suggestion goes beyond just being able to assign Custom Properties to Applications however.  So are you saying that we have the ability to insert a variable into the command line field which can then be replaced with a value stored int he Custom Property?

If that is possible, can you point me to something that would instruct me on how to format the variable name?

I am guessing that if this is possible, you could also use a similar variable name within alert actions.  Is that correct?

Thanks for the reply...

Product Manager
Product Manager

Correct. The following list of Custom Properties can be used with essentially any SAM Script Monitor.

  • ${USER}
  • ${PASSWORD}
  • ${PORT}
  • ${Node.SysName}
  • ${Node.Caption}
  • ${Node.DNS}
  • ${Node.ID}
  • ${Component.ID}
  • ${Component.Name}
  • ${Application.Id}
  • ${Application.Name}
  • ${Application.TemplateId
  • ${Threshold.Warning}
  • ${Threshold.Critical}
  • Node Custom Property Macros ${Node.CustomPropertyName}
  • Application Custom Property Macros ${Application.CustomPropertyName}
Level 12

So I tried that and here was the result....

My original Command Line in the Component Monitor was "perl ${SCRIPT} /qmd/cpr/ucd/QMDPROD1 true 1".  BTW: this has been tested, including just before this exercise, and does work with an "Up" status and no problems.

I then created an Application Custom Property called "Base_Path".

Within the Application Monitor I placed "/qmd/cpr/ucd/QMDPROD1" into the "Base_Path" Custom Property field.

Next I changed the Command Line to read "perl ${SCRIPT} ${Application.Base_Path} true 1".

When I ran a test of this Component Monitor, I got "sh: ${Application.Base_Path}: 0403-011 The specified substitution is not valid for this command."  I tried the test several times with the same immediate result.

This got me to thinking about trying a test in Alert Manager to see how the field was translated to an SQL statement.  I found that the Alert Manager SQL uses "APM_ApplicationCustomProperties.CustomPropertyName" while for Node Customer Properties it is just "Nodes.CustomPropertyName" so I tried that in the Component Monitor and it still failed the same way.  Saved Component Monitor again, tested again and same result.

So while this would be great if it worked, it is not for me.  If I am interpreting something wrong, please let me know.

Again, thanks for the assist...

Level 12

A little further study...

I also tried to get the values in my ${Node.QCPR_4_Lab}, and ${Application.Lab_App} or ${APM_ApplicationCustomProperties.Lab_App} Custom Property fields to display in an alert email but they just appeared in the email as "${Node.QCPR_4_Lab}, and ${Application.Lab_App} or ${APM_ApplicationCustomProperties.Lab_App}" rather than the variables being replaced by the values.  This alert rule is setup with "Type of Property Monitor" set to "APM: Component" if that makes any difference.

Again maybe I am trying to do something that is not possible but I would have expected that it would work.  Or at least that one of them would have worked out of the three.

Product Manager
Product Manager

I should have clarified that the macros I listed above are available only in the script body, not in the command line arguments field of the script component monitor.

Level 12

So here is what I tried...

Within an existing script, I exchanged Message values for the simple values of "Warning = ${Threshold.Warning}", "Critical = ${Threshold.Critical}" and "Base_Path = ${Application.Base_Path}" and put a value in the Base_Path Custom Application Property for the Application Monitor.  All three of these returned blank values.

I did find the "Script Macros" help page which shows threshold macros as "${Threshold.Warning.XXX}" and "${Threshold.Critical.XXX}" but I don't see an explanation of what XXX stands for.  I tried with the exact wording including the XXX but still no values.  Are these used for passing the current Threshold levels into the script or passing values from the script back to SAM?  Are the help macros different then the macros you provided in your list above?

Also, while "Base_Path = ${Application.Base_Path}" did not work, when I changed it to "Base_Path = ${Application.Base_Path}" it did present the value I had in the "Base_Path" Custom Property for the Application.

I also tested the others from both your list and the "Script Macros" help page.  ${Component.ID} returned a zero which I don't know if is correct or not.  However ${Component.Name} did not return any value which leads me to believe they both might have a problem.  I did try it on a few different Component Monitors with the same result.  These are all using the "Linux/Unix Script Monitor" as the Component Monitor base and I don't know if that has anything to do with it.

The ability to use the Application Custom Property field values does resolve the initial reason I made this suggestion but would still like to figure out the Threshold and Component macros that did not result as expected since we also breached those here.  Any ideas or suggestions?

THANKS

Product Manager
Product Manager

The "XXX" at the end of the Macro are a variable to be defined by the user based on which warning or critical threshold value you would like populated within a multivalue script. Normally this is ".1", ".2". etc. but could also be a string, depending on your script output results.

Script Output.png

Level 12

Hopefully this won't be duplicated since I tried to respond to the email I got on your last and was returned a mail server error.

Guess I still don’t completely understand sorry… 

You stated in this thread that there was a macro ${Threshold.Warning} and another called ${Threshold.Critical}.  Are these different than ${Threshold.Warning.XXX} and ${Treshold.Critical.XXX}?

If so, I am interpreting that ${Threshold.Warning} and ${Threshold.Critical} pass the current values in the related Component Monitor Threshold fields to the script.  Is that correct?

As for ${Threshold.Warning.XXX} and ${Threshold.Critical.XXX} your definition in your last post leads me to believe that the values assigned to these macros are only used within the script.  If so, why would I need to use these macro names within the script?  Or, am I misunderstanding and these macros are assigned values within the script which are then passed back to Orion to replace the values, if any,  in the Component Monitor Threshold fields.

Thanks

Mike

Product Manager
Product Manager

The easiest way to show this macro's usage was to make a simple modification to an existing script. Below you see the "Statistic.User" statistic is one of multiple metrics being returned in this script. Statistic.System, Statistic.Wait, and Statistic.idle are also returned by the very same script. So each statistic has it's own unique name/identifier. This also allows us to have unique warning and critical thresholds defined for each metric returned.

In the script below changed the output of the script to return the warning threshold defined for the "User" metric using the ${Threshold.Warning.User}. The macro for warning will always start with "${Threshold.Warning." followed by the unique name you've chosen to identify the metric.

Warning Threshold Script Macro.png

As you can see below, "40" is the warning threshold defined for script output #1, which has a unique ID of "User".

Warning Threshold.png