REST API GET Filtering

Yes @Cole McDonald - you can just update that field with a PATCH request & data collection tasks should immediately start being scheduled with the new collector

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?

See the a href="https://communities.logicmonitor.com/topic/2163-add-device-to-collector-with-least-devices-in-rest-api" rel="">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.

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/

9 minutes ago, Mike Moniz said:

See the a href="https://communities.logicmonitor.com/topic/2163-add-device-to-collector-with-least-devices-in-rest-api" rel="">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.

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.

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.

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