Search the Community

Showing results for tags 'Instances'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • From LogicMonitor
    • General Announcements
    • LM Staff Contributions
    • Community Events
  • LogicMonitor Product Discussion
    • Feature Requests
    • LM Exchange
    • Ask the Community

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 9 results

  1. Hi Throwing something out there for advice. There are a number of datasources that are subject to duplication of instance because you cannot safely turn on the automatically delete as legitimate instances may go down for longer than 30 days. This appears to be due to them being very dependent on the instance name, so if this is something the customer has the ability to change then it creates another instance during Active Discovery. My question is if anyone has an ideas on a complex datapoint (or some other means) that can detect that this instance has matching property to another instance. This could be say auto.device.mac_address or even the Instance Value as these always match between the duplicate instances. This is really bugging me now so I really need to find a proactive way to address them. The real downside is that you lose the historical data when it is actually the same device. What the ideal would be is if you could merge instance or at least delete the new and rename the old one to the new ones name so its not discovered again.
  2. This is not an advertisement by any means, just offering to help anyone who struggles with this as well. As an MSP, we have struggled with how to handle alert tuning in bulk with it comes to things like Interfaces (instances). Some of the interfaces you want to alarm as critical, some you want as error and others you don't care about at all. LM provided a partial fix for that with their Groovy based "Status" alarm based on the interface description, but it didn't take it far enough. We started creating manual interface groups called "Critical" and performing Alert Tuning on that "parent" only to find out that it doesn't work as interfaces move in and out of it. I was beyond disappointed, but it said it right at the top of the page: Changes made to Alerting or Thresholds will only affect existing instances currently in this Instance Group. Instances added later will not be subject to the changes. Anyway, long story short we finally decided to write our own application to do it and built it in Azure. We built it to handle multiple data sources so we could group other instances (like VMware vDisks) and do the same bulk changes. It was written to be a data source in your environment, so that you can apply it to whatever devices you want and just call out to the API with the device name. If you have any interest in using it, let me know. There are costs associated as Azure bills based on usage, but it is pretty small for us (< $200/mo). Trust me, I wish LM solved this without having to write the app!
  3. Hello, We would like to have the possibility of group interface instance(s) [from different devices/clients]. As an MSP we have the need of creating common thresholds for certain types of interfaces we want to group, reports, dashboards, etc... Within LM we aren't able to group instances from multiple devices/clients. Can this be implemented? Regards,
  4. I'm trying to clean up datasources that are in our account that do not have any instances associated with them and likely never will. Currently I have to do this manually by inspecting each datasource in the GUI. It would be really great if the datasource instance count was returned as a property. Even better would be if the instances and associated device ID's were returned as well, but for now I'd be happy with just the device/instance counts.
  5. We have several clustered devices where metrics are gathered on each node. However, the instances across each node are identical. When attempting to graph this data, this means that I would need to add a new datapoint for each instance and use a glob pattern to select the devices from which to pull those instances. This can mean that a lot of time goes into creating these graphs if there are several instances to monitor. Examples: Three Solr nodes - each servicing search requests for the same 10 collections. In order to see the total number of GET requests for each of those collections, I would need to create a graph that has 10 individual datapoints. Instead, I would like to add one datapoint and have the graph intelligently aggregate all instances that have the same name, regardless of the node. Several device groups exist under a parent group. If I want to see the average CPU utilization across each of these groups on a single graph, I would need to add a separate datapoint for each group. A potential solution could be to allow the integration of regex instead of glob patterns to allow for capture groups. Otherwise a simple checkbox for "aggregate instances by device group" and "aggregate instances by instance names" when selecting aggregated graph types would be extremely useful and time-saving.
  6. Hello, We'd like to request some more usage for instance groups. Right now, it's just not very useful to group instances on a datasource. We have shared devices with datasources belonging to different teams and we have to create dashboards and alarm rules regarding those. Right now, we have to use the wildcard filter in a "creative" way to have shared device alerts and dashboards from different teams configured. It would be really helpful if the instance-group name could be used in Filters. Use-Case: * To configure alert rules for shared devices for different teams, we can group all datasource-instances in instance groups named "teamname" and then filter on "teamname", this works even when we use "*" for device/devicegroup, as long as instancegroup "teamname" is persistent over multiple shared devices. * To have dashboards for shared devices on a per-team base, we can filter for the teamname when creating those dashboards. This also works with "*" as device/devicegroup query, so instances on new devices will be added automatically. Regards, Bastian
  7. Anyone know how to pull a list of ALL devices (1000s) with instances reporting "No Data" via the REST API? Thanks as always!
  8. My problem is pretty simple. I have 10,000 USB hard drives sitting close to one of my servers. Every 5 or so minutes we have a robotic hand attached to a robotic arm, which is attached by USB if that's important, that unplugs a random number of the USB drives that are connected to the system, there are only 16 USB ports after all, and it then plugs new USB drives into each of the now vacant USB ports. So what ends up happening here is that upon an autodiscover new instances are created for each of these new drives that have been attached to the system. These instances inherit their alert tuning from the datasource. In this case that is snmpHRDisk-. At the time of this writing snmpHRDisk- is a datasource associated with 158 hosts. If I change the settings to satisfy this host's alert tuning, applies to or filters these apply to all hosts. Changing the alert tuning to satisfy this host's needs virtually disables alerting on all hosts. Changing the filters might cause us to miss a similar naming scheme on another host. So far the best option at present seems to be duplicating the datasource, which we did, then changing the applies to in the main datasource. When I went to change the applies to I've so far managed to associate the datasource to all 1000+ of our hosts, no hosts, only the two hosts, etc... I think the best solution to my problem is the ability to simply disable a datasource at the device level and/or allow alert tuning to be set on the parent of the instances in the device so that new instances will inherit their settings from the device and not global and/or allow new instances to be added to a predefined instance group with alert tuning. There may be different ways to skin a cat but disallowing me from skinning the cat on moral grounds is just immoral. But this one wasn't intelligent. He blew all his money on lottery tickets!
  9. I would love to see the "ESX VM" datasource allow grouping its instances by the VDC/Resource Pool in which each VM is contained. Use case: Each VDC in our infrastructure may have different alerting rules. We have many VDCs and most of these VDCs are available directly to customers through vcloud director, allowing them to create their own VMs using names over which we have no control (so we can't use the automated name filters to group them). Customers may add a new VM at any time within their own VDC and they have the option to expand out at will without notifying us. Currently, grouping VMs by their VDC in LogicMonitor is a manual process which gets outdated everytime a new VM is created - which is at least daily. As a workaround, if the LogicMonitor APIs allowed a way to create instance groups and add instances to those groups, we could script this out and just add new VMs into the appropriate groups as the scripts detect that they have been added into the environment, however, it appears that this functionality doesn't exist in the API either.