Leaderboard

Popular Content

Showing content with the highest reputation since 04/11/2021 in Posts

  1. While investigating an incident we had, looking at the Alerts Tab while in Resources View, there is a column that is called: "In SDT" which turns out is useless. It just means "is the devices currently, at this very moment, in a SDT window" and not if the alerts you are looking at, which may or may not have already cleared occurred while the device was in a SDT window. This would make so much more sense and be actually useful if this column indicated that. I don't care if the device is currently IN a SDT state, I can tell that from looking at its icon in the tree b/c it has the clock icon ove
    7 points
  2. 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
    3 points
  3. This is a DataSource that enables you to update any single custom property on any collector-monitored resource. Example use case / how this came to be: Let's imagine for a moment that you have a collection of monitored resources on a mobile piece of kit, for example a sea-going vessel. One of those resources is a GPS locator device, out of which you can retrieve latitude and longitude values, and you'd like to use those to populate the 'location' property for the resource in LogicMonitor, such that your various vessel locations can be shown on a LogicMonitor dashboard. This Data
    2 points
  4. The thinking behind this is for enterprise customers, not MSP. If you are an enterprise and you're adding one device, more than likely you'll be adding other devices. Storing the creds at the root level makes sense on an enterprise level, especially if you are depending on the Wizard to help you with your deployment. I agree that it should be fixed. Perhaps just a checkbox in the wizard that says, "Save these credentials for future use" that defaults to unchecked.
    2 points
  5. There is a way to do this, but it is not well-documented and there is no UI exposure for "No Data" alerts, you have to dig around the module sources to find them (because it is very hard to put an indicator in the alert tuning thresholds I guess). We have standard alerts on 2 datapoints that have No Data alerts and no other alerts. The first is for "Host Uptime" -> SNMP_HostUptime_Singleton -> Uptime and the second is for Uptime- -> * -> UpTime. If a host stops responding to SNMP, those will trigger. We keep them near the end of our alert policy to generally report to our
    2 points
  6. You could create a single instance SNMP DS polling sysuptime (1.3.6.1.2.1.1.3.0) and put a no data threshold on that.
    2 points
  7. Sure, you can use Service Insight for this, but it is a premium feature, which is using an expensive mallet to handle something that should be available without that extra cost. Or, there should be a Service Insight light for this stuff, leaving the costly part for the intended enhanced features of Service Insight (like Kubernetes). My recommendation on this was to extend cluster alerts so you could at least match up instances. My use case at the time was to detect an AP offline on a controller cluster. There is no way to do this without SI, which as you say is complex, and it is an ex
    1 point
  8. You could create a service out of those two links. The service metric would be interface status. You would choose to aggregate the status data by "mean". If both links are up, they'd both return 1, so the average would be 1. If one link is down, you'd get the average of 1 and 2 (1.5). If both links are down, you'd average 2 and 2 (2). Set your threshold to >=2 and you should be good to go. The only tedious part is setting this up for each pair of links you have.
    1 point
  9. I've updated the script to reflect changes made since the original post. It now includes more examples for handling different alerts (including restarting a Windows service) and a helper function for forwarding syslogs if needed. Heaven forbid you ever get such an alert storm, but I tested triggering 500 alerts/minute to see if the script could handle them all and it successfully processed all of them within a second of the collector performing its regular 60-second External Alerting check. For reference, the test was simply logging each alert to a file using the script's LogWrite functio
    1 point
  10. Hello, my name is Ryan Albert Donovan, Senior Product Managers here at LM. If either of you have some time this week I'd love to have a brief call to better understand the issue or see it recreated. Both myself and my developers haven't been able to reproduce in-house. If not a screen cap of the issue would suffice. Let me know if this work four either of you. Ryan
    1 point
  11. Here's one i did long ago. I recently rebuilt it to be an SSH based DS, which is also in that repo.
    1 point
  12. What i cannot tell you yet would make you very happy.
    1 point
  13. Better quality images are definitely needed there. However, I recommend against extending snmp. It's messy, performance is not great, and requires stuff on the remote side to work. Better to use Expect or JSch scripted DSs. I've a couple of examples I can link when I get back to the office in a few minutes.
    1 point
  14. Two things: 1. It would be amazing if the user building the report could add custom headers to the reports such as custom properties they have assigned to groups/resources. 2. It would be amazing to add the ## DPDESCRIPTION ## token as a header in this report.
    1 point
  15. This actually answers an issue I've been having to correct in our portal. We are also an MSP and monitor client gear. However, we also monitor all of our internal devices via LM as well. We have all our internal roles and permissions separated out to only allow users to see their respective folder structure. However, we needed to be able to allow some users to create dynamic groups, which means we have to give them manage access to the root of the portal. Which, I understand but it would be nice if users could create dynamic folders and it was aware of their permissions and would filter out wh
    1 point
  16. This is something we've also brought up with LM a few times. It seems that LM doesn't track SDT state along with the alert itself. This also makes alert reports difficult to review since we can't filter out alerts that occurred during SDT for the same reason.
    1 point
  17. This is sort of happening now. The "Use dashboard time range to filter alerts" is checked in your screenshot. If this is checked, alerts outside the dashboard's timeframe are hidden. If the dashboard doesn't have a timeframe set, the default is 24 hours. Agreed this could be improved.
    1 point
  18. 1. I feel 'Unmonitored Devices' should be named, 'Unmonitored Resources'. 2. More important - It would be really nice if you could view more then 25 resources at a time, filterning through hundreds if not thousands of resources is very time consuming and challenging. It would be really cool to be able to select how many resources are displayed on a page at a time, like 25, 50,100,250,500 or something like that. Another really cool idea would be to have a check box to say 'show all'. Thanks!
    1 point
  19. Yes, or the platform (resource) may have started life as part of another group and then the business service was changed (application services separated out to different platforms), resulting in a new group to reflect the new architecture of the business service.
    1 point
  20. Found a question in "ask the community" here re: CW Config Record attachments from about 3 years back. CW Config records are essentially the configuration records within CW Manage that track issue, and ticket history for a given device. This data becomes useful when trying to analyze which devices and systems an operator is spending too much time on, and aids in identification of candidates for configuration changes or replacement. We can manually assign configurations to tickets that are routed to our integration, but it would remove one more potential for user error if we could aut
    1 point
  21. Are any of you capturing installed programs on your Windows servers and if so how? I've been asked to look at a way to get this information but don't want to query win32_product. I also can't use Powershell due to our collector configurations and the various clients we have on them(The prerequisites to get powershell working cross domain with trusted hosts etc. is just not feasible)
    1 point
  22. There are a couple methods that could probably work on most every Linux distro. Neither work via SNMP as far as I'm aware, without some additional modification. Luckily, it wouldn't take much to create a PropertySource that can determine this and set a custom property. The PropertySource would use SSH. I whipped this together this morning. Give it a shot. It sets a property called "auto.chassis". It'll be "vm" for a virtual linux machine. It'll be "desktop" or something else for a non-virtual machine.
    1 point
  23. Not sure if you have the same need I had on my organization but, we've developed a simple DS a while ago that fetches some power related metrics. You can find it here Not sure if it helps you out. Thanks!
    1 point
  24. Late to the party (sorry, new to LM itself) but just wondering if any further consideration/progress was made on this feature request? I recently added a Cisco FMC trap in LM. And what would have been a single alarm in our old NMS has generated over 1100 alerts (so far).
    1 point
  25. It would be useful to have SNMP traps that trigger within a specific timeframe to be considered the same alert. We have a few cases where devices start throwing traps every minute and by the time we react to fix we already have dozens of alerts. It would be better to consider the same trap within a time frame to be the same alert to avoid this alert flood.
    1 point
  26. BUMPing.. We are learning of this now as we are starting to implement LM and this is horrible. There has to be a solution for this? Why does LM not correlate the same event and just increase the count of that same alert/trap on the Alert Console? We don't need 1000 different alerts that all pertain to the same event/trap.
    1 point
  27. SYSLOG is another where we have this issue. We have received 1000s of duplicate alerts in the span of minutes. We had to create special escalation chains just to throttle it properly when it does it.
    1 point
  28. Reviving an old thread, but we're currently reevaluating EventSource suppression logic. Some of the other EventSource types already use a timeout like mechanism to avoid duplicates, but we don't do anything like that for SNMP traps. The general idea right now is to let the user decide which duplicate fields indicate a duplicate event, and suppress anything within the "effective interval" of the original alert. I think it makes sense to have the timer reset logic be optional. I also like the idea of providing more visibility on how many events were suppressed. We've also had a fair num
    1 point
  29. That's a very good point. we do have the same problems with Windows events and likely any other event types supported. It comes down to handling asynchronous event technologies differently that accommodates the nature of those event types to be handled well by a NOC or IT team.
    1 point
  30. I like the time out idea and would like to have that applied not just to SNMP trap event sources but to all event sources. A similar thing can happen with Windows event logs where an event log repeats but is actually the same incident.
    1 point
  31. All, I've logged this product improvement/feature request and referenced this forum post for additional information.
    1 point
  32. Right on Jeff and Eric. We like Barracuda and need a solution where LM takes 1 or 100 traps of same event source criteria and understands it is one problem and not 20 separate problems. Anyone out there been able to solve another way? If not, can we get as Jeff suggests?
    1 point
  33. I completely agree with this. Different vendors use TRAPs differently and from my experience may send the same trap multiple times, sometimes several times a minute or more even. The TRAP functionality in LogicMonitor will not be useable in these cases because the noise it will create will be a huge distraction for any NOC to be able to handle. It takes their eyes off of other possibly critical events because of multiple duplicate alerts for the same issue. Let's take Barracuda for instance. Their NextGen Firewalls have a TRAP for HA Partner Unreachable. We received a trap every 5 min
    1 point