Testing groovy script on local ubuntu machine
I am searching for a way to run groovy scripts on my local ubuntu (WSL) while being able to work with the same classes that are used by the collectors. To achieve this I installed a java+groovy and deployed a collector.
However I am unable to import the classes like “com.santaba.agent.groovyapi.snmp.Snmp”
Is there any way to achieve this? Or can I somehow locally access the collector shell to test groovy code without the need to use the LM web UI?
So, I am basically searching for a way to develop scripted DataSources using CLI, without fiddling with the web UI. Any guidance very much appreciated.
therealsle
Posted 2 years ago·Last reply 2 years ago
9 comments
therealsle
OP2 years agoThanks Eric. I have already been using this browser extension for quite a while. It does solve at least some of the issues.
Eric Hale
·2 years agoOne of our devolpers also created a Chrome Extension for debug that helps with syntax highlighting and such…
LogicMonitor Script Debug Helper
https://chromewebstore.google.com/detail/logicmonitor-script-debug/ijojgoccfeggejpbhdahmeijjhpdjklf?pli=1
...but I would love to see an official VSCode extension as well.
therealsle
OP2 years agoThanks for sharing this knowledge!
LM User
·2 years agoThey use IntelliJ as the IDE and they do some acrobatics in there to get the collector classes in and recognized by the IDE. They used to use coretools (more later) to run the file on their file system against a target collector.
Coretools was a set of command line utilities that would allow you to run groovy/posh scripts saved on your file system on a collector against a certain device. So, they’d write a script, save it to their local file system, then run a command like “coretool -run myfile.groovy -device 192.168.0.1” and the output would be echoed to their terminal. For authentication, the early versions used api creds stored in a creds.json file. Later versions utilized a chrome plugin to grab the cookie from your current browser session to LM, allowing the ME team to run it against any portal they could log into using the LM support remote assistance capability (quite secure if you ask me).
All these tools were made by the ME team and not supported for customer use. At one point it got posted to a github repo, but there was a kerfuffle about it being too powerful for the security folks to be comfortable with. So it was pulled (likely the auth method was not preferable). I’m not sure the ME team still uses it. Not sure what they would do instead. The guy that wrote coretools doesn’t work at LM anymore, i think.
That’s part of the reason i’m asking for LM to make the VSCode plugin. Coretools already does most of that work and is even written in python. A good developer could build it over the weekend after getting over the VSCode specific learning curve. So it should only take LM a couple months and several dozen developers.
therealsle
OP2 years agoThanks Stuart, totally agree, +1 for such a plugin.
I’m wondering how LM staff is doing dev for DataSources etc. ..?
LM User
·2 years agoThat’s exactly what I do. I use VSCode and started asking 6 months ago that LM release a plugin for VSCode that would allow execution right within VSCode. This could be written by an enterprising coder since VSCode plugins aren’t too difficult and running a debug command is just an API call. However, it is just beyond my own skill (but not beyond LM’s developers hopefully). I don’t know if i officially put this in as a feature request, but i’m putting it in again officially now.
FWIW: I code in VSCode, for all the reasons you mentioned, then copy/paste into the debug window. The advantage of using the debug window (or the equivalent API call) is that the device/instance properties available in LM are available to the debug task. Meaning that the code you test and the code you eventually put into production can be exactly the same, pulling in credentials and other properties at runtime the same way in both cases. (Not to mention the libraries import issue you mentioned)
If you just run the groovy code in the terminal, even on the collector, you’d have to hard code the ssh.user/ssh.pass or other credentials (or put into env vars). Either way, the code you’re testing would function fundamentally differently from the final code run by the datasource. When you do it via the collector debug console/api call, things like hostProps.get(“ssh.user”) will fetch the current value from the chosen device into your script.
therealsle
OP2 years agoAre you referring to the web-based collector debug console?
If yes, my reasons are:
I prefer using my own editor for writing code (VS Code). This has several advantages, like syntax highlighting, bracket-matching, auto-indentation, box-selection, snippets, and more. And I am able to easily work with multiple different draft versions and test instantly in the terminal.
Any ideas how I can achieve this?
If not, is it maybe possible to directly access the debug console via SSH? Then I would at least be able to use my own terminal client instead of the browser.
LM User
·2 years agoAny reason not to just run them in the collector debug console?