Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Taking Output from Application Monitor and Populating Custom Property

We have a request to obtain a in-house custom software version number from a file and update a custom property field on the node within Solarwinds. The first though was to have a script that would pull the value from the file within an application template monitor and then update the custom property. The problem is, I'm not sure how to connect those two parts. I've got alerts that will update custom properties with static values based on certain trigger conditions, but I'm not sure how to set the property value to a variable based on the output of a monitor.

One way I could think of would be to obtain the value, and then update the custom property directly in the SQL database - all within the same script within the same application monitor. However, is there an easier way that I'm missing? Also, if I were to go about updating the property in SQL directly, is there a single row somewhere that I should update or would there be multiple tables I would need to update?

Cheers in advance for any replies

Find more posts tagged with

Accepted answers

All comments

bobmarley

If you already have a file that has the IP address or caption and the serial number you could directly import using the Custom Properties Import function. That would be the easiest way.

ST1285

Thanks for your reply, but the number within this file (on multiple monitored nodes) changes very frequently and we need an automatic solution

mesverrum

So from my perspective you are kind of falling into a trap by thinking you should use SAM to query the data and then cobble that together with an alert or some other trickery. I say that because if you have the relevant scripting skill to do that in SAM then you would have a much easier time just running the script as a scheduled task on your orion server or some other utility system. In bad psuedo code i'd expect something only slightly more complicated than

get-swisdata for a list of $nodes that might need to be updated
foreach $node check the lines of the file and get the current version
if $version -ne $node.customPropertyName Set-SwisObject $swis -Uri $node.uri -Properties @{customPropertyName ="$versionNumber"}

The reason i don't love embedding something like this into a SAM script is because then you have to add a bunch of boilerplate syntax to make it provide a valid SAM output, its adding potentially a lot of overhead and admin chores to your polling engines, cluttering up a bunch of redundant data into your database. And what do you get for all that extra hassle? I guess the only perk I can think of for having it in SAM is that you have less risk of forgetting the script exists because you would see all the stuff showing up in the web console. Maybe it would be nice to know historically when the version changed but there are literally a thousand ways to log that which would be more space efficient than storing it in the SAM component tables for 180 days of retention.