jakemontgomery

Members
  • Posts

    5
  • Joined

  • Last visited

  • Days Won

    1

Reputation

3 Neutral

About jakemontgomery

  • Rank
    Member
    Member
  1. Just chiming in to say this is a highly desired feature, even 4 years later. I'm running into some limitations with my custom alerting integration and this would be the most simple solution to fix it.
  2. Currently I am unable to set LM to alert if I receive the same or similar SNMP Trap or Syslogs within a specific timeframe. It would be an incredible feature if we could aggregate logs that match a specific string, then graph and alert based on volume and delta of volume. Almost as if to hybridize the EventSources into special DataSources.
  3. There are devices with no alerts beyond warning for "No Data" that are monitored primarily off of SNMP polling. I have discovered a device in which SNMP hasn't been functioning with SNMP for months and it has major implications for us. We really could use a "SNMP Troubleshooter" that functions much like the vendor specific troubleshooters that already exist. To name one specifically, the VMware_LM_Troubleshooter. I'm honestly a little worried of how many devices will end up triggering from this once it's enabled, but it would be a great tool to ensure we are monitoring what we are expecting to be monitored.
  4. I've been spinning my wheels on this same idea. Without having dug into the depths that are MIBs, I'm thinking it might be worth running an expect script to gather the port channel interface assignments directly from the devices. Then each port channel becomes its own instance group, and each interface assigned (and the portchannel interface) become instances within the group. The idea is plausible, but my problem doesnt demand the time-cost to build it out. I figured I'd share it here encase it helps anyone else in the future.