Forum Discussion

Lewis_Beard's avatar
7 months ago

Tips or Tweaks for controlling when a daily ConfigSource runs?

I have a config source, that really under the hood is doing some other task, a coding task, and it used to conveniently run every day at 22:47 or something like that, but because of reasons, now it runs at 10:05 every morning. This is some ancient script someone else wrote in python and it runs on a collector. I’ll probably convert it to be groovy, and have it run hourly, but only act when the hour digit on the time is 22 or something wacky.

But short of that, it did have me wonder, are there any tricky ways to change when a daily config source runs? Because from what I can tell, they run at the time they were made, or I guess at the last time the collector went down because of a domain password problem :) *cough*.

I could just try a meaningless edit on the ConfigSource and see if that does it. I dont think bouncing the collector service will do it because on rare occasion the service restarts at a time other than its normal time and that doesnt change CS run times.

Just wondering if anyone has any tips or tricks? I’ll probably just rewrite this to run hourly but act only on a specific hour of the day. But just fishing for ideas.

I really wish we could schedule ConfigSources like we can reports.

Thanks!

  • Definitely try touching/editing the configs at a very specific time(s) throughout the day, then see how that effects the timing of things.  You might be able to really kludge it that way and that gives you band-aid time.  :-)

    I can’t imagine this would be pegged to Collectors boot time since you’d probably see this pin to a specific time no matter what with regular Collector reboots.

  • Anonymous's avatar
    Anonymous
    • I want the daily results shown in the text so that people can make note of when an action happened

    A good reason to think about LM Logs, unless you’re not licensed for it.

    • I got in the (bad?) habit of doing all our platform scripts as config sources, all running against our portal resource object, so habit I suppose.

    I do this too, although I run mine as datasources so that i can output certain script variables as datapoints at the end of the script.

    • I generally want the code to be native groovy or powershell anyway, because in case I get hit by a bus or something, I want someone else coming in to look at the config source to be able to literally see the code there in the LM platform.

    A good reason to request native python support in LM. I can’t believe it’s 2024 and we still don’t have it. I’ve been told in the past that it isn’t done because “it would be hard keeping all the virtual environments and stuff from conflicting.” Seems like a cop out to me.

    Hey LM, how about adding support for every language by adding docker support? Let me specify the docker repo and container, a list of environment variables populated by tokens, and either an embedded script viewable in the UI, let me upload a set of files, or link to a git repo. There’s a docker container for running scripts in just about every language out there. Wanna run a datasource discovery script in Rust? There’s a container for that. Wanna run a specific version of Python with certain libraries already PIP’ed in? There’s a container for that. What if the collectors could run any script in any language and the script could exist natively in the UI just like Powershell or Groovy scripts?

  • We learned recently if you do disable the instance, you still have to wait till past the point when it would normally pull before re-enabling.

  • Anonymous's avatar
    Anonymous

    Just wondering if anyone has any tips or tricks? I’ll probably just rewrite this to run hourly but act only on a specific hour of the day. But just fishing for ideas.

    This is the way. There’s no definitive way of controlling it from LM’s side. You might have luck editing it at a specific time, but a collector going down could undo it.

    I assume you’re doing it as a configsource because you want to save the output of the script as a blob of text, readable from LM? Have you considered containerizing your python script and pushing the logs to LM Logs via the API? 

  • The old-fashioned way to do this would be to run it using cron (wrapped in a job monitor wrapper) You wouldn't have the diff (unless you saved the diff-able output in a file with its own configsource) but it would happen when you want it to. 
    https://www.logicmonitor.com/support/logicmodules/batchjobs/setting-up-batchjob-monitoring/batchjobs

  • I assume you’re doing it as a configsource because you want to save the output of the script as a blob of text, readable from LM? Have you considered containerizing your python script and pushing the logs to LM Logs via the API? 

    My main reasons (probably all bad? :)) would be:

    • I want the daily results shown in the text so that people can make note of when an action happened
    • I am in a weird position where I dont have easy access to any collectors where the python would run. When I “inherited” the “portal admin” dutues all of a sudden, I inherited a bunch of python scripts my predecessor wrote that just run on a windows collector. But I dont really have easy access to that collector, so I ported all of them away from external python (there were only a few). It is super tedious to have to get permission to maintain the code each time. So I wanted it all in-platform for LM.
    • I generally want the code to be native groovy or powershell anyway, because in case I get hit by a bus or something, I want someone else coming in to look at the config source to be able to literally see the code there in the LM platform.
    • I got in the (bad?) habit of doing all our platform scripts as config sources, all running against our portal resource object, so habit I suppose.

    As for LM Logs, I’ve never had need to use them. I think there are some basic log-related functionalities I’ve never needed to use, and I seem to recall that the fancy LM Logs thing is a pay-for feature. Not sure.

  • Oh and for any seeming discrepancies in “inherited a bunch” and “only a few”, the first descriptor was emotional, the second was literal. :) I ported maybe 12 of them off python and over to groovy (they were already configsources someone else wrote using external python). :)