Can anyone help modify this Datasource to be able to use any port?
Hi, We have F5 devices and LM can monitor some of the stuff inside them. However, we found a problem because the Module that monitors the SSL certs only monitors them if the site using it is on port 443. If it is using any other port, LM ignores it and doesn't monitor it. We have a lot of internal sites that us ports other than 443 and had a cert expire last week. It broke some stuff because we never got notified that an expiration was coming up. The module in question is called: F5_BigIP_SSL_VIP_Cert. (not sure how to post a link to it. The Discovery script has a line that says: if(port == "443"). This causes it to not see any of our sites that use ports other than 443. If I change it to say: port != "999" it will find all our sites that use something other than 443 which is great. However, the Collection script is also hard-coded to 443 as: This 'port' variable is used in a bunch of places in the rest of the script so it's not as easy to modify. I'd have to get a list of every site and which ports they use and code something up which would be impossible to maintain as things change. I'm wondering if there'd be a way for the Discovery script to grab the name AND port from the things it finds and then pass that info to the Collection script so each cert would include the port it's on and everything would just work. Unfortunately, that's over my head, and I don't know if that'd be really easy, or really hard to do, so I figured I'd ask here. If any of that doesn't make sense, let me know and I'll try to clarify it. Thanks!!Groovy4, FastStringService, V.206, etc
I noticed in the detailed release notes for V.206 some discussion of Groovy2 vs Groovy4, because apparently at some point in the future Groovy2 may go away and so Groovy4 will be required. There is some info on mitigation, including updating official modules (with its usual issues, IMO) but also updating custom modules. But it looks like the latest collector doesnt force this now, but just supports both Groovy2 and Groovy4. But I want to move on this as soon as I can. So I did some testing on one of my custom groovy configsources and discovered that when I force the script to use Groovy4 (//!/lib-groovy/v4 on the 1st line) I get one of the errors mentioned in the release notes for V.206 ( https://www.logicmonitor.com/release-notes/v-206-release-notes ). Specifically "Unable to load FastStringService". But unlike some of the other known issues, no workaround or example was given. import groovy.json.*; def JsonSlurper jsonSlurper = new JsonSlurper(); def jsonParsed = jsonSlurper.parseText(responseBody) The first 2 lines are fine, so I believe there is nothing to be changed with how I'm importing it. The docs I see for latest groovy still show I'd use groovy.json.jsonSlurper. But the 3rd line in the code throws the "Unable to load FastStringService" error. So I guess I'm just wondering if the community has dealt with this specific issue, or if there is a document that contains a workaround for this case and others. I know LM will be updating their modules, or maybe they already have (I havent looked; their new Modules UI hurts my brain a bit, not looking forward to the old version under settings going away). But updating all our custom code is going to be painful. Somehow I didnt realize this conversion from Groovy2 to Groovy4 was coming, so I'm trying to figure out when that will be a hard line in the sand. But in the meantime, I'm just wondering if anyone has found a way around this issue? Thanks!Oracle jdbc JAR file update
LogicMonitor's collector utilizes an outdated version of the Oracle JDBC jar file. It's essential to upgrade to the most recent version available in the Maven repository to take advantage of new secure database connection types. However, users should note a significant change in behavior with the new jar: while the old version automatically closed abandoned Oracle database connections, the new version does not, potentially leading to an excessive number of open connections. This surge in open connections can overload and crash an Oracle server where connections aren’t limited by user. Therefore, clients must either ensure that customizations explicitly close database connections or adjust their server settings to impose limits on the number of concurrent open connections. All of the newest Logicmonitor datasources properly close connections but some of the older modules did not do this. Logicmonitor has created a module to test for this problem and alert if it occurs. Oracle_Database_MonitorUser will keep track of the number of connections in use by the monitoring user and alert if the number of connections is too high. This update is scheduled for collector 35.400. Make sure this module is installed before upgrading to collect 35.400 and monitor your database connections before rolling this out to general release.
