Thank you Kevin. It's all good now! [cid:[email protected]] My performance concerns were from a previous thread on this list w where you helped breakdown a poorly designed rule I built for monitoring AD Security logs. Since then, I have operated under a general rule of thumb that wildcard/regex is 'bad' if the rule evaluates every event. Now that I know about Condition Detection, I really like matching on stupid simple criteria and only then attempting more complex logic.
Thanks again! I feel like I say this a lot, but your Twitter and blogs continue to help me tremendously. From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Holman Sent: Wednesday, March 15, 2017 11:38 AM To: [email protected] Subject: [msmom] RE: Event Rule with Multiple Sources: ATTENTION: This email came from an external source. DO NOT open attachments or click on links from unknown senders or unexpected emails. The definition of a rule: * One or more data source * Zero or one condition detection * One or more write actions So no - you cannot combine multiple condition detections together in a rule.... But you CAN add a bunch of expressions in a dingle condition detection like you have. Your issue is this: <Expression> <ValueExpression> <XPathQuery>EventDescription</XPathQuery> <Operator>MatchesWildcard</Operator> <Pattern>*SQLReportingEngine*</Pattern> </ValueExpression> </Expression> MatchesWildcard is not a simpleexpression - your XML is invalid. It would need to be something like this: <Expression> <And> <Expression> <RegExExpression> <ValueExpression> <XPathQuery Type="String">PublisherName</XPathQuery> </ValueExpression> <Operator>MatchesWildcard</Operator> <Pattern>Report Server (PROD_RPT*)</Pattern> </RegExExpression> </Expression> <Expression> <RegExExpression> <ValueExpression> <XPathQuery Type="String">EventDescription</XPathQuery> </ValueExpression> <Operator>MatchesWildcard</Operator> <Pattern>*SQLReportingEngine*</Pattern> </RegExExpression> </Expression> </And> </Expression> See this guide for ExpressionTypes and their respective operators and syntax: https://matthewlong.wordpress.com/2012/07/03/the-scom-unsung-hero-using-the-system-expressionfilter-module/ That said - while using a simple datasource, and adding a condition detection MIGHT be more efficient - don't go too crazy...... this efficiency becomes more critical whenever you have a massive number of events hitting the event log, such as when using Security event monitoring for the Security event logs. Most servers don't log THAT much stuff to their application event log that this becomes a huge problem. Great work though. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Wednesday, March 15, 2017 12:59 PM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [msmom] Event Rule with Multiple Sources: I'm attempting to create a rule that raises an alert based on the following criteria: Log Name Application Event ID 1 Event Level 2 Event Source (Match on any of these sources): * Report Server (PROD_RPT1) * Report Server (PROD_RPT2) * Report Server (PROD_RPT3) * Report Server (PROD_RPT4) Event Description "[Unique Job ID] SQLReportEngine::GetOutputStream(): Render format 'IMAGE' is not supported" >From past help provided here I understand using wildcard or regex on event >descriptions can be a performance killer. To mitigate that, I have been >reading about condition detections using expression filters. My plan is to use >Basic Event Detection's Event Provider type to first match solely on Event ID >and Event Level. >From there I'm not sure the best next step(s). There are multiple Event >Sources with the pattern "Report Server (PROD_RPT#)" [# will be 1, 2, 3, or 4]. >From a performance perspective, is it okay to use the 'MatchesWildcard' >operator on the Event Source and the Event Description in the same >ExpressionFilter? Or can you have multiple condition detections to further >filter the data being processed? Meaning, should the rule first look at Event >Source, then pass that condition down to the Event Description filter? Would >it matter at that point, or is the performance negligible? This is my first time looking at condition detections, so I appreciate any help. I'm attaching the framework of the rule (sanitized). I apologize if the syntax is incorrect, as I'm working my way through this as a first-timer. Thank you. Confidentiality Notice: This is a transmission from Montage Health. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
