Vitor Santos

Members
  • Content Count

    119
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by Vitor Santos

  1. This look really nice. Does it still looks to 'not real-time' data from MS? I know there was a limitation in terms of data that API parses (since it was getting data indeed but, not real-time).
  2. Hello Michael, Thanks for you reply! I was able to do it in the meanwhile (started reading the documentation and trying out on Groovy) & ended up getting it. I'm working on trying to do the same monitoring (via API) that we're currently doing using SNMP (there's some limitations but, I believe we can do it). I'll post here my data sources once I've finished them (in order for you guys to view/correct/make use of).
  3. To start with I was looking for already existent data sources. Just wanted to understand if someone already had something, otherwise, I understand that will need to do it from scratch.
  4. Hello, I've been searching for Datasources related with Spanning Tree Protocol monitoring but didn't found one. Does this mean there's no out-of-box datasources for STP monitoring? This is extremly useful in terms of monitoring. Appreciate the feedback.
  5. From what I've read apparently it's mainly HTTP gets (replies in JSON 🙂) My issue is on creating a Groovy script for that (Java its not my thing). Thank you!
  6. Hello, We're monitoring a lot of Tegile device(s) via SNMP (making use of the OOB datasources, however, those fail quite often). This is happening for the majority of our clients & after our NOC opened a case with Tegile directly (they stated there's a bug when using SNMP on the MGMT IP). Having that in mind, I started leveraging the possibility of using Tegile API instead of SNMP. Searched through the Exchange but found none developed yet. My idea would be replace the SNMP with API ones. I've found their documentation about API calls but, actually requires some help to
  7. Hello, We're monitoring a lot of Tegile device(s) via SNMP (making use of the OOB datasources, however, those fail quite often). This is happening for the majority of our clients & after our NOC opened a case with Tegile directly (they stated there's a bug when using SNMP on the MGMT IP). Having that in mind, I started leveraging the possibility of using Tegile API instead of SNMP. Searched through the Exchange but found none developed yet. My idea would be replace the SNMP with API ones.I've found their documentation about API calls but, actually requires some help to pu
  8. It works smoothly! Just concerned with the load on the collectors (once we add a quite big expression) - Lets see how it goes Thanks a lot for you help Stuart!
  9. Nice to hear that! We'll start mapping our stuff & see if it works. Using a sample event (that I can trigger on purpose) in order to test this out. Will further update
  10. I've further checked the event table on the device itself & the date isn't the same (obviously ). I've raised a support case #208119 to engage support. Thank you for the availability!!!
  11. No problem!!! Ok I think I got that, within the 'Application' log we've multiple filters where we want to fetch events from multiple different sources & for each of those sources only grab specific IDs. Example (just using two events we get from the Application events): Both of those events fall into the 'Application' logs but contain different sources & different IDs per source. From looking into the Event Source definition I'm able to pass the Source(s) & ID(s) but, in a separate way: This will not restrict those IDs to the actual Source(s). Bu
  12. Ok so I've ran the groovy script in Debug console & tweaked it like this: It returned this: I see the first event is good & its no longer getting triggered because it already passed. However the second event still display the data wrongly & LM it triggering that alarm every 60 minutes (but duplicated) The event date I guess it could be a bug at the device (I'm thinking on raise a case with support anyway). However, related with the duplicated alarm, do you have any idea why?
  13. Okay... still kinda lost lol Can you provide an example?
  14. Hello, We've noticed the out of the box event source 'Liebert_Condition_Events' is triggering alarm where the actual date of the event is in the future (example below): NOTE: Blurred the device name (in order to protect our client information) I've already accessed the device in question & the system time is correct. Could this be an issue with the data source 'timestamp' handling? Or there's another thing that I might be missing? Thank you!
  15. Hello, Nowadays, we are migrating from CA IM to Logic Monitor platform, when it comes to the event logs monitoring we've some doubts on how to replicate those. Currently at IM we pick what we want to monitor (by creating profiles that look into the Severity, Source, ID, Message, etc...). I do understand this is possible within LM but, from what I checked it would require us to create a different event source every time the source changes (& we are talking about >100 variations). With that in mind, using that method we would create a huge load on the collectors, correct (due
  16. Currently, we have some clients that want to monitor several certificates on a box (example -> IIS server). Not only the server cert itself like 'SSLCerts-' does. From this thread it seems this does the trick right? If yes, is it possible for you to share this DS? Thank you!
  17. Got it. I'll differ this internally, because this could be an issue for us. We've clients that don't give us ICMP access on purpose (but then we've SNMP access). Thank you for the info!
  18. Ok, so I ended up doing it like this: - if(eq(snmpDown,1),2,if(un(upTime),0,1)) It does the trick, thank you! I've disabled the SNMP on the device (to force the condition), however, LM doesn't see that device as dead. What's exactly needed for LM to consider the 'Device Dead'? It relies on ICMP as well?
  19. Basically I want to do what the PeerDown expression currently does: Only if the snmpDown == 0, else, return 2 (or something != than 0)
  20. Ok so I've added that try, except on the actual script. So it pretty much returns 0 if the SNMP portion goes well & returns 1 if it catches the timeout exception. Just added the actual SNMP walk code into the try{} & added the one below as catch() So now we're able to know if SNMP isn't working. I'm kinda lost on what to do at the 'PeerDown' datapoint (in terms of expressions). Can you help? Never used the complex datapoint features before.
  21. After checking the OIDs I don't believe the upTime can tell that difference. I'll try to leverage that 'general' change & see if it works for us. That's a great idea! Basically we could just add a new complex datapoint (via groovy) & try to poll a basic OID. If it doesn't return data, then assume snmp isn't replying (snmpDown == 1). From there just tweak the actual PeerDown to actually have that value in mind before returning 0. Am I in the right path? Or you had something more simple in mind? Thank you anyway for the input on this !
  22. Hello, We've noticed the Cisco EIGRP PeerDown alarm(s) aren't being suppressed if the actual device goes down on LM. When lost SNMP connectivity to one of our routers, it started returning PeerDown alarms (since SNMP wasn't responding, causing the 'NoData' condition at the 'upTime' datapoint). This becomes an issue because the actual datapoint that checks the Peer status, bases itself on the data retrieved by the 'upTime' datapoint (which at this point, is as 'NoData). Basically, if the 'upTime' doesn't return data (which happens if the actual device goes down) it'll trigge
  23. Hello Michael, Actually the legacy SNMP datasource(s) cover pretty much everything we need in terms of the UCS C Series stuff (hardware, temperature, power consumption, etc...). I've re-applied those only to UCS C stuff by tweaking the AppliesTo. Therefore, I don't think there's a need of developing new ones.
  24. So after reading the UCS monitoring article I found that we need to actually add the Manager & Fabrics (making use of the API keys for those). However, it requires a few tweaks on the data sources part in order to avoid duplicated monitoring. Since the 'sysinfo' on the UCS stuff contains 'NX-OS' it grabs a bunch of extra stuff (that we actually don't require for UCS because those are already monitored via the new data sources suite). The solution for us was tweaking all those data sources 'appliesTo' in order to remain the same & not get applied if the condition below is true.
  25. Hello, Now that a new suite of data sources is available for the UCS stuff, we're having some doubts on the monitoring related with the Cisco UCS Manager & their respective components (Fabric Interconnects, etc...) I'm sure the new suite removes the need of the SNMP legacy datasources (that's great btw!!!), however, we're now kinda lost on what should we add into LM (in terms of components). I'm pretty sure in the past we had to add the UCS Manager + the Fabric Interconnect devices (to fetch some hardware related info that wasn't fetched via UCS Manager), but currently, I see t