ErnieC

Members
  • Content count

    14
  • Joined

  • Last visited

  • Days Won

    3

Community Reputation

5 Neutral

About ErnieC

  • Rank
    Community Whiz Kid
  1. SOLR JVM Stats (non-JMX)

    Was this released to the public?
  2. Apache solr monitoring

    Hey guys, been a few years. Any update on this?
  3. Currently, a service alert has the following limitation: ##CHECKPOINT## - the checkpoint associated with the alert (this value will be 'Overall' if the alert was triggered based on the checks at multiple locations) There is no way to show the failing one, only the number of failures. It would be nice to have the collector (or multiple collectors) name included in the alert. Currently, you need to go to the service check and refer to a graph. Not helpful with email/texts I have posted something similar in the past about External Collectors, but internal ones would be useful -
  4. Dynamic Tables (dashboard widget)

    Glad to see this was released in v99. We will be playing with it over the next few weeks. Thanks!
  5. Dynamic Tables (dashboard widget)

    Fantastic, thank you for the update!
  6. Dynamic Tables (dashboard widget)

    @Ali Holmes that is a good start, although I was told the same thing last November by my account manager. It's been almost a year and no progress has been made and this is still being spec'd out? I also kinda agree with @mnagel - there shouldn't be a problem just NaN'ing the "bad" cell in the table. Doing one is a good start, but let's not be content with just that. For what it's worth, you can kind of "ghetto" this up already with a line chart. The data and logic is already baked in, just displayed as a point on a graph over time, instead of the most recent datapoint.
  7. SDT for minor alerts

    Couldn't you on a per-device or per-device-group basis set the specific Datasource/Instance for a recurring SDT? So you're not SDT'ing the entire device, just the "benign instance" during hours you specify.
  8. Currently, a service alert has the following limitation: ##CHECKPOINT## - the checkpoint associated with the alert (this value will be 'Overall' if the alert was triggered based on the checks at multiple locations) There is no way to show the failing one, only the number of failures. It would be nice to have the collector (or multiple collectors) name included in the alert. Currently, you need to go to the service check and refer to a graph. Not helpful with email/texts
  9. Currently, a table must have static columns and rows defined before the widget will display data. It would be great to be able to dynamically build a table's rows based on * To expand on this, it would be great for the table to have the option to exclude instances with zero/no data from the list. For example, I would like a table that displays all MSMQ queue names and the number of messages in each queue - but not display anything if the current queue length = 0
  10. Sample Rate Increase

    Would appreciate this as well - even if it is limited to Network Devices vs Web Services vs VM/Physical Devices.
  11. From a product view, it should be something that is optional, but maybe presented at time of removal? In other words, ask me "do you want to archive this device" when I go to delete it. As for archival retention, I think that should be related to the service level you're paying for. I believe the difference between LogicMonitor Standard and Pro (or whatever the tiers are called) is 1 year vs 2 year data retention. I don't see why that should change.
  12. Dashboard local times

    Per-user TZ and DST settings would be great! Correlation between other services not monitored by LM is difficult (think of DevOps team working independent of Networking Team, correlating timestamps of mismatched logs)
  13. Customize severity colors

    Would greatly appreciate this. To take it one step further, the orange and red colors used for severity sometimes resemble each other on cheaper displays or monitors - the icon is the only way to truly tell what level alert it is at.
  14. There are times where a user may want a legacy device's data retained in LogicMonitor for performance tuning and comparisons. If you remove a device, it also removes all associated data, making historical reporting impossible (unless you export the raw data, which is a pain in the neck). It would be great to be able to "archive" a device, automatically removing it from Collector queries and alerts. It would also be great for the device to no longer count against your device license limit, but I understand why this may be problematic (the data still exists, taking up storage). Currently, the only way to mimic this is to disable alerting and collection and drag the device to a separate folder. However, a Collector still must be defined, which I imagine is a waste of resources (invalid WMI calls, SNMP failures, etc).