Eric Feldhusen

  • Content Count

  • Joined

  • Last visited

  • Days Won


Community Reputation

2 Neutral

About Eric Feldhusen

  • Rank
    Community Member

Recent Profile Visitors

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

  1. The latest information we received from our Ruckus support representative based on the size of our Ruckus installation was to use the Ruckus Zone Director API instead of SNMP, because it's more performant and has more information. We've just started looking into the API and using a Groovy script to poll the Zone Director API for all the information, so we don't have anything useful yet.
  2. You can install Linux (Ubuntu) on those Intel Compute Sticks or use something slightly larger like a Udoo x86, which costs less than $100, and that can run several normal Linux distributions as well.
  3. As we expand pass 2600+ devices, and having to manually spread and adjust devices quantities over multiple collectors, a nice option to utilize our collector resources better would be the option to set the "Preferred Collector" for a device or group to be a "Collector Group" and then during device creation, the LogicMonitor backend logic just assigns each new device to the collector within the group to the collector with the lowest device count. It seems like a rough way to balance the collectors, but in our experience, that's how we're currently doing it and it's not the most perfect, but it has been working very well to allow the collectors to be utilized well, without causing Collector Task Count queuing, unavailable to schedule errors or failed active discoveries. Eric Feldhusen
  4. Ali, Thank you for your post and I will follow up with a direct email to you. Eric Feldhusen
  5. We really like the small/medium/large presents for the Collector templates, but we've noticed in our usage, that for us, there's two sets of additional Collector configuration changes we make based on whether the collector is doing primarily a large amount of purely snmp queries or if it's doing a large amount of pings and tcp pings to specific ports, so we have to "tailor" our collectors based on the devices in use on that collector. If it was possible for us to add to the LogicMonitor supplied Collector templates of small/medium/large with additional "templates" specific to our instance of LogicMonitor, it would make the collector deployments extremely fast. At the moment, we have to spend time after each collector installation doing large copy & paste of collector configuration templates. There are other ways to do this with configuration engines like Ansible, Chef, Puppet, but it makes sense to keep that type of information within the LM interface.
  6. We're a service provider that provide a managed service of LogicMonitor, so we have multiple customers within our single instance of LogicMonitor. As we expand, we have customers with devices in multiple timezones and from our experience, as we looked at it, our best suggestion would be for a user specific time zone setting, so that per user, they'd get the default time zone setting, unless they set their unique user setting for be another time zone, like PST, whereas we're in CST and that's what our instance is set for. Then, all time/date presented would just be in their set time zone across the board, so that they're seeing the information related to their set time zone, whether it's in an alert, graphing, or in dashboard(s). We've already had multiple customers ask about this, so I think it's a setting worth doing. Eric Feldhusen