Leaderboard


Popular Content

Showing content with the highest reputation since 03/22/2018 in all areas

  1. 5 points
    I would love to see LM implement a new feature for taking a built-in, self prescribed, action on an alert. To minimize any exposure that LM might have in an action gone awry, the actions taken could occur as the result of a script that one could upload into the Escalation Chain. Ideally you could define multiple actions or multiple retries on an action and whether that occurred before or after the recipient notification in the notification chain. This would allow for very basic alerts (disk, service restarts, etc) to be resolved programatically. Also being able to support various scripting languages such as PowerCLI, Ansible, etc would allow for some very creative ways to integrate with solutions such as VMWare or Ansible Tower for very complex actions to be crafted by more expert skill level folks.
  2. 4 points
    We've recently run into issues with users accidentally changing a setting or deleting a device and would like the ability to allow users to Create new devices, but not be able to delete anything or change alert settings. I'd like to either split Manage into Write/Delete groups or add a deny action role that would allow me to give users manage access with a deny delete:*
  3. 4 points
    As we move towards a DevOps model, we increasingly have a need for small teams to have full admin access to the tools they use to manage their IT services. When it comes to LogicMonitor, this has proven difficult with the existing role permission model. DevOps pods would like to be able to manage their own datasources, alerts, and escalation chains but this isn't possible unless we give them broad access rights to those areas, which could cause significant harm to other groups of monitoring users. For example, an inexperienced DevOps user could inadvertently modify a datasource that applies to all Windows devices or they could create an alert rule that causes alerts not to be delivered to other users. To solve this problem, I'd propose that LogicMonitor offer alert groups, escalation chain groups, along with the existing datasource groups. Then, LogicMonitor could provide the ability to restrict roles to manage these specific groups. DevOps pods could be given the ability to manage their own custom subset of datasources and set up their own alerts in a rule range after the main set of rules.
  4. 3 points
    We have a use case to show "Response Times" from a subset of configured Websites. Ideally I'd like this to be in the Big Number widget. We also want to able to chart a subset of my Websites' response times over time in the Chart widget. Anyone found a useful workaround to achieve this? Would LM consider "upgrading" widgets to allow the presentation of Website data? Currently only the SLA widget seems capable of handling Website data.
  5. 3 points
    We have a multi-tenant MSP environment, We find that we cannot use the same display name for our clients even though the similarly named systems are in different Child folders. So \'DC01\' for Domain Controller has to be unique across all of our clients. Please consider changing this.
  6. 3 points
    There are currently far too many opportunities to commit errors in LM from which is is difficult to recover since there is no version tracking. Ideally, it would be possible to revert to a previous version of any object, but especially very sensitive objects like logicmodules, alert policies, etc. I have created my own method of dealing with this, which leverages the API to store JSON streams of all critical elements regularly, changes committed via git (certain adjustments to the original results are needed to avoid a constant update stream). Recovery would be very manual, but at least possible. This would be far more useful within the system itself. Thanks, Mark
  7. 2 points
    We run a horizontally distributed architecture. As such, we really don't care (too much) if we lose one of N hosts, provided that a minimum number of hosts/processes/etc. are up and healthy. LogicMonitor makes it easy to make a graph of computed datapoints that span hosts, but doesn't let us configure alerts on the same computed data. Tangible example: One application, when running, publishes capacity data to LM. This capacity data is aggregated and graphed, giving us great insight for planning purposes. However, the only alert configuration that LM supports requires us to alert on every single host, sometimes causing unnecessary wake ups in the middle of the night. Operationally, we'd be fine having one host be down, as long as we maintain adequate reserve capacity. System-wide reserve capacity can only be determined by aggregating data across the set of hosts (just like the graphs do). We've been told to write custom scripts to do the collection and aggregation, and perhaps some rainy day we will. However, it seems like 1) LM does so much of the necessary bits already and 2) this would be a really useful capability for anyone that runs a horizontally distributed architecture. This isn't a "holy cow, gotta have this now!" type of feature request, but certainly would be a great value-add.
  8. 2 points
    It would be nice to have an export button on any alert table. When we're doing research on an issue and we've finally narrowed the criteria to see the info we need, it helps to have an export button right there, rather than having to go to reports and reconfigure all the parameters to hopefully get the same data.
  9. 2 points
    I think it would greate if you add some headers to your mails. This will helps to mail program to create conversation for every alert and clean message for it. Now we have only separate messages: LMD... critical - Host1 Ping PingLossPercent LMD... critical - Host2 Ping PingLossPercent LMD... ***CLEARED***critical - Host2 Ping PingLossPercent LMD... ***CLEARED***critical - Host1 Ping PingLossPercent In my opinion, it will better if this message will create conversation for every alert: LMD... ***CLEARED***critical - Host1 Ping PingLossPercent LMD... critical - Host1 Ping PingLossPercent LMD... ***CLEARED***critical - Host2 Ping PingLossPercent LMD... critical - Host2 Ping PingLossPercent As I know, the header is Thread-Index https://excelesquire.wordpress.com/2014/10/17/use-excel-to-count-the-number-of-emails-in-each-email-chain/ https://stackoverflow.com/questions/5506585/how-to-code-for-grouping-email-in-conversations
  10. 2 points
    Hi, GRAPE is a dependency manager for groovy scripts. I know logicmonitor is working on adding a screen to add custom JARs for scripts to use. An even more forward thinking approach would be to support GRAPE. Actually, it partially works right now, however it seems there are still a few errors that would need to be worked out. The benefit of this would be that devops teams could really develop the groovy scripts more freely and deploy them to larger environments without having to do manual processes with importing custom JARs, a process which simply does not scale. In my opinion, it's one of the few remaining barriers to Logicmonitors extensibility and scalability, and it's very close to working. Please investigate and support
  11. 2 points
    We would like be able to query historic SDTs to determine if a device,group, or instance has recently come out of SDT via API.
  12. 2 points
    We would like the ability to generate alarm on events generated within the vSphere event log, I really can't believe this isn't in place already.
  13. 2 points
    There currently doesn't appear to be a way to create an eventsource through the REST API. This functionality would be very useful as part of an CI/CD pipeline.
  14. 2 points
    Hi, I just got done working with VMware support on an issue where our ESXi 6.5 hostd process would crash during a booting phase. We eventually traced it back to a bug in some vSAN code that LM monitoring is polling.. It doesn't matter if you're running vSAN in your environment or not. Our work around has been to disable host level monitoring in LM for our ESXi hosts for now and it's been stable ever since. The expected fix is scheduled for release in Q3 2018 from VMware.
  15. 2 points
    NOC is an acronym for Network Operation Center. Heads up monitors are typically called NOC monitors, so you can see where the widget being called a NOC widget is useful for those types of dashboards.
  16. 2 points
    After spending some time trying to display instance level auto properties on an Alert widget on a dashboard, it has just been confirmed to me by Dave Lee that it is not possible and there is currently no way to display instance level properties on a dashboard. Since auto properties can hold very useful descriptive information detected during active discovery it would be nice to be able to include this on dashboards as additional information.
  17. 2 points
    Please add a token for alert notes so that we can include an alert's notes in the email notification when an alert clears.
  18. 2 points
    Hey Joe, I'm not sure that this exactly meets your needs, but I think it's a good start. Basically, you can call hostProps.toProperties() method which spits out an array that you can now dig through and filter using regex. Something like this: def allProps = hostProps.toProperties() allProps.each{ if(it ==~ /.*\.databases=/){ println it } } Let me know if this doesn't address what you're trying to accomplish.
  19. 2 points
    Hello LM Team, It would be great if the NOC widget in the Dashboards have the possibility to filter out inactive devices and show only the ones that actually have alerting enabled. For example we have VCenter that have 1500 virtual machines, but only about 10% of them are to be monitored at all times, so by default alerting is disabled for all VM machines from VCenter but these we actually need. Unfortunately the NOC widget will show us everything from that Datasource and it's problematic. Thank you.
  20. 2 points
    I would love to get my devs more involved in creating LogicModules, and incorporating it into a pipeline. Since LogicModules can be expressed in either pure XML or JSON, I would love to provide them documentation on the construction of LogicModules in these structured data formats natively.
  21. 2 points
    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
  22. 2 points
    I would appreciate it if datapoints marked for alerts on No Data were indicated in the Alert Tuning page with the designated alert level displayed. Right now, to know this, you have to dive into the datasource definition to find out. Thanks, Mark
  23. 2 points
    Please add the ability to select first, second, third, fourth weekend or day of month. So, for example, we need to be able configure: o Third weekend of the month, 0200 to 0400 - meaning both the third Saturday and Sunday of the month o Second Tuesday of the month, 0400 to 0600 And so on. At the moment we would have to manually add multiple entries and keep updating.
  24. 1 point
    It is currently impossible to detect certain conditions without having to be bombarded by noise alerts, which I am told is against the philosophy of Logic Monitor. Consider a few cases: * interface flaps a few times versus more frequently -- how do you tell the difference? right now, you have no choice other than perhaps to construct an API script (not tested). A better solution in this example would be to count the number of flaps over a period of time, and use that as your alert trigger. As it stands right now, there is not even a method to select the top 10 most unstable interfaces since it is literally a yes or no value and top 10 makes no sense. * resource utilization (bandwidth, CPU etc.) is sometimes much better checked over a period of time than just a single interval. the answer I have received on that is "require N checks to fail", and this works if the resource is pegged, but not if it is spiky. As it stands now, the longer of a period you want to simulate via "N checks", the higher the chance one check will reset the alert but the overall result is clearly bad on inspection. Please note this problem has been solved long ago by other tools, like Zabbix (https://www.zabbix.com/documentation/3.4/manual/config/triggers/expression), so hopefully this can be added to LM in the near future as well.
  25. 1 point
    We have more than one version of the same datasource, to be able to support the needs of different teams, and we need to keep the Display As the same for these datasource. In the Alert Tuning view at device group level, it's difficult to tell which datasource is which. Please add the DataSource description to the Alert Tuning table at device group level.