Popular Content

Showing content with the highest reputation since 01/23/2017 in all areas

  1. 2 points
    Hello, We currently use a third party (OpsGenie) for alerting, and currently we have a custom integration configured in LogicMonitor to send alert information to OpsGenie. Although there has been significant improvements to integrations over the past few months, one feature that lacks significantly for us is a supported two way integration between OpsGenie and LogicMonitor. This would be very similar to the partnership/integration that LogicMonitor has already built with PagerDuty. As LogicMonitor releases new integration features, it tends to break current workflows with alert creation in OpsGenie. A supported integration would give us more confidence that as LogicMonitor continues to release new features, that our alert functionality would continue to operate as expected.
  2. 1 point
    I know I've brought this up before, but I'd like to bring it up again. LM's requirement that collectors run as local admins (or system) is a GAPING security hole in your product. No amount of certificate signing, or other like security measures are a replacement for running a collector or an agent as a read only account. The fact is, with every security measure you take, if the collector is running as an admin account or a system account, its going to be exploitable in one way or another. Having the signed scripts and what not, would be great, but really it shouldn't be the primary focus IMO. Security is much better when its locked down by default and opened up as needed, compared to what you guys are doing, which is a completely open system, that you're trying to add security enhancements on top of. It's almost akin to you guys having no firewall,and then adding a few rules here an there to block certain types of traffic, while the rest of the network is completely exposed. A more prefered architecture (security wise) would be an agent / collector that can run as a read only account and be supported. WMI, perfmon, and many other functions all work fine with a regular user, when it's executed locally. That is why an agent or a special collector is needed. Most ideal communication path would be an "agent" talks to a "collector" which then talks to the portal. This would also allow us to keep our internet locked down. I suspect this would also have the other advantage of taking a lot of load off the collectors and really putting most of the work on the agent, which is ultimately better given that the workload would be distributed. For now though, even having a "supported" configuration for a collector not running as a local admin / system would be a great step in the right direction. The reason this is less of a concern for solution like Solarwinds and SCOM is they're on premises based solutions, meaning there is much lower external risk factor. You guys are cloud, and there for need to design the solution from an untrusted point of view.
  3. 1 point
    Also something we need from SNMP: From SNMP: System Name,Location,Contact,Model,Serial,Machine Type Added to the Information Tab of each Item, so we can collect it with the API.
  4. 1 point
    A modified version of ESX VM- to use a script based active discovery that also gives instance level properties. Uses Get-View to get data about the VMs and uses Get-VM as a fallback for those systems that don't support Get-View. This requires that you have VMware PowerCLI installed on the collector machines. I'll take another stab later to move this to groovy and utilize the built in Java API. Applies To: system.virtualization =~ "VMware" Name: ESX VM- RYD6DP
  5. 1 point
    Alert history is currently limited to only 30 days of data. This severely handicaps identification of false positives/negatives, the understanding of alert history and its implications across the organization, and severely limits the value of reports. Please increase alert and event retention to match the "Data Retention" length explicitly stated on LogicMonitor's official pricing page for a given plan. Thank you!
  6. 1 point
    Please update the documentation for the Script EventSource to include this boilerplate/sample code... Would have saved me a lot of research and debugging time :). import groovy.json.* def events = [events:[]]; if (condition) { events.events << [happenedOn:new Date(), severity:'error', message:errorMessage] } if (!events?.empty) { println new JsonBuilder(events).toString() } Thanks, Mark
  7. 1 point
    We have found cases where the default SNMP AD method is woefully inadequate (e.g., try to discover interfaces on a Cisco ISR4K with voice enabled; you will discover no interfaces and get no indication this has failed due to the full ifTable download taking way way too long). To workaround this, we plan to convert the interface AD to a script, but found the SNMP library provided does not support bulk operations (or they are undocumented). Can these please be added? If not, will look into something like http://btisystems.github.io/snmp-core/site/project-summary.html as an alternative via Grape. Not sure yet how well that handles SNMP version abstraction, which is a nice feature of the LM library. Ideally we could get the bulk operations included in the LM library. Thanks, Mark
  8. 1 point
    Please add a Settings option to allow users to set the colors for alert severities. This could be as simple as setting the CSS hex values/RGB values via a Settings UI. Reason is some people have color blindness and would prefer to select their own color values for severities.
  9. 1 point
    Please add an option to turn off the rows added to a CSV report (see below for example). A CSV file should be just that, a CSV file. I want to use the CSV to feed another process but having these rows means having to pre-process the file. Company: rentokilinitial From: 2017-01-13 19:56:43 GMT Powered By: LogicMonitor Inc. To: 2017-01-20 19:56:43 GMT Description: Router availability
  10. 1 point
    Would like to see a way to report on the dashboard, alert rule, etc dependencies on a device or device tree so that when reorganizing a device tree or moving devices we can anticipate the impact on dashboards, alert rules, etc and proactively address the impact rather than trying to find out where things broke after-the-fact because of the change. We've seen the API where we can programmatically some of this info (http://www.logicmonitor.com/support/rpc-api-developers-guide/manage-alerts/get-alerts/), but this doesn't address dashboards or device group dependencies.