Troy Felix

LogicMonitor Staff
  • Posts

  • Joined

  • Last visited


0 Neutral

About Troy Felix

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Jhana, It would be very unusual for simple SNMP Get queries to crash the SNMP service. I would suggest confirming that the firmware on the ZS5-2 array is current, reviewing the logs on the device and reaching out to our Support Engineers if needed. Best, -Troy
  2. Hi Ether, Yes, there is a more targeted way to turn off only Status and Status Flaps for specific interfaces that you've added to an Instance Group. If you create an Instance Group under your main Interfaces, then add the interfaces for which you want to disable Status and Status Flap monitoring to that Instance Group. Then, go to Alert Tuning on that new Instance Group and uncheck Status and Status Flap to disable just that monitoring on those interfaces. Hope this helps! -Troy
  3. Hi Jnana, Happy to help you out here, what specifically is going on with your ZFS monitoring? Thanks, -Troy
  4. Hi Tom, One of my colleagues recently wrote an SNMP DataSource which queries the Netscaler AAA Statistics to track the three security features of authentication, authorization, and auditing. Specifically, ICA session and connection metrics, along with authentication successes and failures. If you can provide me with your LogicMonitor account, I will get this DataSource added for you. Cheers, -Troy
  5. Hi Tom, We have robust DataSources around Netscaler and applicable session metrics. Along with giving LogicMonitor the appropriate SNMP Community string, make sure you configure your Netscaler to allow SNMP requests from the LogicMonitor Collector. Regards, -Troy
  6. Hi Ivan, We are pulling the Status and Status Flap metrics via SNMP directly from the device. It is unlikely that these are false positives. Status Flap and Status alerts are common for access switches where you have users turning their machines off and on, unplugging when leaving for the day, connecting/disconnecting mobile devices, etc. For these situations, we suggest creating an Instance Group and adding the appropriate 'user access' interfaces to the group. Then turning off Status and Status Flap monitoring for that Instance Group. The interfaces that are important, trunk ports, VLANs, Uplinks, etc will continue to be fully monitored. Regards, -Troy
  7. Hi Pandiyan, With the flexibility of dashboards and widgets, one approach to your use case is to create a Dashboard Called "Router Utilization". Then using the Text Widget, create a "Router A" then build out the various utilization widgets(CPU, Memory, Bandwidth, etc) under "Router A". Then on this dashboard, repeat for "Router B", "Router C", etc. Please let me know if this answers your question. Thanks, -Troy
  8. Hi Ryan, You should be able to edit system.categories values so I'm not sure what is going on there. Is your user granted the full Administrator role? Since other existing DataSources and potential future DataSources might need these system,categories values, I would suggest a different approach here. If you don't want to see certain DataSources, then I would instead use the "Applies To" within those DataSources to fine tune to which devices/groups/etc, if any, they are applied to: Please let us know if you have any questions. Thank you, -Troy
  9. Hello Thangadurai, First, we highly recommend that you configure a "Collector Down" escalation chain to associate with the "Collector Down Notification" on the Collector itself. This will alert you(via email, sms, or phone call) to loss of collector connectivity to the LM cloud. If you want to see this in a dashboard, then I would suggest creating an "Alert List" widget, filtering on just the collector device and by severity of critical which will show you any critical level issue with the collector device. Regards, -Troy
  10. There currently is no "show associated dashboards/widgets" capability similar to "show associated devices" for DataSources. However, you can see DataSources associated with individual Widgets via the REST API. (As shown using a Python script in Example 3) Another possibility to avoid this, if feasible, would be to modify the existing DataSource, rather than creating a new DataSource or cloning an existing DataSource. Feel free to submit a feature request via the Feedback option in your LogicMonitor portal to address this capability.