Max number of Strings per Rule?

That is an interesting question ... I will have to ask the team if there is any limit or a number that is reasonable to keep it under.

I should have asked... Do you already have a rule with quite a lot of them that isn't working or is the question more theoretical in nature?

I have a rule with about 75 different strings in them, and the website freezes when trying to load it, but eventually will load everything.  I also have a support case open for this but after 2 days, no one has touched it yet.  One rule i need to create has about 399 entries to look for, and in creating one that needed approx 200, i broke it out in chunks of 50 when 70+ seemed unmanageable. 

Can you send me the ticket number so I can check on the progress of the case?

Can you be a bit more specific about the nature of your rule?   If there are 400 variations on the log message is that really all tracking back to a single type of issue or is this lots of different situations?

Lots of different situations. These are not 400 traps for just one or two issues, but just about anything that vendor's device could spit out that we want our engineers to acknowledge and take a look at.  Between the 20-something vendors i have, there's just about 2,000 strings i need to look for and have in rules.  Some of these are better suited for Orion's methods of alerting (for example, not relying on SNMP Traps for hardware health issues when Orion can do that) but for now i'm more worried about making rules that are too "large".

Ticket 00439036.  So far they just requested more time to look into it.

You might have better luck going the opposite route and creating rules to drop any events types that are not actionable, that way instead of sifting through a million events looking for useful data you only keep useful events in the db and immediately route everything else to the garbage?  Log Manager is not exactly dialed in to operating as a full on a SIEM.  It might be a 6 of one, half a dozen of the other kind of situation though.

I know in most sql queries having a long list of OR conditions against strings tends to be really hard on system performance, and you've already run into the limitations of the GUI itself to display the rules.  I know in the regular alert builder I had some cases before where I used code to build alert conditions that had like dozens of lines of logic in them and they also were really slow to display as well.

Thanks. I'll keep an eye on that ticket.

Are you using multiple "Contains" entries or are you using the "Matches Regex" method? The Regex path might make the web UI less likely to bog down.