• Content Count

  • Joined

  • Last visited

  • Days Won


Community Reputation

1 Neutral

About S P

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We need a way to be able to confirm what type of LogicMonitor license is being consumed by a given Resource or Website. Ideally there would be a system.license or similar property we can look at to be sure of the license type being counted for that resource. This would allow proper audit and chargeback to customers who are using the service as well as a way to validate total billing on our account. There must be some way you are counting these in order to bill us, so if this can be exposed as a property it would be helpful.
  2. @Chris Seiber - It looks like this is actually working despite the above now. I think the problem was I had some additional attributes set for Freshdesk that despite being supported by the API didn't seem to go through (which caused the entire update to fail). So I think I'm good now on this but do still think the HTML formatting I mentioned may be helpful to others.
  3. I've also just done a test to create a new escalation chain with only the ticket update integration on it, but no improvement. I get this for ##EXTERNALTICKETID##: Freshdesk - Create and Update Tickets : 20024 I will report back if I find anything new.
  4. Correction on the above - I do see that "id" can also work but results in the same thing. I was just going off of what I was aware of as "proper" path syntax... but in any case, it still seems to work that way. So, again, the main issue now seems to be the extra text added to the ##EXTERNALTICKETID## property which has nothing to do with the JSON response AFAIK.
  5. @Chris Seiber thanks for posting this. I have found a couple of things when setting this up and thought I'd share (and ask for feedback): 1. To properly format the message in the ticket you need to use HTML. In other words you need to use <br> instead of \n for a line break. 2. The JSON path you have doesn't seem valid. I was able to use $.id to get the ticket ID... however there is an issue with that (see below). When I get the ##EXTERNALTICKETID## it is coming back like this: Slack Integration : -1, Freshdesk - Create and Update Tickets : 20018 Where the first part before the colon are the display names of all integrations used on the alert (note the first one is for Slack and the second is for Freshdesk). If I only had the Freshdesk integration configured, it would likely say "Freshdesk - Create and Update Tickets". The part after the colon is the actual ticket number. Do you have any thoughts on how to strip off the first part? I know you support regular expressions but then that doesn't seem to be usable at teh same time as JSON for the ##EXTERNALTICKETID## mapping. Is this a bug in your software that is including this in the property to begin with given I don't see how we could possibly get those values (the integration labels) from the JSON response itself (I don't see them when I do a test).
  6. Any thoughts on making it possible to install a collector on a Raspberry Pi device? Has this been tested/tried since this feature request 4 years ago?
  7. 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.
  8. I’m not sure if your product group has this on their radar, but for AWS in particular it would be very useful to have a “keep display name in sync with AWS name tag” checkbox that is selected for AWS sync since it is possible for AWS names to get changed and no longer match what’s in LM. Azure doesn’t seem to have this problem (I don’t think Google would have this issue either). In order to deal with this, I ended up writing this script (which can be scheduled), but hopefully it can just be added to the product: https://communities.logicmonitor.com/topic/1525-logicmonitor-powershell-module/?tab=comments#comment-4385
  9. 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}
  10. 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.
  11. Thank 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.
  12. @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/
  13. @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!
  14. @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?