• 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 fi
  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-p
  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 $li
  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
  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?