All Activity

This stream auto-updates     

  1. Yesterday
  2. There is not, unless there has been a change recently. There are some datapoints within the collectors you can use (which we do for widgets displaying what we are able). There is not full coverage for all the various things that can incur fees (or usage against commit). I had to write a script against the API to capture this, and even then it is not complete. I had to define a custom property to group the results by client as well (with a warning if I find an element without the custom property). My script currently does this: scans all resources, counts each regular and LMCloud type (deviceType==0 or deviceType==2) scans all configsource instances to count LMConfig usage (dataSourceType == "CS") scans all websites, counts each, noting whether it is internal or external I would definitely prefer something standard to get a complete picture of license consumption, especially since new separately licensed features are added from time to time.
  3. We need a way to be able to confirm what type of LogicMonitor license is being consumed by a given Resource or Website. Ideally there would be a system.license or similar property we can look at to be sure of the license type being counted for that resource. This would allow proper audit and chargeback to customers who are using the service as well as a way to validate total billing on our account. There must be some way you are counting these in order to bill us, so if this can be exposed as a property it would be helpful.
  4. I'm in a multi-tenant IaaS windows environment and I'll need to test my second hop authentication to make sure I can get to the servers we're monitoring from the Collector. The External alerting documentation specifically says it runs the script on the collector. As that is the case, I would imagine the script can do anything you could normally do in the script on that collector. Caveat from the documentation: "You can only have one External Alert entry per Collector." If you had multiple scripts you wanted to be able to run, they'd need to be tokenized, then pushed through a communication script that starts the pertinent script on the collector which then performs the corrective action on the client. With that in mind, I'd like to rally for an external alerting method that would allow the Collector assigned to a device to be passed as a token that can be used to define where a common script would run from to be able to reach the client VM. I also would like them to be able to be a stage in an escalation... potentially using output from the script to inform the escalation chain somehow. At minimum a true/false continue escalation return flag.
  5. pperreault

    Public IP Property Source

    Thanks for this, this is great. I am only interested in the ip and org info so in the interest of de-cluttering the property source info I reduced the script output to just that. Stack Exchange (since I'm not a groovy guy) pointed me to this solution. //comment out orig map iteration //arrayInfo_map.each{ key, value -> println "$key=$value"}; def ip_addr = arrayInfo_map.find{ it.key == "ip" }?.value; if(ip_addr) println "ip = ${ip_addr}"; def carrier = arrayInfo_map.find{ it.key == "org" }?.value; if(carrier) println "org = ${carrier}"; I wouldn't be surprised if improvement on this is possible. Thanks again.
  6. ShahzadAli

    How to Add Recipient Group using Rest API

    Yes got it thanks. Customer Support also provide same link. Issue resolved. Thank You.
  7. Last week
  8. Michael Rodrigues

    Retaining attributes while updating LogicModules

    Thanks for such a quick reply @dcyriac. What we're considering is basically extending the Device Tree Alert Tuning functionality to the other things in the list. It already includes severity. This would mitigate the need to modify the global definition, and make updating easier. Would love to hear your thoughts on this.
  9. mnagel

    datasource migration function

    It is nice to hear this is getting some attention, but there are definitely more items needed. There are at least two different issues with LogicModule maintenance. The one in this F/R relates to upgrades (e.g., new version of VMware modules). The hope was that you could retain previous data by matching DS/DP in the old to the new in a merge operation when importing the new datasource. I get it is complex, but it is also frustrating to see loss of historical data treated so casually. The one you are referencing is about module parameter override preservation. I like what you have above, but really, the correct solution for this is to allow linked cloning with inheritance and individual override of any or all elements in the module. There are already many examples of almost the same but not quite modules that could benefit from this. A great example of how that leads to problems is the excellent changes made by Steve Francis to support ActualSpeed ILPs for interfaces. Because that applies to only one (albeit common) case, all other interface DSes fail to get the same behavior. If that was done in a base interface module and the rest inherited from there with overrides/additions for there specific needs, that could be a general improvement for all interfaces. Lacking that, I would ask that in addition to the above, the following also be preserved: additional datapoints (including scripts, etc.) changes to datapoint settings (perhaps not scripts, but alert settings including templates) I am dealing with a specific use case right now where a fairly complicated NetApp DS needs to be updated to alarm when space available drops below a threshold. We can add a custom threshold, but then the alert template is default and the units are bytes. I can fix this, but this creates a maintenance headache regardless of whether I update in place (new versions will kill my changes) or clone (new versions require manual review to sync into the clone(s)). That said, the filter preservation would at least avoid issues with my changes to BGP- (filters admin down sessions) and changes to the collection interval for HP network devices (default is set to 1 day instead of 1 hour), so I will take what I can get!
  10. Michael Rodrigues

    datasource migration function

    We're not currently looking into a way to "stitch" data across module name change updates, but we are working on a feature that would let you easily update and keep your changes to: -AppliesTo -AD/Collection intervals -AD Filters -Alert threshold changes It would be very similar to the Group/Device/Instance level Alert Threshold tuning we allow now, but we would extend it to the account-level, and add the above. This means that for core LogicModules, you would just update the main definition, and apply your tweaks on the Device tree. I know that doesn't solve the stitching problem, but it should make merge/updates easier, and would not require the use and management of clones. We also looked into a more advanced diff & merge option, but generally we know if you changed one of those things above, you want to keep it when updating. Changing something not listed above would require creating a new module definition. The great thing about this approach is that minor changes to the module don't result in a brand new module that you have to clone or manage. If you make frequent customizations to things not on that list, or you already have a lot of clones, there may be some pain in migrating to the new paradigm. This doesn't preclude further enhancements in the future, but we think this is a good iteration that will save lots of time with updates going forward. Any feedback is appreciated.
  11. @Michael Rodrigues The only thing that comes to mind apart from the ones you've mentioned is 'Alert Severity' levels.
  12. Michael Rodrigues

    Retaining attributes while updating LogicModules

    Hey @dcyriac, can you provide any more detail on what other attributes you're commonly changing on modules that you'd like to persist? Anything outside of?: - AppliesTo -Alert Thresholds -AD/Collection Interval -AD Filters
  13. Please implement more granular permissions for SDT function. We would like to be able to grant permission to apply SDT to data sources elements, but NOT on the resource itself. We often encounter situations where by accident or carelessness our staff apply SDT to a resource instead of the data source element.
  14. Michael Rodrigues

    How to Add Recipient Group using Rest API

    Hi @ShahzadAli, have you seen the REST API v2 documentation here: https://www.logicmonitor.com/swagger-ui-master/dist/#/Recipient Groups/addRecipientGroup It lays out how to add a recipient group pretty nicely.
  15. Forrest Evans - LM

    1 to Many fail-over load balancing Feature request

    Hi Akash, We are close to releasing a new feature that will include functionality to spread fail-over of devices among multiple collectors. ~Forrest
  16. Joe Tran

    Mobile App

    I don't. I just use the site in a mobile browser set to request the desktop site. A better mobile experience would be great though.
  17. ShahzadAli

    How to Add Recipient Group using Rest API

    Still working on it. Can any one please show any response?
  18. Hi All, As we all know, that currently logic monitor has a feature to setup only 1 fail over collector. I would like to request for a feature, where we can have multiple fail-over collectors and in such a way that even if, the collector is active and polling objects, it still can be set as a fail-over collector. Thanks & Regards, Akash Pandya
  19. Amy

    Mobile App

    I installed the mobile app on my iPhone today and when I try to open it it just says loading - forever. Is anyone using it?
  20. We run into situations where widgets display an error of some sort due to any number of reasons, usually when datasources are changed or resource group structure is updated. The point is, there is an error displayed in the widget instead of the data, and the fact that is happening is pure stealth currently, just waiting for an embarrassing moment with clients. I propose that this meta-issue be reflected in a way it can be detected in advance. If the API can pull that information, then a check could be setup within LM or via external script. I just checked our JSON dump of all widgets and nothing like this appears to be in place currently.
  21. Michael Rodrigues

    VMware vCenter Event Log Monitoring

    We talked about building an EventSource to pass alarms through, but that would be very noisy and probably wouldn't make it into core. Lots of those alarms also overlap with alert thresholds defined within the VMware modules. You can build Syslog EventSources to pick alarms out of a vSphere syslog stream today. I don't see us building a UI specifically around selecting and filtering which VMware alerts get passed through, but EventSource filters do provide some of this functionality.
  22. Michael Rodrigues

    netflow filter improvements

    Hey @Brandon, @mnagel, we do not currently have these NetFlow enhancements prioritized. I am hearing a decent amount of feedback about NetFlow shortcomings though, so this may get more love later this year, or in 2020.
  23. dharrison

    Instance properties handling

    Looking into a couple of use cases we have a large VMware environment in which we dont want every VM as a device/resource . In LM it has instances for each vm . These instances have tags import from esx. We would like for LM to be able to be to query Instance properties for a couple of reasons . 1) Dynamic groups - based on instance properties . 2) Device by types - OS types for example . show all windows whether instances or devices. 3) Alert by instance properties . Its a little frustrating in the data is visible in LM but we're not able to group/query/alert by these properties. see attached image.
  24. Brandon

    netflow filter improvements

    We're experimenting with netflow now and we are also struggling with these very real limitations. It would be great if we could get a response as to whether or not enhancements to Netflow are going to be prioritized. Currently we're finding that we have no other choice but to rely on multiple tools to gather this data.
  25. Mosh

    Dependencies or Parent/Child Relationships

    Thanks @Michael Fisher If the alert suppression is part of the core platform that is good news.
  26. Michael Fisher

    Dependencies or Parent/Child Relationships

    @Mosh The majority of our Topology offering will be core to our platform. However, aspects of Topology, such as advanced overlays, widgets, saved maps, etc, are features that are subject to be billable items in a broader LM AI platform that we are actively working on. Stay tuned for the launch email I will be sending out soon which will contain more info on this subject. Best, Michael
  27. Mosh

    Dependencies or Parent/Child Relationships

    Thanks @Chris Sternberg Will the topology module be a licensed module or included as part of a forthcoming update?
  1. Load more activity