Matthew Dunham

LogicMonitor Staff
  • Content Count

    60
  • Joined

  • Last visited

Everything posted by Matthew Dunham

  1. Hi @Cole McDonald - The LogicMonitor Collector runs jobs using the permissions it has inherited from the Collector. Where the Collector is run as a privileged user so will the jobs that it's launched. Regardless of which Collector permissions model you adopt, as a best practice we recommend using our role-based access controls to limit "Manage" access to your Collectors. You can do so by assigning individuals that don't need Collector Debug functionality the "manager" role rather than the "administrator" role. This allows you to effectively limit the scope of your end-users based on the principle of least privilege.
  2. Thanks @mnagel -- this is indeed the recommended approach. And yes, we're working on getting a frequency scheduler attached to PropertySources. Coming soon....
  3. Hey Jamie - Good point. As a workaround, you can create a Complex Datapoint (https://www.logicmonitor.com/support/datasources/creating-managing-datasources/complex-datapoints/) to do what you need. We maintain the datasource pollling interval as a token you can substitute into your complex datapoint expressions. Provided your units are per-second (or converted as such) you can translate your "rate datapoint" into a "difference datapoint" using something like: rate_datapoint * ##POLLINTERVAL## A little more detail on substitution tokens available in datasources creation are available at: https://www.logicmonitor.com/support/datasources/creating-managing-datasources/tokens-available-for-data-collection/ Hope this helps.
  4. You should be able to find it in our "core" repository, which you can access from DataSources => Add => From LogicMonitor Repository. We're in the process of streamlining this process. Apologies for the confusion.
  5. An octet is really just a fancy name for a "byte". So if you multiply this number by 8 you get bits -- that solves part of your question. The other trick is that you need to convert the point-in-time octets measurement to a rate with units of octets/sec (and eventually bps). In LogicMonitor you can do so by using the "counter" or "derive" datapoint type. See https://www.logicmonitor.com/support/datasources/creating-managing-datasources/normal-datapoints/ for details, but the short version is that these two datapoint types subtract the current value from the previous value and then divide by the configured polling interval to give you a measurement in units/sec. Then to do the multiplication above, you can use a Complex Datapoint to translate bytes/sec (octets/sec) to bps https://www.logicmonitor.com/support/datasources/creating-managing-datasources/complex-datapoints/. LogicMonitor graphs can auto-scale for you, so we'll handle the Kbps / Mbps / Gbps conversion for you as needed. For Fortinet gear, you might also have a look at our "Fortinet Fortigate Interfaces" LogicModule -- it does all this for you (and more).
  6. Note that LogicMonitor does not endorse running Collectors with the EnforceLogicMonitorSSL configuration item set to "false". This setting disables certificate verification the Collector uses to authenticate our service platform before sending sensitive data. By disabling this, you risk exposing the data your Collector sends upstream to a man-in-the-middle attack. Where a decryption proxy is in use, we recommend that you disable proxying for Collector traffic as Mike specifies above.
  7. Hi Joe - Thanks for the suggestion. That's maybe a reasonable improvement to the Collector Properties feature set. We designed Collector Properties primarily to assist in the diagnosis and identification in the context of Collector Down notifications, so we wouldn't have expected a use-case by which they're used to store credentials or other sensitive information. Would you mind explaining your use-case so we can get some additional context?
  8. Thanks Eric! I have been attempting to engage with the Microsoft mothership on this issue for some time and getting the brick wall. We'll investigate this solution and integrate into our Windows Collectors as appropriate.
  9. LogicMonitor Collectors don't yet support Raspian OS. Our Collector has been built for the x86 CPU architecture, and there are a few tricks to get it to run on the ARM processors found in Raspberry Pi devices.
  10. The LM Config™ features are licensed separately from our core product. Reach out to our support team to learn how to get it enabled.
  11. The issue here could be that some of your Windows systems are defaulting to connect to LogicMonitor endpoints using TLS 1.0, which we no longer support. You can ensure your scripts are using a more recent version of TLS by prepending the following line of code: [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls11 -bor [System.Net.SecurityProtocolType]::Tls12; Hope this helps.
  12. Our apologies -- this is a product bug related to some Cisco devices sending non-standard syslog data. We're working on a fix.
  13. Eminently possible, but we don't do this out-of-the-box. You'd need to write your own custom datasource. See the example at https://www.logicmonitor.com/support/datasources/groovy-support/dns-scripting-methods/, as well as the preceding info about writing scripted datasources, for details.
  14. We've done some in-house research into the right-sizing of the appropriate permissions for polling WMI/PDH from a remote system. Our own experience has been that we can indeed craft a set of non-administrative permissions carved out for this use-case for a given OS version + service-pack + patch-level. But that a subsequent patch may change these on any particular Patch Tuesday, which makes it pretty challenging for us to support -- or even recommend. We have an initiative in-flight with Microsoft Consulting by which we're attempting to get direct guidance from the proverbial "horse's mouth" on how best to right size these permissions in a future-proof (or at least future-resistance) way. Stay tuned....
  15. Hey Matt - Note that we support monitoring of Office365 email availability & performance using our Email Service Monitoring datasources. Have a look at: https://www.logicmonitor.com/support/monitoring/applications-databases/email-service-monitoring/ for details. A number of other Office365 services can be monitored with custom service checks. More info at: https://www.logicmonitor.com/support/services/adding-managing-services/adding-a-web-service/ -m
  16. Hi Thomas - I'd suggest having a look at https://www.logicmonitor.com/support/devices/device-datasources-instances/device-datasources-instances-overview/ to solidify the concept of "singleton" vs "multi-instance" datasources. Note that a singleton won't have an instance id, since there's only a single instance to monitor in that type of datasource. Once you have that under your belt, have a look at https://www.logicmonitor.com/support/datasources/data-collection-methods/scripted-data-collection-overview/ to understand scripted datasource modes of operation. Then follow with https://www.logicmonitor.com/support/terminology-syntax/scripting-support/external-scripting/ which provides a simple example of putting together a scripted datasource. Hope this helps. -m
  17. Hi Jeff - I assume you've seen our information on Collector sizing at: https://www.logicmonitor.com/support/settings/collectors/collector-capacity/ From a storage standpoint the Collector uses only a nominal amount of space -- only about 200MB. And disk storage is not used in normal operation because essentially all operations take place in-memory. Where the Collector may use disk is to cache collected data in case of a temporary outage between the Collector and the LM mothership. In this (typically rare) case the Collector will write collected data to disk until connectivity with our service platform is restored, at which point this cache will be flushed such that any consumed storage will be freed.
  18. Hi Joe - Active Discovery wasn't designed for this purpose. Instead you might consider repurposing your AD script as a Data Collection script that reports the number of instances, and use the "delta" alert threshold to notify you when your instance count has changed. Hope this helps....
  19. At this time none of LogicMonitor's "core" LogicModules employ WinRM services for device polling. Although it's possible that your account may have custom (PowerShell) datasources that might use WinRM, these are likely not supported by LogicMonitor
  20. We've been working on a number of features to overhaul and streamline the LogicModule management process, including version maintenance, ease-of-import, and proactive updates. We expect to see these arrive in-product real soon. Stay tuned.....
  21. Note that LogicMonitor's RBAC system allows for the definition of any role you'd like with fine-grained detail. Feel free to create any role as appropriate for your environment.
  22. Yep -- we're working on exactly this feature, along with streamlining the overall LogicModule update process. Probably a few months out still; stay tuned....
  23. We have some Ruckus monitoring in beta. Contact support to get your hands on early-access modules.
  24. Hi Idan - In this case it sounds like what you'll want to do is create a datasource that uses JDBC-based Active Discovery to get the database name (e.g. something like "SHOW DATABASES") then use JDBC Data Collection to run your query. See: https://www.logicmonitor.com/support/datasources/active-discovery/jdbc-active-discovery/ and https://www.logicmonitor.com/support/datasources/data-collection-methods/jdbc-data-collection/ respectively. You can then create datapoints with appropriate thresholds to generate alerts. To get the current value of the datapoint somewhere you can see, the best bet is probably to use our "Big Number Widget" on a dashboard. For details see: https://www.logicmonitor.com/support/dashboards-and-widgets/widgets/big-number-widget/
  25. Yup -- this has been painful as far back as when I was an LM customer a few years back. We're really excited to finally get to improve this area of the service.