bring back longer polling intervals (e.g. 12 hrs, 24 hrs)

i would like that for a few types as well.

I have some new devices that only have cellular access for monitoring.   I want to keep pings often, but Poll everything else very infrequently, even delaying  future automatics discovery's, could use a Property Slow connection.

There are some timing issues with the collectors automatically restarting that made the longer polling intervals intermittently reliable.

For items that we really just want to run once per day, or even once per day or month, we've used PowerShell datasources where the first check is to get the system date and time. Then if it matches X time of day, then process an IF loop in PowerShell.

For instance, we want to check something once per day in the 3AM hour, our PowerShell would say the equivalent of:
     If (time equals 3AM) {do this here}

Obviously this won't work on built in datasources, but since those are all pretty much performance based, you want that data at a regular interval. For those custom things, like asking a server what version of service pack that it's on, our PowerShell time logic works perfectly.

This would a great feature to add - not sure why it was removed.

I want to check how many updates are waiting to be installed on a given server but really only need to do that once or twice a day.  Running the script opens a Windows Update session on the monitored host and causes the CPU to spike for up to a few minutes.

For what it's worth, the longer durations were removed due to the collector recycling at the eight hour mark. Longer intervals were found to be unreliable, as they had to survive collector reboots.

We would still like to see 2, 4, 6, and 8 hour collection intervals, but as I noted above, we've gotten around it in all of our script by checking the time on the device and executing it at a given hour of the day.

That makes sense, Thanh - It's a reasonable work around but what do you pass to the collector for all of the intervals when you script doesn't do something but the collector polls the host?  I guess you could get the last known good value via the LM api.  Do you just pass nothing or 0?  That makes graphing not useful, but I guess for reporting that would work ok.  A 6 or 8 hour interval would be fine, too.

Great question Matt

Specific to our use cases, we actually use LogicMonitor to run PowerShell scripts against our monitored systems. We are a small, vertical market MSP (about 400 customers, of which we wholly manage about 25% of them.) We set things that you'd normally push with group policies, such as Windows update configuration, folder redirection and the like. However, we push those settings directly into the registry on the monitored device. I've also used it to install and remove software. I also do temp file cleanup and various file system maintenance.

In all of these situations, I don't really have a need or want to run these processes more than once daily. I usually run it in the early AM, so at the top of my PowerShell script, I get the system time, then the entire rest of the script is contained in an if block that only runs if it matches the hour of the day that satisfies the if block. If it doesn't satisfy the if block, the script still exits gracefully with an exit code of 0.

I am not sure that I have fully answered your question though. I've posted an example of my script below for reference. I comment code quite a bit so that anyone behind me can hopefully decode my mess. That logic sort of goes along with using long variable names that are named for their exact function.

#gets the server name from LogicMonitor
$Server = $args[0]

#gets the current system date and time from the collector
$CurrentSystemDateTime = Get-Date

#if the current system time matches the hour in the if condition below, run the associated block of code
If ($CurrentSystemDateTime.Hour -eq '4')
{
    Get-ChildItem "\\$server\C$\Windows\Temp\*" -Force -Recurse | Remove-Item -Force -Recurse -Confirm:$false #deletes all contents of C:\Windows\Temp on the monitored host, but leaves the temp folder in place
}
 

For use cases other than performance metrics, it may be worth considering a PropertySource or a ConfigSource (if you have LM Config).

A PropertySource will run once per day and set/update one or more device properties, which could for example list or count the outstanding updates at that time. There is no graphing or alerting directly, although a DataSource could then pull the property value in, e.g. if your PropertySource produced a count of outstanding updates. In that way, the "hard work" - i.e. the script to find the updates - runs only daily, while the more frequently run DataSource does very little / causes very little load. Textual property values can be pulled into Device Inventory Reports.

For direct alerting, LM Config permits a ConfigSource to be run every 1, 4, or 24 hours, and you could have it generate alerts on any change, e.g. when the list of outstanding updates changes. Again, no graphing, but in many use cases a graph is not as vital as having the textual data.

With an hourly config collection you could also script in the time limitations, e.g. only collect a config if the hour is 3am.

Those are great ideas, Antony - I'll look into LM Config and Property Sources, hadn't found a use for them until now.  I ended up using Thanh's suggestion and checking the current system time before executing the part of the script that does the work only at a specific time each morning.  I think it would be a great feature to add to LogicMonitor though - the ability to schedule tasks against a wide range of hosts at a specific time or only during one hour of the night, for example.

Longer polling intervals were added in v102. Now 4 hours, 6, hours, 8 hours, 12 hours, 24 hours (1 day) are options.  Version 26.400 collector or newer is required. In case you didn't already know, there's also a capability to specify a polling interval for a device or group by setting a property (help doc)