• 0
Cole McDonald

REST API GET Filtering

Question

I'm attempting to retrieve a list of devices assigned to a specific collector.  I can't find any solid documentation for the queryParams portion of the URL.  I'm currently working on this:

$fromHost = <returned collector from previous commands; id is a field stored therein with the [int] ID of the collector>

$resourcePath = "/device/devices?filter=collectorid=$($fromHost.id)"

How do I need to alter this to make it work correctly... or where is the documentation for the query options?

Share this post


Link to post
Share on other sites

18 answers to this question

Recommended Posts

  • 0

Is there a list of which properties are immutable?  Here's the list I'm working with currently (some names have been changed to protect the innocent) :

type    name                            value                                    
----    ----                            -----                                    
system  system.collector                false                                    
system  system.collectordesc            *******                 
system  system.collectorid              6                                        
system  system.collectorplatform        windows                                  
system  system.collectorversion         28002                                    
system  system.deviceGroupId            174,12,5                                 
system  system.deviceId                 2092                                     
system  system.devicetype               0                                        
system  system.displayname              *******                            
system  system.domain                   <domain>.local                          
system  system.enablenetflow            false                                    
system  system.groups                   <company>/Data Center - MN,Devices...
system  system.hostname                 *******                               
system  system.ips                      *******                               
system  system.model                    PowerEdge R610                           
system  system.netscaninfo              Discovered by Collector (id=5) via Net...
system  system.prefcollectordesc        <domain>\<collector name>                 
system  system.prefcollectorid          6                                        
system  system.resourceCreatedOn        1548440971                               
system  system.staticgroups             <company>/Data Center - MN           
system  system.sysinfo                  Microsoft Windows Server 2008 R2 Enter...
system  system.sysname                  *******                          
system  system.systemtype               x64-based PC                             
system  system.totalphysicalmemory      119.99GB                                 

I'm trying to force a device to move to a different Collector.  Since the Collectors don't seem to know which devices are looking at them, I'm assuming the change has to be made on the device itself...  I have everything working on my simplified autobalancer except for the payload. (the built in autobalancing collector groups don't seem to work yet).  Here's what I've got for the payload:

$resourcePath = "/device/devices/$($toMove.id)"
$data         = @"
{
    `"Name`"             : `"<system name>`" ,
    `"systemProperties`" : [
        {
            `"type`"  : `"system`"      ,
            `"name`"  : `"system.collectorid`" ,
            `"value`" : `"5`"
        },
        {
            `"type`"  : `"system`"      ,
            `"name`"  : `"system.prefcollectorid`" ,
            `"value`" : `"5`"
        }
    ]
}
"@

# Make Request
$response           = Send-Request  `
    -company          $company      `
    -accessid         $accessID     `
    -accesskey        $accessKey    `
    -resourcePath     $resourcePath `
    -data             $data         `
    -httpVerb         "PATCH"

It doesn't complain about the request... but doesn't make any changes.

Edited by Cole McDonald

Share this post


Link to post
Share on other sites
  • 0

@Cole McDonald all system properties are read only, except system.categories (idea being they are set by the "system" - LM). But many of those system properties are set based on the device attributes that you can configure directly, e.g. displayName, preferredCollectorId, etc.

Share this post


Link to post
Share on other sites
  • 0

Specifically, what mechanism do we use when LM gets it wrong?  I'm not going to manually change potentially hundreds of items.  And as the centerpiece to our business, we can't afford to have our monitoring get it wrong.

Share this post


Link to post
Share on other sites
  • 0

Is there some API where we do have access to those fields?  If I start coding out java modules for our implementation needs will I be able to access those fields and alter them?

Share this post


Link to post
Share on other sites
  • 0

I guess for the purposes of this thread, my question is... what is the correct, LM approved method for forcing a device to move to a different collector?

Share this post


Link to post
Share on other sites
  • 0

I'll give it a shot.  I'm at the finish line with my autobalancer simplification script.  It only considers # of Devices / Collector.  The current metrics based decisions don't seem to be working for our environment well.  We're ending up with a lopsided balance of about 40/60... so one of the collectors is always being taxed more heavily.  I'm collecting all of the data to be able to move them based on instances, thread, or CPU load... or some combination thereof.

Are there object model diagrams available anywhere that define what fields are accessible and mutable per resource type?

Share this post


Link to post
Share on other sites
  • 0

See the other thread you have replied to about moving devices to different collectors where some code examples have been provided.

I think there are some confusions on how the LM system.x properties work. In most cases as mentioned these properties are read-only and are just reporting various information about a device or it's settings so they can be used for tokens and stuff in the GUI. For example system.collectordesc reports the name of the collector for a device. This is used if you wanted to report this in an Alert or Report, so you can use a ##system.collectordesc## token.

When you are working in the LM API, you don't even use these "property" values all that much. While they are called "properties" in LM don't think of them Object Properties in the programming sense. They are just a key-value array of information about a device. When using the API you have access to the "real" properties for a device or collector. So using PowerShell, if you want to get the the display name of a device you look at DeviceObj.displayName or get the the Collector's ID you look at DeviceObj.preferredCollectorId. You would also change these values by modifying these same object properties (in json).

system.categories being the one weird exception, but you don't normally modify this is API calls but using something like PropertySources.

One tip that might help you is that the LogicMonitor portal itself uses almost the same API. If you open your browser's development console (F12) you can actually watch how the website works and see the API calls and how the site does it. It might not be as efficient as your code might be (for example you can PATCH while the site would always use PUT). This might help atleast determine which APIs you need to research. 95% of the time if you can do it in the GUI you can do it via API, love that about LM.

I also suggest, imho, that you start off with the APIv1 documentation. APIv2 is very new and the documentation isn't as complete or described as fully as v1, especially if you are just looking at Swager automated documentation. Once you understand using the v1 docs, you can easily migrate it to v2 since it seems almost 1-to-1 matching.

 

Edited by Mike Moniz

Share this post


Link to post
Share on other sites
  • 0
28 minutes ago, Cole McDonald said:

Are there object model diagrams available anywhere that define what fields are accessible and mutable per resource type?

 

In the APIv1 docs, each section has a "About the X resource" section that has a table of all the object properties with description and type. The page for Devices for example is at: https://www.logicmonitor.com/support/rest-api-developers-guide/v1/devices/about-the-device-resource/

Edited by Mike Moniz

Share this post


Link to post
Share on other sites
  • 0
9 minutes ago, Mike Moniz said:

See the other thread you have replied to about moving devices to different collectors where some code examples have been provided.

I think there are some confusions on how the LM system.x properties work. In most cases as mentioned these properties are read-only and are just reporting various information about a device or it's settings so they can be used for tokens and stuff in the GUI. For example system.collectordesc reports the name of the collector for a device. This is used if you wanted to report this in an Alert or Report, so you can use a ##system.collectordesc## token.

When you are working in the LM API, you don't even use these "property" values all that much. While they are called "properties" in LM don't think of them Object Properties in the programming sense. They are just a key-value array of information about a device. When using the API you have access to the "real" properties for a device or collector. So using PowerShell, if you want to get the the display name of a device you look at DeviceObj.displayName or get the the Collector's ID you look at DeviceObj.preferredCollectorId. You would also change these values by modifying these same object properties (in json).

system.categories being the one weird exception, but you don't normally modify this is API calls but using something like PropertySources.

One tip that might help you is that the LogicMonitor portal itself uses almost the same API. If you open your browser's development console (F12) you can actually watch how the website works and see the API calls and how the site does it. It might not be as efficient as your code might be (for example you can PATCH while the site would always use PUT). This might help atleast determine which APIs you need to research. 95% of the time if you can do it in the GUI you can do it via API, love that about LM. 

I also suggest, imho, that you start off with the APIv1 documentation. APIv2 is very new and the documentation isn't as complete or described as fully as v1, especially if you are just looking at Swager automated documentation. Once you understand using the v1 docs, you can easily migrate it to v2 since it seems almost 1-to-1 matching. 

 

My first script was specifically using categories and may have made the forward movement more difficult.  I also always assume the GET (gotten?) properties should match the PUT properties for a given object.

The DeviceObj.* is something I haven't seen anywhere up to this point.  Is that the full nomenclature for the non-prefixed properties that I've been using up to this point?  That scope is very illuminating.  Thank you.

The advice to read through the V1 stuff first is a great piece of advice as everything up to this point has been , "we're on V2, ignore V1."  This may be the source of some of the frustration I've been feeling so far.

I'm going to go update my posts in the other thread... I'm this close _||_ to getting my autobalancer working.

Share this post


Link to post
Share on other sites
  • 0
9 minutes ago, Mike Moniz said:

 

In the APIv1 docs, each section has a "About the X resource" section that has a table of all the object properties with description and type. The page for Devices for example is at: https://www.logicmonitor.com/support/rest-api-developers-guide/v1/devices/about-the-device-resource/

 

I have read through that and was using it... but as it's not prefixed, I assumed they were the system.* ones that matched what I saw in the interface and in the returns from GET properties.

Share this post


Link to post
Share on other sites
  • 0
3 minutes ago, Cole McDonald said:

My first script was specifically using categories and may have made the forward movement more difficult.  I also always assume the GET (gotten?) properties should match the PUT properties for a given object.

It does, it's just that system properties as listed in the LM portal is not programming objects. They are more tokens used in the GUI. Agree that categories are the weird exception, I assume for legacy reasons.

Quote

The DeviceObj.* is something I haven't seen anywhere up to this point.

Sorry, forget that. I was just referring to how you can access the (real) object properties in Powershell. $DeviceObj = get-webrequest...; $DeviceObj.displayName.

Share this post


Link to post
Share on other sites
  • 0

ok... understood... now trying to figure out the expected JSON and I should be good. <fingers crossed - so normal programming>

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now