Forum Discussion

Antony_Hawkins's avatar
8 years ago

DataSources_List PropertySource

(Edit, October 2020 - see later comment below for a version that does all this without needing an API call)

Q: What does it do?

A: Calls the LogicMonitor API and finds, for each applicable device, a list of DataSource Names that exist on the Device, i.e. have at least one instance. This also includes ConfigSources active on the Device. These are put together as a semicolon-seperated list in the property auto.activedatasources:

c79ef7414884f314cf54c8317eb8bd77.png

Q: Why? I can just look at the Device in the Device tree.

A: You can, but... This PropertySource means you can create Dynamic Groups and Device Inventory Reports based on the presence or absence of *any* combination of DataSources on Devices.

Q: Can you give me a real-world example of this being useful?

A: Yes. On a Microsoft SQL server, LogicMonitor will find the SQL Services via WMI, but the actual SQL Server metrics are found via Perfmon or JDBC methods. If we can't access Perfmon or JDBC for any reason (required services not running, lack of credentials, etc) we'll be missing the SQL stats but quite probably getting all the other Windows metrics (via WMI). This can be very difficult to spot if you have one affected SQL server out of 1,000.

With this PropertySource running, you could create a Dynamic Group with a custom query of:

auto.ActiveDataSources =~ "WinSQLServices-" && auto.ActiveDataSources !~ "WinSQLServer-" && auto.ActiveDataSources !~ "WinSQLServer_JDBC-"

This will list all the devices on which we've found SQL Services but have failed to find any SQL metrics.

Similarly Exchange Services are discovered via WMI, whilst most Exchange metrics come from Perfmon.

Or, maybe you want to create a Group to contain all your Linux servers that are running Apache web server and MySQL:

isLinux() && auto.ActiveDataSources =~ "Apache-" && auto.ActiveDataSources =~ "Mysql-"

You will need:

A REST API Access ID and Access Key for a user with permissions to at least view all Devices within the account (or all Devices in whichever Groups you wish to consider). These should be set as properties 'apiaccessid.key' and 'apiaccesskey.key' within the Devices tree (generally the root level, or a Group level if appropriate).

The PropertySource will use these to find the list of DataSources present on the Device, and create the auto.activedatasources property for all devices.

auto.activedatasources will have one of two error messages if the required API details are not present or do not give sufficient access to query the Device; this could of course also be used to create Dynamic Groups and in Device Inventory Reports.

Note that DataSources are listed by their (unique) 'Name' rather than their (not necessarily unique) 'Displayed As' string seen in the Device tree.

v1.0.0: ZLTDWM

Current limitations:

The auto.property fields are limited to 2,000 characters, so if the list of DataSource Names exceeds this size, the data will be truncated. This is likely to be an edge case only seen on test Devices with multiple custom DataSources applied.

Auto Properties are updated daily or when Active Discovery is run for a Device, so there may (will!) be a time lag between DataSources being applied to a Device and those DataSources appearing in this auto.activedatasources property list.

  • @Antony Hawkins First, I would like to say that this PropertySource is awesome and solved a big problem I had on trying to manage SDT for some SQL Queries we added as DataSources. 

    I do have an issue that I hope you can help with.

    The PropertySource has been added to our environment and it is working great on every device that isn't monitored by a Large Collector. The devices monitored by these collectors test well in the PropertySource and fall into the AppliesTo devices, but the property is never written to them. If I change a device from being monitored by a Large Collector to a Medium Collector then the property is written.

    Any ideas what may be causing this and how to resolve?

  • Update...

    I have now constructed a "version 2" of this that produces the same output without making any API calls, meaning no need for API credentials and a more efficient collection.

    It can do this because the collector running the PropertySource for a resource already knows the tasks it has to run for that resource.

    v2.1.0: EWZY2K

  • It seems YH9ZXM is unavailable due to security review. Is there a stats on this?

  • @Antony Hawkins i just modified the pair values to be lowercase. the upper case response was fine, it was just the "auto.propertyname" that couldn't be "auto.PropertyName", very odd behavior, but that caused issues for some reason. 

  • Thanks Tom, good to know it's already being useful!

    Did you modify the output with '.toLowerCase()' or similar, or was there more to it?

    Cheers

    Antony

  • This wasn't working for us, I think we ran into a bug somewhere where uppercase property sources weren't working, i set them to lowercase in this one and it started working. not sure why that was an issue though, i've got other datasources that i believe i have uppercase letters in. just an fyi. this is great though, will use this in our dynamic grouping applies to functions.