Vitor Santos

Members
  • Content Count

    160
  • Joined

  • Last visited

  • Days Won

    33

Community Reputation

105 Excellent

5 Followers

About Vitor Santos

  • Rank
    Thought Leader

Recent Profile Visitors

337 profile views
  1. I'll reply to your email (will include our CSM as well for his awareness). Thanks!
  2. Well yeah, I could argue that as an enterprise user that could cause issues as well but, you got my point 🙂 I agree if this doesn't get solved, then have an alternative solution. Exactly like you stated would suffice (at least it would give us the option to choose what happens).
  3. As an MSP we use netscan & expert mode all the time. That's not in question, however, we've a lot of persons using LM & sometimes 'Wizard' is used to add 1 device or so instead of 'Expert'. This is a bug & should be fixed... Regardless if we're an MSP or no, it doesn't make sense to populate the properties of a certain device on the root group... I'm also missing the use case for this logic, are you aware of it? This is just my opinion though. We rarely use the Wizard (myself, I don't use it all), however, I can't control our users. We already brought this to everyone atte
  4. Hello, We already raised this but, it was a while ago & it didn't got fixed yet. When adding device(s) via 'Wizard' option, properties that are set for the device will appear on the ROOT group as well (independent of the group we assign that device to). This is very concerning & doesn't make any sense. Is there any ETA for this to be fixed? Doesn't make sense to add a device (with properties at its level) & then map those properties on the ROOT level (making all the SUB groups inheriting it - as an MSP that represents DOZENS of clients that have nothing to do with ea
  5. Yeah, this is a HUGE LACK of feature. This is common sense & needed. We should be able to see if the device/instance/etc was in SDT whenever the specific alert got triggered. For tshoot purposes is very helpful. Like @DanB said, we don't care about if it's on SDT at the time at all, that's silly LOL. We can see it right away on the GUI logo, no need to have a column on that. We've already brought this to our CSM as well, lets see if it gets to dev ears.
  6. There should be a field for the syslog time then, or include it in the message itself. But the actual alert date should be the time it hit LM (because that's the actual time where we received the notification - not 4/5 hours ahead of the REAL time in the portal).
  7. We've a Trap server in our environment & all our clients send Traps into it. The problem is that it belongs to our old solution architecture (which we like a lot) but, they'll be shutdown soon. Our upper management wants to get rid of those & all the VPN tunnels we've from our DCs to our clients infra (which allowed us to send Traps to a single spot). That's why we're ultimately leveraging a workaround for the stuff we still need to rely on Traps. Never mind, I think we just found a solution. We'll receive the duplicated Traps on LM, set the ES to clear them every 5 minutes (
  8. Yes, I found a tool this morning that does that. Was able to create a config source that accommodates our needs, however, that represent a LOT of manual work in each collector. Which isn't a optimal solution. We were wondering if there's a property that we can set on the collector config for it to dump the received traps within a certain log file. I'll poke support about it. Thanks anyway @Stuart Weenig!
  9. @Stuart Weenig, do you know if there's any way to dump the traps received by the LM collector into a .txt file or something?
  10. We're talking about client infra which we don't manage. Regardless of what's the optimal procedure, we should be able to control that on the tool end. Doesn't make sense to have an alert start date other than the time it actually hit the tool.
  11. I totally agree with you, if possible use SNMP or some other retrieval method. However, there are certain very specific metrics/conditions that are only available with Traps/Syslogs.
  12. This is really an handicap to us. The device in question is a Cisco FMC, which doesn't pass the time zone attribute in the syslog timestamp format. Since it's located in a different time zone, we get alarms in a 'future' date once they hit LM. This is causing the syslog suppression not to work properly unfortunately.
  13. That's a fact! But, we should be able to dictate which severity it gets mapped within LM (in case we don't have the LM Logs feature).
  14. That would be great! Thank you for the possible 'warm' notice 🙂