LogicMonitor PowerShell module

11 hours ago, andrewk said:

@mhashemi, 

Start-LogicMonitorDeviceSdt -AccessId $accessID -AccessKey $accessKey -AccountName $AccountName -Id <ID>
2020-06-30T22:29:48: Unexpected error starting SDT. To prevent errors, Start-LogicMonitorDeviceSdt will exit. PowerShell returned: The remote server returned an error: (403) Forbidden.

 

What perms do I need to set a SDT on a device? This is not working for me.

Can you put the device in SDT in the portal? What version of the module are you using?

It might not be permissions, but could be related to the version of the API you're calling. If you're looking to start/stop SDT, you might check these out as examples.

@mhashemi, 

Start-LogicMonitorDeviceSdt -AccessId $accessID -AccessKey $accessKey -AccountName $AccountName -Id <ID>
2020-06-30T22:29:48: Unexpected error starting SDT. To prevent errors, Start-LogicMonitorDeviceSdt will exit. PowerShell returned: The remote server returned an error: (403) Forbidden.

What perms do I need to set a SDT on a device? This is not working for me.

I took your changes to Update-LogicMonitorCollectorProperties and added them, along with support for PATCH and PUT in 1.0.0.29. I have to go on a trip, but if you wanted to look at updating Update-LogicMonitorDeviceProperties, that would be cool. :)/emoticons/smile@2x.png 2x" title=":)" width="20">

Device updating has a more complicated JSON structure based on whether or not you are updating custom or standard properties.

Either way, thanks for the help.

There is a default limit of 2 . I've been bitten by this one before and I have not encountered anything with LogicMonitor's REST API that goes much beyond 4, but better safe than sorry. 

Sounds good. Why did you limit the JSON depth to 6? Why define it at all?

Oh, you know what? Even though it isn't documented, I believe this part of the API supports the PATCH method (like devices). I was thinking of updating it to build the property/value pairs using the same code as is in the Update-LogicMonitorDeviceProperties cmdlet. As far as I can tell, it does not suffer from the same bug as you have pointed out here. Do you agree? I prefer PATCH over PUT because it is so easy to screw up when using PUT.

1 hour ago, mhashemi said:

This is my first open source project, so I'm not sure what the etiquette is, on accepting code changes. Did you test your changes in hotfix/update-lmcollectorproperties-data ? This is exciting.

No worries. This is my first time contributing to a public project . 

And yes, I did test it . 

Verbose output using current:

> $test_collector_details_update = Update-LogicMonitorCollectorProperties -AccessId $AccessId -AccessKey $AccessKey -AccountName $AccountName -CollectorId $CollectorName -PropertyNames collectorGroupId,escalatingChainId,description,resendIval -PropertyValues 3,1,'TestCollectorNewName',0 -Verbose
2018-07-18T17:32:36: Beginning Update-LogicMonitorCollectorProperties.
VERBOSE: 2018-07-18T17:32:36: Finished updating $resourcePath. The value is /setting/collectors/3.
VERBOSE: 2018-07-18T17:32:36: Finished updating $data. The value update is {"collectorGroupId":"3"}{"escalatingChainId":"1"}{"description":"TestCollectorNewName"}{"resendIval":"0"}.
VERBOSE: 2018-07-18T17:32:36: Executing the REST query.
VERBOSE: PUT https://accountname.logicmonitor.com/santaba/rest/setting/collectors/3 with -1-byte payload
VERBOSE: received 2137-byte response of content type application/json

Verbose output using PR:

> $test_collector_details_update = Update-LogicMonitorCollectorProperties -AccessId $AccessId -AccessKey $AccessKey -AccountName $AccountName -CollectorId $CollectorName -PropertyNames collectorGroupId,escalatingChainId,description,resendIval -PropertyValues 3,1,'TestCollectorNewName',0 -Verbose
2018-07-18T17:18:11: Beginning Update-LogicMonitorCollectorProperties.
VERBOSE: 2018-07-18T17:18:11: Finished updating $resourcePath. The value is /setting/collectors/3.
VERBOSE: 2018-07-18T17:18:11: Finished updating $data. The value update is {
    "description":  "TestCollectorNewName",
    "escalatingChainId":  "1",
    "resendIval":  "0",
    "collectorGroupId":  "3"
}.
VERBOSE: 2018-07-18T17:18:11: Executing the REST query.
VERBOSE: PUT https://accountname.logicmonitor.com/santaba/rest/setting/collectors/3 with -1-byte payload
VERBOSE: received 2123-byte response of content type application/json

In current, the REST API will only take the first json-object ({"collectorGroupId": "3"} in my example) and ignore the rest. 

Thanks for the input! I accepted your first one, for Add-EventLogSource. This is my first open source project, so I'm not sure what the etiquette is, on accepting code changes. Did you test your changes in hotfix/update-lmcollectorproperties-data ? This is exciting.

Yeah, I use psake to build the individual .ps1 files into the module, publish to PowerShellGallery, and push to GitHub.

I see that you've added this to Github . I've created two PRs to address issues I've been having with 1.0.0.26. I'm assuming the Public directory scripts are "bundled" when releases are created and uploaded to PowerShell Gallery. 

Yup, I forgot to upload 1.0.0.17 when I made the TLS change. That's done now.