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. Hey @Mike Moniz thanks for the list here, I will get this to the ME team for fixing.
  2. We have some ACI (APIC) monitoring out of the box today: https://www.logicmonitor.com/support/monitoring/networking-firewalls/cisco-apic-monitoring/ If there's additional stuff you'd like to see from ACI, please don't hesitate to let us know.
  3. @pperreault good stuff. If I were to implement this in product I would probably write a regex with capture groups to match a valid user line. That way you can be more sure than the 9 column line is actually a user entry, and you can use the capture groups to easily dump out other items of interest. This is a pretty common pattern in our core DataSources, most of the Nimble Storage stuff follows this pattern. The regexes in those scripts might look scary but it's pretty easy to make in something like https://regexr.com It's pretty solid looking for a first Groovy script. I would consider exiting the SSH session before you process the output, no need to keep that connection open after you have the data in a variable. As far as error handling, you could wrap the initial Expect session setup in a try/catch. You can also use exitValue() on your Expect client object to ensure that your `show` command returned a successful return code before parsing the output. Here's a pretty extreme example of a Groovy script with multiple return codes for specific issues: import rocks.xmpp.addr.Jid import rocks.xmpp.core.XmppException import rocks.xmpp.core.sasl.AuthenticationException import rocks.xmpp.core.session.TcpConnectionConfiguration import rocks.xmpp.core.session.XmppClient import rocks.xmpp.core.session.XmppSessionConfiguration import rocks.xmpp.core.session.debug.ConsoleDebugger import rocks.xmpp.core.stanza.model.Message import javax.net.ssl.* // Server details, required def host = hostProps.get("system.hostname") def domain = hostProps.get("xmpp.domain") def port = hostProps.get("xmpp.port") ?: '5222' // Account details, required def sender = hostProps.get("xmpp.sender") def sender_pass = hostProps.get("xmpp.sender.pass") def receiver = hostProps.get("xmpp.receiver") def receiver_pass = hostProps.get("xmpp.receiver.pass") // Optional, disable starttls by setting to 'false' def use_ssl = hostProps.get("xmpp.ssl") ?: true // Optional, set to "true" to enable debug output in wrapper.log def debug = hostProps.get("xmpp.debug") ?: 'false' // Optional, change default authentication mechanism def auth_mechanism = hostProps.get("xmpp.authmech") ?: "PLAIN" // time to wait for expected message ( in seconds ) def timeout = hostProps.get("xmpp.message.timeout") ?: 5 // Check for required props if (!(sender && sender_pass && receiver && receiver_pass && domain)) { println 'missing required properties' println "xmpp.sender, xmpp.sender_pass, xmpp.receiver, xmpp.receiver_pass, and xmpp.domain are required" return 1; } // Used as a lock for synchronizing def received = new Object(); // Setup a bogus trust manager to accept any cert def nullTrustManager = [ checkClientTrusted: { chain, authType -> }, checkServerTrusted: { chain, authType -> }, getAcceptedIssuers: { null } ] // Setup a bogus hostname verifier def nullHostnameVerifier = [ verify: { hostname, session -> true } ] // Setup an SSL Context with the bogus TM and HV to accept any cert SSLContext sc = SSLContext.getInstance("SSL") sc.init(null, [nullTrustManager as X509TrustManager] as TrustManager[], null) public class NullHostnameVerifier implements HostnameVerifier { public boolean verify(String hostname, SSLSession session) { return true; } } HostnameVerifier verifier = new NullHostnameVerifier(); // Store send and receive timestamps so we can calculate RTT ( in millis ) def send_time = null def receive_time = null // Check debug option, setup session accordingly if (debug == 'true') { sessionConfiguration = XmppSessionConfiguration.builder() .debugger(ConsoleDebugger.class) .authenticationMechanisms(auth_mechanism) .build(); } else { sessionConfiguration = XmppSessionConfiguration.builder() .authenticationMechanisms(auth_mechanism) .build(); } // Setup connection config def tcpConfiguration = TcpConnectionConfiguration.builder() .hostname(host) // The hostname. .port(port.toInteger()) // The XMPP default port. .sslContext(sc) // Use an SSL context, which trusts every server. Only use it for testing! .hostnameVerifier(verifier) .secure(use_ssl) // We want to negotiate a TLS connection. .build(); // create the client instance def xmppClientSender = XmppClient.create(domain, sessionConfiguration, tcpConfiguration); def xmppClientReceiver = XmppClient.create(domain, sessionConfiguration, tcpConfiguration); // Add a message listener to the client instance xmppClientReceiver.addInboundMessageListener( { e -> // Get the message Message message = e.getMessage(); // Confirm that this message is from the expected sender if (message.from.toString() == "${sender}@${domain}/LMSENDER") { // Confirm that this message has the expected content if (message.body == "TESTMESSAGE") { // Record receive time receive_time = System.currentTimeMillis(); // Notify the parent thread that we can exit // synchronized must be used for notify() to work // received is our lock synchronized (received) { // notify the main thread to resume now that we have received the expected message. received.notify(); } } } }); // Try to connect the receiver client try { xmppClientReceiver.connect(); } catch (XmppException e) { println 'Receiver client failed to connect'; return 2; } // Try to connect the sender client try { xmppClientSender.connect(); } catch (XmppException e) { println 'Sender client failed to connect'; return 3; } // Try to login and send a message try { // We need to use synchronized here to call wait() on our lock object (received) // This will wait for a message event from the expected user with the expected content // The message handler will call notify() to resume this thread. // If we don't do this the client will close before we get the message. synchronized (received) { // Login with receiver account xmppClientReceiver.login(receiver, receiver_pass, 'LMRECEIVER') // Login with Sender account xmppClientSender.login(sender, sender_pass, 'LMSENDER') // Record time just before sending, so we can get RTT send_time = System.currentTimeMillis() // Send the message xmppClientSender.send(new Message(Jid.of("${receiver}@example.com"), Message.Type.CHAT, "TESTMESSAGE")) // Call wait() to block this thread until the message listener has called notify() // or until the timeout. received.wait(timeout * 1000) } if (send_time == null) { println "Message wasn't sent." return 4; } if (receive_time == null) { println "Message wasn't received." return 5; } // Print delivery time println receive_time - send_time } catch (AuthenticationException e) { println 'Authentication issue. Check your credentials.' println e; return 6; } catch (XmppException e) { println 'Something else went wrong with XMPP.' println e; return 7; } finally { // Close the connections xmppClientReceiver.close() xmppClientSender.close() } return 0;
  4. @Vitor Santos you won't have that kind of control over scheduling. Did you try using Upload Script? You should be able to use your proprietary language directly and avoid the hassle of syncing up two scripts
  5. @mnagel no concrete plan at the moment, but there is an open FEED ticket for it.
  6. Hey @mnagel we're actually working on this right now but we're blocked on having access to a device. If you can help us get access we're looking to get these into core soon. Back in 2017, "beta" included all sorts of stuff that wouldn't necessarily make it to core in a timely manner. The team's come quite a ways since then, and with the Exchange we'll have some better infrastructure in place to distribute and track "beta" modules. We're looking to nail down our Q1 2020 LogicModule Roadmap in mid-December, which we will publish to avoid duplicate efforts. Thanks for bearing with us, hopefully I caught you before you spent too much time on Ruckus.
  7. @Cole McDonald I think you're referencing wrapper.java.maxmemory in wrapper.conf.
  8. 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.
  9. @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.
  10. Reviewed. You weren't kidding about simple code.
  11. 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.
  12. 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
  13. @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.
  14. @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/
  15. @DFassett it should be out of Security Review now.