I need to alert for 20 consecutive failed logon attempts within a 30 minute time period

If the SQL logs are ingested into LM Logs and the failed SQL login attempts are logged, then yes, you can set a log alert to notify when 20 failed SQL login attempts are seen in the log files within a 30 minute period.

I wonder if LM Logs and the aggregate functions might be able to accomplish this. Worth reaching out to your CSM to see if you can get a technical resource from LM to investigate whether or not this would be possible. LM Logs and APM are big pushes right now, so if they have a real use case they can use their shiny new features to solve, they might be motivated to help.

This allows easy cloning and quick set of the data being pulled… then you can set normal thresholds and heads/tails (consecutive polls to raise/lower the alert).

Instead of cloining the DS, have the eventLog, eventID and timeSpan set as instance level properties on a multi-instance datasource. To create the instances with their ILPs, create a property that lists them all out:

Logon Failure|Security|4625|5,Something Else|Security|2346|10,Instance Display Name|eventLog|eventId|timeSpan

Then your discovery script would look like this:

try{
    hostProps.get("logSpanInstances").tokenize(",").each{instance ->
        wildvalue = instance.replaceAll(/\|/,'_').replaceAll(" ",'_')
        i = instance.tokenize("|")
        println("${wildvalue}##${i[0]}######eventLog=${i[1]}&eventID${i[2]}&timeSpan=${i[3]}")
    }
    return 0
} catch (Exception e){println(e);return 1}

With the above example, this would create the following instances:

Note this discovery script replaces the pipe and space characters in the instance to create the wildvalue.

LogicMonitor has not shown any intent to add this sort of alert logic -- I know I have requested it for many years and seen nothing on the roadmap.  It would be wonderful in many places, like "high CPU for N of the last M minutes", etc. 

For events in particular, there is nothing if you use the normal event matcher.  If you use Groovy, you might be able to leverage Collector Script Caching to track the events seen and only generate an event from the Groovy code if the your conditions match.  I believe the cache is bound to specific collectors (not distributed), so if you use load-balanced collector groups I imagine it will end badly.

We use these all the time.  Using $events.count as the return value:

Get-WinEvent        `
  -ErrorAction Stop `
  -FilterHashtable @{
      LogName   = $eventLog
      ID        = $eventID
      StartTime = (get-date).AddMinutes(-1*$timeSpan)
  }

(note the use of backticks for line continuation)

At the top of the script is this:

$eventLog  = 'Security'
$eventID   = 4625
$timeSpan  = 5

This allows easy cloning and quick set of the data being pulled… then you can set normal thresholds and heads/tails (consecutive polls to raise/lower the alert).