Forum Discussion

MikeTaney's avatar
MikeTaney
7 years ago

Allow multiple selection across instances pages

When LogicMonitor discovers Cisco switches and other network devices, there are often numerous interfaces that are monitored, when they should not be.  Think about a 4507 chassis with 80% user ports that we don't want to look at, but 10 access point and 2 uplinks that we do.  

Right now when going into instances for the a device and editing interfaces and trying to disable multiple selections, you can only do this within the page you are on.  If you select say 10 interfaces from a page, then hit next page and select 10 more, only the 10 from the page you are currently on get disabled.  This is adding significant time to my cleanup of things auto-discovered, and should be an simple and great enhancement!  -Thanks

cisco
interfaces
network

2 Replies

Sort By
Replies have been turned off for this discussion
  • Nick's avatar
    Nick
    7 years ago

    We had this issue as well, unfortunately, with multiple customers and network devices we do not have the luxury of having the same naming conventions or that interfaces are even given descriptions. So we flipped this around cloned/edited the datasource so that it displays all interfaces by default, no matter the status and have removed alert thresholds at this level. we then work with the customer/consultants to obtain a list of interfaces of interest per device, invariably this is just a handful of interfaces that need alert thresholds setting at the local level.

    Just another way of looking at it/getting around this :)/emoticons/smile@2x.png 2x" title=":)" width="20">

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    7 years ago

    Yes, it is truly annoying and really got my clients mad until I devised a solution using policy-driven API script.  The policy is defined by a few properties that indicate which ports should be monitored and which should have alerts set (we base this on the interface description).  I run it hourly, but it could be run as frequently as desired.  I find more and more that LM is not really awesome at real-life monitoring requirements out of the box (e.g., stuff like this or the fact that ACKs are permanent, etc.), but thankfully the API is flexible enough to make it do the right thing!  Here are my internal notes on the interface monitoring script:

    Device Properties

    Edit section

    The device properties leveraged to define which interfaces have monitoring or alerting active are as follows:

    Property Value Purpose
    wm.intf.desc.alert regular expression enable alerting if desc matches RE
    wm.intf.desc.noalert regular expression disable alerting if desc matches RE
    wm.intf.desc.monitor regular expression enable monitoring if desc matches RE
    wm.intf.desc.nomonitor regular expression disable monitoring if desc matches RE
    wm.intf.email.label email addresses (comma-separated) send change notice to all in-scope email addresses

     

    The logic applied to matching the interface description is alert then noalert and monitor then nomonitor.  Any in-scope property can be set to the word null to cause the property to be ignored at that inheritance level.

    For email, the idea is that each level can introduce a new and additive set of targets, hence the label.  If only a single 'default' label is used, then each layer defines the overall set of email targets to be notified about port changes.

    The default values for these properties (defined in the root of the device tree) are:

    Property Value
    wm.intf.desc.alert .+
    wm.intf.desc.noalert ^#
    wm.intf.desc.monitor .*

     

    In English, this means:

    • monitor all ports
    • alert on any port that has a label, except if that port's label begins with a '#' symbol

     

    Regards,
    Mark