Michael Rodrigues

LogicMonitor Staff
  • Content Count

  • Joined

  • Last visited

Community Reputation

100 Excellent

1 Follower

About Michael Rodrigues

  • Rank
    Community All Star

Recent Profile Visitors

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

  1. @Cole McDonald I think you're referencing wrapper.java.maxmemory in wrapper.conf.
  2. Hey @Cole McDonald, nothing's changed there. I'd guess you're confusing System memory with JVM memory: https://www.logicmonitor.com/support/collectors/collector-capacity/ I still reference that chart when I second guess myself on it.
  3. @Hayden if you go through support they can get this to the monitoring team. Being beta, you may see a longer turnaround time for response from the dev team. You're sure you've got SNMP enabled on your Ruckus, and it's properly configured in LM for your Ruckus resource? You can also do some snmpwalks on the device from the debug window to see if it's responding at all.
  4. Reviewed. You weren't kidding about simple code.
  5. Hey @Cole McDonald, my understanding is that CLOSE_WAIT state is entered when the server closes the socket, as opposed to the client, which eventually results in TIME_WAIT. I presume your port exhaustion is due to all of the collection tasks on your collector? There are some timeout config directives you can tweak for the various collection methods if you identify which one is using the most resources.
  6. Hi @Shack, sorry you're having collector issues. There are currently ~400 collectors running 28.400 across the customer base but we haven't come across any bugs so far. I've asked Support to follow up on your case to see if we need to get development involved. Thanks for your patience, Michael
  7. @Dennis Walcott thought of a codeless way to do it. If you have a command line utility that allows you to test RADIUS (I used radtest from freeradius) you can just install it on your collector and call it with the "upload script" type Datasource. Presumably the cli utility will give you back something you can easily regex for in a datapoint, "SUCCESS" or "FAILURE" gets printed out if I remember correctly.
  8. @Dennis Walcott I've done something similar in another monitoring tool in a past life. I used a script that called a radius test client and made a request directly to the RADIUS server. Parse the results and return a simple 1 or 0 for failure or success. I would probably go with a DataSource over a webcheck in this case. You can use Expect to run the radius test client if it's installed on your collector. https://www.logicmonitor.com/support/terminology-syntax/scripting-support/groovyexpect-text-based-interaction/
  9. @DFassett it should be out of Security Review now.
  10. Hey @joshlowit1, I'm sorry you're having problems with WMI collection. Can I trouble you to engage with Support on this? They can gather the necessary details and get this escalated to the collector team if necessary.
  11. Hey @BrianG, we actually don't have anything official for linux processes via SSH just yet. We'll get this into the queue, we really should have parity between the SNMP and SSH monitoring offerings for linux.
  12. Hey @Ye Tao, can you give me some more concrete examples of data you'd like to track with this? We've heard this request a few times. We do have instance-level properties which provide a way to collect text metadata, but it's not the same as collecting it in a time series. Would this generally be a string representing something like status or health?
  13. 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.
  14. 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.