Vitor Santos

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Vitor Santos

  1. 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
  2. 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,
  3. 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.
  4. 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,
  5. 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
  6. 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
  7. 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
  8. 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!
  9. 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!
  10. I appreciate your suggestion, however, it doesn't suit our case. The complex datapoint is being used to trigger the actual severity of the problem. In case it's a resource fault we want it critical, if it's only config we'll want error instead. However, the status that we would like to pass on the message itself can have a lot of values (from the simple datapoint itself). It can be 1,2,3,4,5,6,7,etc... In sum, we've 2 simple data points that can have multiple values (where >2 isn't healthy). But 1 overrides the other (in terms of the issue itself). That's why we came up wit
  11. Hello, We've a complex 'datapoint' on a DS that will alarm based on different 'simple datapoint' values. We've the 'resource actual state' & 'resource configuration state' datapoints & we'll throw a 'Critical' alarm if the 'resource actual state' == 1 , but, in case it's equal to 0 we'll observe the 'resource configuration state' and throw an 'Error' alarm if it's ==1. This is useful for us, because we can have a resource that's online but, facing configuration issues. Our goal is retrieve both those simple 'datapoint' values in the actual alarm message itself (on the co
  12. This would be really nice to have. We struggle on this, specially on Dynamic Groups that might contain devices (due to the previous category) that no longer should be there.
  13. We were able to surpass this by tweaking the way the output gets processed (on the groovy script): snmpGet = new SNMPCollector()._convertTime(Snmp.get(host, community, version, oid)); This was found by the user MNagel - thanks a lot man! From there I've tweaked our DS in order to add context/support to SNMPv3. Bear in mind that in order to use SNMPv3 (in this STP context) the user/group needs to have view for the 'vlan-' context (tested this only at Cisco devices for now). Found this on post below:
  14. I was checking on this & we were able to come up with a script that analyzes different VLAN(s) - using the actual VLAN context. I believe it's working as intended, however, the actual output of the snmp.get (on the TCN OID - . it's being automatically converted into a readable date (which I don't want, I want the RAW value in ticks). Example of how it's been printed within LM groovy: If I do a get on the same exact OID (outside of LM) it'll output the actual raw value (in time ticks) - example below This is the script I've so far (I just need to s
  15. Thank you Stuart. I'll share this post with our CSM. Regards,
  16. About the API capabilities, just to add my thoughts to Stuart reply (which you should adopt in first place).I was requested to develop a few scripts that make use of LM. There's some features that aren't documented but, you can make use of your browser programmer tools in order to actually see the different API requests (on the GUI). That helped me a lot & I was able to code some calls that weren't documented (even making use of API v3). Bear in mind those aren't supported by LM but, they might help you if you've urgent needs (like they helped me). Thank you!
  17. Do I need to submit a feature request? Or what's the proper action here (since I already have this post)?
  18. Your logic is exactly what we want. To sum, exclude just one event (for a certain period only) & don't affect the others on the same ES. We could do that (creating 1 ES just for that event), however, this is something that we do really often (for our diverse clients). That's not an optimal solution for us in terms of monitoring management, otherwise, we'll need to be creating separate ES all the time (whenever a client requests it for a certain event - which happens often). We actually can do this in our Alert Console (since our LM is sending all the alarms to our SNOW instance),
  19. Hello everyone, We've multiple Event Sources setup (each one of them covers multiple events (different sources & event IDs). They're kinda in the same category but they cover different events (example Backup Related Events - within those there's multiple applications, event IDs, etc...). Our question here comes if we need to filter a specific event (within one of those Event Sources) on a specific period of the day. For example, ServerA is returning some events at 2AM EST but those are related with a scheduled job that occurs daily, one of our clients requested us to filter tho
  20. This is very useful. Thank you for this!
  21. In the past I also had that need & what I ended up using (from debug console) was !aplist & !apdetail commands. !aplist -> refer to help !aplist for further info This will return a list of the tasks ran against different hosts (on the collector context). From there, you can extract the task ID: With that ID you can run the !apdetail <id Here> & it'll return you the details of that run (if it discovered new props, failed, etc...) Not pasting all the info here since it contains sensitive info for us. Related with the time it ran I didn't found
  22. Yeah, just confirmed and that works. Passed the actual collector on the wild value of the !posh script context and it rebooted as expected Example command -> shutdown /r /f /t 0
  23. Hello Stuart, I was able to query the API on past Monday. Went further and developed all the DataSources we need (to mimic the SNMP monitoring). I would like to publish those into exchange but I'm not quite sure how. Tried to publish those into my repository but the window just keeps stuck on the loading phase for one of the DS. Perhaps you could give me some advise on how to do that. Those might be helpful for another folks or even for you guys to review it.
  24. Just a thought, you could extract those properties from API response & map those into the discovered instances (as auto.* props) - example auto.service auto.currentstatus etc... From there you could map the ones you feel important & if generating an alarm you could invoke those same properties on the alarm custom message itself (it could be useful) - example Service '##auto.service##' is degraded.... Not sure if it makes sense to you. Just suggesting it because I did it this way a few days ago when creating a DS that reads from the device Event Fault table (I
  25. Ok, I finished the datasources we need & I believe it looks nice. Deployed those within all the Tegile devices & it seems to work nice. I was trying to create a package out of those (to further deploy it within Exchange) but, Exchange seems to be weird today. I can't even commit those to our rep. Anyone else facing issues?