Vitor Santos

Members
  • Content Count

    110
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Vitor Santos

  1. Nope, those aren't discoverable. They're set manually by us (client status, domain in our ticketing tool, etc...)
  2. Hello, We've several instance groups within the same DS (Ping, URL, etc...). Some of those profiles need to have common properties (per instance group) due to the integration we've with our ticketing system for example. It would be GREAT if we could add properties at the Instance Group level (that way those would be inherited by the instances & we don't need to be mapping those individually per instance). I tried that & didn't found that possibility... correct me if I'm being noob Thank you!
  3. Gotcha! I guess for what we want here that's not good (since AD runs every 15 minutes)... Thank you for the help anyway Stuart!
  4. I see but, it would reappear if the Instance gets discovered again but, not actually alarm is the process stops (since the instance disappears), right? Since the AD will no longer consider it an instance (when it stops). Maybe I'm doing some confusion
  5. I searched on the Exchange & the one from LM but didn't found metrics related with it (maybe I missed something )
  6. Hello, Just wondering if anyone developed DS to monitoring Exchange DAG so far? That monitoring is really important on our current tool... If not, I guess we can develop one but, prior to that I just wanna make sure there's nothing out there already. Thank you in advance!
  7. Yeah, I really think that's the most reliable option to pursuit. However, I've coded a DS just to see how it behaves (WinProcessStats_Responsiveness). Just in case you want to have a look. Only problem I'm having with that DS is that I don't have Active Discovery erasing the Instances (therefore they'll stay there alarming if that process is no longer running - which is kind of what we want but, not perpetually). This is why we're really leaning towards just expecting a number of process & alarm if it's lower that that.
  8. Yeah I looked into your example but, that has the PID as wild value. That's exactly the tricky part of this. Cause nowadays our probe is able to catch those processes (even with same name) & alarm if those get stopped. I just don't know how to replicate this at LM. Was wondering if anyone might come up with a workaround that I'm not actually seeing. I've tried to come up with something that has the cmdline & then enumerating those as cmdline#1/#2 etc... but, if now there's 3 instances of the process running but later there's only 2... the third instance will return an alarm (ca
  9. Hello, In our current monitoring tool we monitoring Linux processe profiles using a Regex expression to match one or more. Example, we've a profile that will look into processes that contain /.*OpswiseAgent.*/ in their cmdline path. Once those are running, the probe picks them automatically and monitors their state (not actually having the PID in mind because that might change). In LM we would also not rely on PID since it might change (in terms of wildvalue).There can be also more that 1 process (with diff PIDs) running with the same exact cmdline (therefore it needs to pick tho
  10. Thank you for the feedback. Is there any planning on implementing similar feature on the collector(s) page? Cause it's really annoying having to scroll up/down and/or changing page in order to reach the collector we want. Thank you!
  11. Yeah I actually ran with those issue(s) but then noticed that we need to do additional things. Have the Powershell specific module installed at the collector level: Install-Module PSWinDocumentation.O365HealthService -Force (in my case there was some issue with TLS at the collector level so I had to run the command below prior to the module install -> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Enterprise Application needs to have the following role: I've also tweaked the script(s) actual token(s) being used on the c
  12. Also to add here... According to the documentation the user account roles should be: However, the DS below doesn't work only with those perms: I had the need to add the role 'SharePoint admin' in order to make it work Tried all the 'Reader' roles & none is able to make it work Is there any other way to have it working without the need to grant 'Admin' privs to the user in context? This is very important to us because we've clients that will not give us those type of privileges (100% sure). Please advise here folks. Regards,
  13. Hello, This is something we've noticed a while ago, but, only sharing now since I forgot in the meanwhile. When adding MS Office 365 env. into monitoring following the official documentation, at some point it's stated that one of the properties that should be set at the resource level is: I've done this but, the property source for Office365Reports category fails when running (prop. source details below): The actual error states the 'tenant name' in context doesn't exist. This gets solved if instead of using the tenant name we pass the tenant ID instead. Jus
  14. Hello, Starting a few weeks ago we've lost the functionality of dynamic filtering Collectors using the search box (top right corner). I mean, we can still search collector(s) but, the results actually display ALL the collector group(s) anyway... This is kind of annoying & not that useful since we've >100 groups. I know this was working smoothly in the past, not entirely sure why it got removed (maybe there's an explanation but, I don't recall seeing that published on the Release Notes - correct me if I'm wrong ). Thank you!
  15. Hello, I've created a suite for Tegile API monitoring a few weeks ago. One of the DS captures the events for the Tegile Event table (using the API), maybe that's useful to you since you don't need to configure any event source, traps, etc... I've been trying to publish those in the exchange but, for some reason my page always stays stuck at the loading phase (I've already tried in diff. browsers but, it doesn't work). Use those at your own risk (in case they're helpful to you) since those weren't approved by LM 'officially'. In order to use them you just need to map the prop
  16. Maybe it's easier for you to use one the already existent datasource(s) that queries Cisco Meraki API & from there build the query you actually want You can refer to the code of the DS below for example: This is usually what I do if I want to extend the capabilities of certain monitoring... I always check if they didn't did the 'connection' already. That way I don't need to loose time understanding how to do it
  17. If you've one simple datapoint per each phase (phase1, phase2, phase3) then you can just create a complex one & sum the 3 simples ones (quick example below): I would say that does the trick for you! Regards,
  18. Not sure if it helps you but, I had a similar issue ( might not be you case ) & I replaced the actual DNS name with the actual IP (on the resource level itself), it worked for me. See if that helps as well.
  19. This is actually useful. One of our SQL engineers requested something similar (only worried about TDE certs for SQL boxes) & we ended up using this logic to accomplish that. I actually had to tweak the 'timeToExpire' since it was returning a negative value (for certificates that are yet to expire). Since we'll want to use a < 30 30 15 (or similar) threshold, we had to revert the result(s). Published it to my GitHub -> HERE Regards,
  20. I have updated the actual DS.. Realized that it wasn't getting data from the actual endpoint in context. I was running PS commands locally (so it was always retrieving data from the Collector ). I've re-wrote it in order to use 'Invoke-Command' & this way it seems to be getting data for each device in context. Updated the GitHub repo
  21. Updated the actual code since the task ExitCode was being output as Decimal & it's easier to present it as HEX on the actual alarm message. To accomplish that, I've added a function that makes use of LM API & maps a custom property at the instance level (this way we can then reference it in the actual alarm message -> converted to HEX). Hope it's useful for anyone
  22. Hello folks, We had a request from a client where he had the need to monitor some important scheduled task(s). While checking the documentation, we wanted to avoid the procedure on the actual 'Job Monitor' for scheduled tasks (since the clients is kind of harsh when it comes to make changes in their boxes, even if those represent no harm). Since we were only interested in the actual task return code (after its run), we've done a quick DS (powershell). Just sharing it here in case it's useful for anyone. GitHub repo -> Here For now, we're alarming on the actual task r
  23. Yeah, this is a feature that our teams are used (from our prev. tools). It was something they really insisted to have. Hope it works smoothly Thanks anyway Stuart!
  24. Hello, I was able to surpass this by making API requests on the script itself (by update custom properties at the instance level directly). We now have 2 properties at the instance level (ResourceState & ResourceConfiguration). From there every time the script runs updates both properties with the respective values. On the alarm message I'm now able to invoke those tokens (##ResourceState##, etc...) & reflect the values. Thank you!