Forum Discussion

Antony_Hawkins's avatar
4 years ago

Location / credentials / any custom property updater DataSource (framework)

This is a DataSource that enables you to update any single custom property on any collector-monitored resource.

Example use case / how this came to be:

Let's imagine for a moment that you have a collection of monitored resources on a mobile piece of kit, for example a sea-going vessel. One of those resources is a GPS locator device, out of which you can retrieve latitude and longitude values, and you'd like to use those to populate the 'location' property for the resource in LogicMonitor, such that your various vessel locations can be shown on a LogicMonitor dashboard.

This DataSource will let you do exactly that.

It's a framework, into which you'll still have to put a bit of effort, namely, you need to add code to actually find the value you want to set/update on the resource. Obviously enough I have no idea what that might be in your case...

However, all the rest of the work - actually updating the resource using the LogicMonitor API - is done for you.

Yes, you could use this to grab data from another property, such as an auto.prop set by a simple PropertySource.

Yes, you could put the same code into a PropertySource or ConfigSource if that were appropriate for your use case, give or take some tweaks to the outputs.

Yes, you could use this to pull SNMP location data from a device, although "3rd floor back office cabinet, rack 2, shelf 6" won't translate well onto a Google Maps widget.

You will need to:

1. Create LM API token credentials (ID and key) for a user with rights to manage the resource(s) in question. Set these as apiaccessid.key and apiaccesskey.key properties for the resource(s);

2. In the DataSource script, ensure line 27 defines the custom property name you want to update:

customPropertyToBeUpdated = 'location';

Note this must be a property that you can access via managing the resource - this excludes any auto.xxx and system.xxx properties;

3. Create and put whatever necessary code into the try{} block of the getNewPropertyValue() function (lines 32-49 in the template), that returns the desired property value as a string.

Note that depending on what that code is, you may need to add further imports to the top of the script;

4. Set a polling interval that makes sense for the rate of change of value;

5. Change the AppliesTo rule from false() to whatever is appropriate.

What it does:

1. Runs your code to get a new property value;

2. Checks that this would be a change from the existing property value (or absence of property);

3. If it is a change, calls the LM API and updates (or creates) that custom property.

It'll graph results on a success/failure basis, and alert if you're missing API credentials or if those credentials are inadequate for the resource.

And, look, see, location data:

 

...granted, you can't tell I didn't just manually do that...

 

Although designed and released as a location updater, bits of this code started life as an SNMP community string updater (by testing multiple community strings from a list, and setting the one that works: a href="https://communities.logicmonitor.com/topic/1867-pick-one-from-multiple-snmp-community-strings/" rel="">https://communities.logicmonitor.com/topic/1867-pick-one-from-multiple-snmp-community-strings/), so could be used for that or for updating any property.

Caveats:

This script updates exactly one property. If you wanted to update multiple properties, you could clone the DS for each, or you could adapt the script to loop over multiple properties. If you do the clone route, note that the clones will not all run at the same time, so if you're trying to update a username and a password, that's going to leave a mismatch for a period. Also, we have a proper, in-platform, credentials vault integration on the way anyway.

v1.2: 3C2PMM

 

  • Hi Antony,

    Thanks for this.  I have been doing this sort of API device updating via datasource for some time now, and it is definitely not ideal.  With propertysources only running once every 24 hours ?, there is definitely a huge need for collectors to be able to natively and dynamically update device properties when it needs to do so. I've been digging into some of the Java methods available under the hood on the collectors and I believe I have found a workaround. Here's the relevant snippet of groovy code:

    import com.santaba.agent.debugger.*
    
    println "Updating property: system.${LMObj} :: OldValue: ${hostProps.get("system.${LMObj}")} :: NewValue: ${currentObj}"
    task = "!hostproperty action=add host=${hostProps.get("system.hostName")} property=${LMObj} value=${currentObj}"
    HostPropertyTask updater = new HostPropertyTask(task)
    updater.run()
    println updater.output
    return updater.exitCode

     

    As you can see, I'm manually calling on the collector to run the !hostproperty debug command in order to update the property (I know. sneaky, eh?).  I'm still watching to see if this gives me any trouble, but so far it appears to be working far better and faster than the API method I was using previously.  Of course, any updates to the collectors might break this functionality, but hopefully by then we will see a native hostProps.set() method instead.

    cheers!

  • NB. Remember this calls the API to make any necessary changes. If you make 1,000 clones to change 1,000 properties on 1,000 devices once every minute, you will crash into API rate limiting and things won't work as expected.

    Be sensible with deployment and update time intervals. Your ship is not moving that far every minute...

  • Hi Antony
    I have made some minor changes. The API Key I have included directly in the script. I was trying to read out via snmp the location at oid .1.3.6.1.2.1.1.6.0 but when I've tried to get the systemname automatically from the hostProps.get('system.hostname') it did not work and the script failed. Any hint on this? 

    P.S. I would like to have the custom properties field snmp.location filled with the value from the snmp request for all of our 723 snmp devices... So I can't have 723 variations of this script with the IP fix coded in it ?

    Thanks for any hint on this

     

  • Hi @Christian Schneider, I don't see an immediate reason that would fail.

    Feel free to email me the details of the device(s) you're testing against and the link to the modified datasource, and I'll be happy to take a quick look, if you wish.

    :)/emoticons/smile@2x.png 2x" title=":)" width="20" />