Doubts

3 minutes ago, maxwell said:

LogicMonitor’s Version2 API cannot be used for which of the following tasks
updating netscan
ensuring consistency during customer implementations
creating role groups
automating tedious and repetitive tasks.

Take a peek at the v2 API documentation. The idea of using the API to do management is all about consistency. Note that we're asking which cannot be done with v2 of the API.

5 minutes ago, maxwell said:

What is the most convenient way to save a complex AppliesTo expression for frequent reuse?
Add the AppliesTo expression to an Ops note so you can copy and paste it as needed
Add the AppliesTo expression to a new Default Message Template
Save the AppliesTo expression as a property at the root level of your device tree
Go to Settings > AppliesTo Functions and click the Add button to create a new AppliesTo Function
My Answer:Save the AppliesTo expression as a property at the root level of your device tree

Check out this support article: https://www.logicmonitor.com/support/logicmodules/functions

6 minutes ago, maxwell said:

If an alert rule has *ABCD*|*PQRS/* specified in the Group field of an alert rule, alerts from resources in which of the following groups would match? Select all correct answers.
/Customers/ABCD/Routers
/Customers/Test PQRS/Network
/Customers/PQRS/Linux
/Customers/ABCD
/Customers/PQRS
/Device by Type/Linux
Not sure

The star * is a wildcard and the pipe | is the OR operator. 

11 minutes ago, Stuart Weenig said:

Take a peek at the v2 API documentation. The idea of using the API to do management is all about consistency. Note that we're asking which cannot be done with v2 of the API.

Check out this support article: https://www.logicmonitor.com/support/logicmodules/functions

The star * is a wildcard and the pipe | is the OR operator. 

Thanks you, still i am not clear with third one

15 hours ago, maxwell said:

Thanks you, still i am not clear with third one

About the API capabilities, just to add my thoughts to Stuart reply (which you should adopt in first place).I was requested to develop a few scripts that make use of LM. There's some features that aren't documented but, you can make use of your browser programmer tools in order to actually see the different API requests (on the GUI). That helped me a lot & I was able to code some calls that weren't documented (even making use of API v3).

Bear in mind those aren't supported by LM but, they might help you if you've urgent needs (like they helped me).

Thank you!

On 9/3/2020 at 4:59 AM, Vitor Santos said:

 

About the API capabilities, just to add my thoughts to Stuart reply (which you should adopt in first place).I was requested to develop a few scripts that make use of LM. There's some features that aren't documented but, you can make use of your browser programmer tools in order to actually see the different API requests (on the GUI). That helped me a lot & I was able to code some calls that weren't documented (even making use of API v3).

Bear in mind those aren't supported by LM but, they might help you if you've urgent needs (like they helped me).

Thank you!

I have done the same often, with marking those as v3 in our API library module.

As far as some of the original discussion, what might help is building out consistent dynamic groups within each customer, which is how we have approached this problem.  Then it is always something like Customers/XXX/Automatic Groups/Linux Servers, etc.  The input to the script is an array formatted like:

    {
        group => 'Windows Servers',
        appliesTo => 'isClient%s() && isWindows()',
    },

The key in this is to setup an Applies To function that allows you to identify the client, then we can create the dynamic groups for each client via this script.  We currently run it manually for each specific client, but it would not be that much harder to automatically run it for all clients in a loop.  We use the preferred collector naming scheme (which has triggered problems because apparently some things are not recalculated when changes happen like a collector replacement, but we are basically hosed if that does not work since you can't use properties).  The meat of each of those functions (*) is "system.prefcollectordesc =~ "\\.domain$" and we organize clients into specific domain structures for the collector descriptions.

Note: we use Perl for most of our API automation and I have been shunned a few times in these forums for it, but I don't care :).  The one time I got mad was when someone in dev claimed my API result was not going to be looked at because Perl not supported. Really.

(*) I have a hard time calling something a function that does not support parameters.  In this case, we could have one actual function with the client name as a parameter and life would be even simpler.