LogicMonitor PowerShell module

BTW - as I continue to test it seems like the typical pipe approach is a bit different in that I need to continue to provide credentials (which is fine).  What's a bit more interesting is to try and get a list of all device properties in one object/array).  It seems like first I can get all devices (using Get-LogicMonitorDevices), but the device properties are an array... so I then use Get-LogicMonitorDeviceProperties against the previous list to expand those properties).  However, as you can guess since it runs line by line there is no longer a single array to act against.  Perhaps there is a better approach with your module commands? 

Just FYI - my goal is to update AWS device names with the tag value... so my plan was to export a list of all devices, identify those where the AWS tag name is not null and also where LM display name does not match the AWS tag name and then update the LM display name with the AWS tag name data.

I was able to get this figured out and used the following to update the LM display names with the AWS system tag and only when the AWS tag is present.  I could use a way to better handle errors when LM finds a duplicate or when there are invalid characters in the tag, but it does the job:

#Get AWS devices with name tag set (not null)
$aws=Get-LogicMonitorDevices -AccessId $lmid -AccessKey $lmkey -AccountName $lmacct | select id,displayName,systemProperties | where {$_.systemProperties -like "*system.aws.tag.name*"}

#Build list of devices including ID, LM Display Name, and AWS Tag Name
$list = @()

foreach ($device in $aws) {
	$item = New-Object psobject 
	$item | Add-Member -type NoteProperty -Name 'id' -Value $device.id
	$item | Add-Member -type NoteProperty -Name 'displayName' -Value $device.displayName
	$item | Add-Member -type NoteProperty -Name 'awsTag' -Value (Get-LogicMonitorDeviceProperties -AccessId $lmid -AccessKey $lmkey -AccountName $lmacct -DeviceId $device.id | select name,value | where {($_.name -eq "system.aws.tag.Name")} | select value) 
	$list += $item
}

#Create list of objects to update where the display name does not currently equal the AWS tag name.
$update=$list | where {$_.displayName -ne $_.awsTag.value}

#Process Update
foreach ($item in $update) {Update-LogicMonitorDeviceProperties -AccessId $lmid -AccessKey $lmkey -AccountName $lmacct -DeviceId $item.id -PropertyNames displayName -PropertyValues $item.awsTag.value}

Minor update - we found it was better to only do this for EC2 since for other devices it made it a bit harder to find things.  I've updated the script above with the following on the third line (right after the $aws= line):

$ec2=$aws | Select-Object | where {$_.systemProperties.value -eq "AWS/EC2"}

Then update the foreach loop to use $ec2 instead of $aws and you will only update EC2 devices.

On 9/9/2017 at 10:37 PM, mhashemi said:

I have published a PowerShell module, which refactors part of the REST API, to the PowerShell gallery. Please feel free to make requests (or send me cmdlets you want added).

 

https://www.powershellgallery.com/packages/LogicMonitor/

Mike - Any interest in collaborating to build this out further?  

What did you have in mind?

As of April 19th, you'll want to add the following line at the top of the psm1 file OR any script that uses this module:

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

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.

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. 

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.