Property source per database

It sounds like you want a custom property per database instance. PropertySources create device level properties. You probably want a property on each database instance that is different from the properties of other database instances, right? In that case, you need to modify the discovery of those instances to set ILPs or instance level properties. How to do that will depend on which method of discovery is used in the DataSource you're looking at. Can you provide more details on what you have already and where you want these properties to eventually live? What DataSource is currently showing your databases?

2 hours ago, Stuart Weenig said:

It sounds like you want a custom property per database instance. PropertySources create device level properties. You probably want a property on each database instance that is different from the properties of other database instances, right? In that case, you need to modify the discovery of those instances to set ILPs or instance level properties. How to do that will depend on which method of discovery is used in the DataSource you're looking at. Can you provide more details on what you have already and where you want these properties to eventually live? What DataSource is currently showing your databases?

So the hope would be that just running a simple select query from the specific database would populate the property.  So I wouldn't want the property to be at the SQL instance level but actually on the database.  

Hope that makes sense.

db instance != lm instance

You're using the word instance to refer to the SQL instance. I'm using it to refer to the LogicMonitor resource instance. Your "resource" (aka device) has children on it. Each child is an instance. Each CPU is an instance, each disk is an instance, each NIC is an instance, RAM is an instance, open TCP/UDP ports are each instances, etc.. So, if you're monitoring a server, you will have one or more LogicMonitor "instances" associated that server in LogicMonitor as a child of that object. For databases, you'll have usually a LM instance per database. All of this depends on the details of the databases as they show up in LogicMonitor under the device. What is the DataSource that is currently showing the databases in LogicMonitor (or are the databases not yet showing up as children under the server)?

4 hours ago, Stuart Weenig said:

db instance != lm instance

You're using the word instance to refer to the SQL instance. I'm using it to refer to the LogicMonitor resource instance. Your "resource" (aka device) has children on it. Each child is an instance. Each CPU is an instance, each disk is an instance, each NIC is an instance, RAM is an instance, open TCP/UDP ports are each instances, etc.. So, if you're monitoring a server, you will have one or more LogicMonitor "instances" associated that server in LogicMonitor as a child of that object. For databases, you'll have usually a LM instance per database. All of this depends on the details of the databases as they show up in LogicMonitor under the device. What is the DataSource that is currently showing the databases in LogicMonitor (or are the databases not yet showing up as children under the server)?

Gotcha, the children indeed are populated by the Microsoft_SQLServer_Databases datasource.  The thought originally was to use a datasource but since the need is to use strings, the thought went to properties.  For example create a property per SQL database that is populated by something simple like "select version from versions"

You're thinking is good since datapoints can only contain numbers. However, DataSources define how instances are created, including any instance level properties that are created during discovery (and updated through subsequent discoveries). 

That DS uses a fairly large, but not overly complicated, script to do discovery. Line 32 is what grabs the list of databases. The loop that starts on line 37 processes each of the results and ends up outputting a single line that defines the instance creation (specifically line 66). 

Notice how there is an ilps variable at the end of that line? The script already outputs some instance level properties. You just want to add to that. Line 54 seems to be where each database is looped. Probably within that loop you'd want to add the execution of your query. Then take the result and append it to line 66 like this:

println "${wildvalue}##${instanceName.trim()}/${name}######${ilps}&mycustompropname=${customqueryoutput}"

Where mycustompropname will be the name of the property and the customqueryoutput variable contains the result of your query.

1 minute ago, Stuart Weenig said:

You're thinking is good since datapoints can only contain numbers. However, DataSources define how instances are created, including any instance level properties that are created during discovery (and updated through subsequent discoveries). 

That DS uses a fairly large, but not overly complicated, script to do discovery. Line 32 is what grabs the list of databases. The loop that starts on line 37 processes each of the results and ends up outputting a single line that defines the instance creation (specifically line 66). 

Notice how there is an ilps variable at the end of that line? The script already outputs some instance level properties. You just want to add to that. Line 54 seems to be where each database is looped. Probably within that loop you'd want to add the execution of your query. Then take the result and append it to line 66 like this:

println "${wildvalue}##${instanceName.trim()}/${name}######${ilps}&mycustompropname=${customqueryoutput}"

Where mycustompropname will be the name of the property and the customqueryoutput variable contains the result of your query.

Nice that is cool, thanks for the pointer brain cells are starting to bump together now.