LogicMonitor PowerShell module
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).
mhashemi
Posted 9 years ago·Last reply 6 years ago
25 comments
mhashemi
OP6 years agoCan you put the device in SDT in the portal? What version of the module are you using?
LM User
·6 years agoIt 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.
andrewk
·6 years ago@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.
mhashemi
OP8 years agoI 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.
Joe_Tran
·8 years agoThere 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.
mhashemi
OP8 years agoSounds 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.
Joe_Tran
·8 years agoNo worries. This is my first time contributing to a public project
.
And yes, I did test it
.
Verbose output using current:
Verbose output using PR:
In current, the REST API will only take the first json-object ({"collectorGroupId": "3"} in my example) and ignore the rest.
mhashemi
OP8 years agoThanks 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.
Joe_Tran
·8 years agoI 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.
mhashemi
OP8 years agoYup, I forgot to upload 1.0.0.17 when I made the TLS change. That's done now.
Joe_Tran
·8 years agoAs 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:
mhashemi
OP8 years agoWhat did you have in mind?
PatrickATL
·8 years agoMike - Any interest in collaborating to build this out further?
S_P
·8 years agoMinor 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):
Then update the foreach loop to use $ec2 instead of $aws and you will only update EC2 devices.
S_P
·8 years agoI 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:
S_P
·8 years agoBTW - 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.
S_P
·8 years agoThank you very much for the response. You are right, it does work if I change the case. Interestingly if I don't have the proper case, the command still says successful but I guess in the backend it's really not. I will go ahead and make sure to use that case for the display name and will need to see how I can verify the case for other properties if/when the issue comes up. Any way to catch that in error handling? Thanks again for creating this though - it's something the product badly needed.
mhashemi
OP8 years agoOh, you don't need the hash table. When I run with the property capitalization, the cmdlet works fine. For "display name", you need to use "displayName".
mhashemi
OP8 years agoYour experience is interesting, because I update the displayName property of our new collectors several times a week. In the script we use to deploy collectors, I use the following code:
If you put the displayName property into a hash table like I did, do you have the same problem?
I'll try to find some time to create the other cmdlet you suggested.
S_P
·8 years ago@mhashemi I looked at the verbose output of your command and it actually it looks like the issue is that you are using the PATCH method which only allows updating of custom properties. If you were to change this to a PUT and instead use the path for properties, it would allow any property to be updated.
https://www.logicmonitor.com/support/rest-api-developers-guide/devices/update-device-properties/
S_P
·8 years ago@mhashemi also, just FYI (though I don't need to use it at the moment) Get-LogicMonitorServiceProperties does not seem to work for me. I would also think a nice compliment to this would be a new Update-LogicMonitorServiceProperties cmdlet (if you get time for it)... though the first issue I mentioned I would think is more valuable to me. Thanks in advance!
S_P
·8 years ago@mhashemi thank you for creating this. One question/issue.... should Update-LogicMonitorDeviceProperties support updating any system properties? I tried to use this to update system.displayname and though the command says successful, nothing is changed. In addition if I do system.foo, it says it works but actually doesn't. However, any other property name (e.g. foo.system) works fine. There is something about system.X properties that the update cmdlet (or API) doesn't seem to like. Thoughts?
PatrickATL
·8 years agoThank you for this!
Kerry DeVilbiss
·9 years ago@mhashemi Impressive work - thanks for sharing!
Andrey_Kitsen
·9 years ago@mhashemi awesome stuff !