Richard_Collins
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: DataSources_List PropertySource
From my past conversations with support, the only real difference was that it provides a dedicated execution space (JVM) for script execution with dedicated memory. So if you uses Agent your script/batchscript/etc run inside Agent memory space and have the possibility to exhaust Agent memory or terminate Agent if your scripts do not exit properly; with SSE you can only impact the SSE process itself. That being said, SSE didn't exist for many years and all scripts ran in Agent, so keeping it that way isn't a big deal really, especially if you don't do a lot of LogicModule dev. SSE only kicks on if there is an available memory of 50% of the RAM allocated to Agent anyway (meaning if you configure a collector that uses 8GB for Agent, it would want 4GB for SSE) and if that's not available it will suspend usage of SSE anyhow. Also, because of that memory allocation logic, you'll find the docs recommend not using SSE with many virtual-machine collectors due to how they report RAM to the underlying guest OS (see the docs). We have a hodge-podge of SSE and non-SSE collectors at various clients and there's been no discernible difference operationally. We have this community DS that's the subject of this thread running on a dozen non-SSE linux VM collectors and it's had no issues.2Views0likes0CommentsRe: DataSources_List PropertySource
On 8/26/2021 at 11:56 AM, Antony Hawkins said: @Brandon Sellersum... no idea on the cause, in terms of a first guess at least. I'm more than happy to take a look, calendar gaps permitting (pretty hectic/full currently, but will see what I can do), if you can point me at a working and a non-working example in your portal (PM me the details). Based on an email exchange with support today it sounds like this won't work in the new version if executed from within SSE, it must be executed by Agent in this new non-API flavor. Perhaps his Medium collector wasn't using SSE?2Views0likes0CommentsRe: Cisco EIGRP Peers
So I know this is an old thread, and the above community locator isn't really needed now that the EIGRP peers datasource is in the LM repo.... but I thought I'd post here in case someone else hit a similar issue and wanted a fix. The built-in groovy discovery script was using HEX addresses for the peer addresses in our instances, and it was a pain to decipher them every time one went down. So I added a hex-to-decimal conversion to the discovery script so that he instance names look like "172.20.0.50" instead of "AC:14:00:32" Here is the updated block of the discovery script // get all IP addresses of connected peers. peerAddr_walk.eachLine { line -> regex_pattern = "(${peerAddr_OID})" + /.(.*)\s=\s(.*)/; regex_match = ~regex_pattern line_match = regex_match.matcher(line) handle = line_match[0][2] val = line_match[0][3] //val here may be SNMP data in format of "Hex-STRING: AC 14 00 32" and arrive as AC:14:00:32 instead of an ip address in the instance name if (val.contains(":")) { tempaddr = val.split(":") def newaddr = [] tempaddr.each { hexint -> newaddr.add(Integer.parseInt(hexint, 16)) } val = newaddr.join(".") } Hope it helps someone else1View2likes0Comments