I saw his followup and he described the problem I mentioned
below. Which reminded me I never sent this.
In message <871a4abc8d257540b1e95a5661ef785d01a40...@email.exchange.electric.ne
t>,
"Reynold McGuire" writes:
>Here is the log sample that I am trying to capture
>
>----------------------------------------
>Timestamp: 6/16/2008 4:23:51 AM
>Message: linkedTableName = |bcp_ACCOUNTNAME_2722149_20080616042256 as S|
>Thread Name: T_0001
>Extended Properties:
>----------------------------------------
Let's call this message 1.
>.... other stuff here...
Unrelated stuff I assume.
>-----------------------------------------------------------------------
>06/16/2008 04:25:31
>Type : System.Net.WebException, System, Version=1.0.5000.0,
>Culture=neutral, PublicKeyToken=b77e5d561934f089
>Message : The operation has timed-out.
>Source : System.Web.Services
>Help link :
>Status : Timeout
>... more stuff ....
And we call this message 2.
Does the more stuff for message 2 include something like:
bcp_ACCOUNTNAME_2722149_20080616042256
or
T_0001
The reason I ask is that you have a pair of messages with nothing
linking them other than one occurs after the other in time.
Since the first message occurs often what happens if you have:
>Message: linkedTableName = |bcp_ACCOUNTNAME_2722149_20080616042256 as S|
>Thread Name: T_0001
followed by
>Message: linkedTableName = |bcp_ACCOUNTNAME_1_20080616042256 as S|
>Thread Name: T_0001
followed by message 2. Which message 1 instance corresponds to message
2?
>SEC Rule
>type=pair
>ptype=RegExp
>pattern=^Message\:\s+(\S+)\s=\s\|(bcp)\_(\w+)\_(\d+)\_(\d+)\sas\sS\s\|
>desc=ACCOUNT: $3 :: Job: $4
>action=logonly
>type=Single
>ptype=RegExp6
>pattern=Type\s\:\s(System\.Net\.WebException)(.*)\nMessage\s\:\s(.*)\nSo
>urce\s\:\s(.*)\nHelp\slink\s\:\s(.*)\nStatus\s\:\s(.*)
>desc=JOB FAILED: $1 $6
>action=logonly
>
>
>The 'RegExp6' worked great... now what I really need is to be able to
>report on both events.
Note that this will leave a bunch of partial rule triggers
pending. Everytime message 1 comes through with a different account or
job ($3, $4) you will set up a correlation rule looking for message
2. The rule that sees pattern 2 may not have been triggered by the
pattern 1 that matches the pattern 2.
That is given varients A, B and C of message 1:
message 1 A arrives
message 1 B arrives
message 1 C arrives
message 2 arrives
may trigger pattern2 for the correlation started by A, B or C. If
message 2 is really intended to match message 1 B, then there are
issues.
If you have info from the A, B, and C versions that is unique, then:
message 1 A arrives
message 1 B arrives
message 1 C arrives
message 2 B arrives
will match only the correlation operation stated by message 2 A.
>The first pattern will happen repeatedly, the second pattern only
>appears if there is an error.
Is there something that matches message 1 in the case where there is
not an error?
If there is a message 3 that indicates that everything
is ok and message 2 can't be generated for a message 1, then you have:
pair rule for message1 and message 2
if this triggers reset the instance of the message below
pair rule for message 1 and message 3
if this triggers use reset to rest the instance of the rule above
Kind of a pain.
>So I want SEC to watch for the 1st pattern, and if the second pattern is
>found, output the mux of the two...
>
>Something like "ACCOUNT: $3 :: Job: $4 JOB FAILED: $1 $6"
>
>I am pretty sure it can be done w/ contexts, but I have never been able
>to get them to work correctly.
I would ditch the pair rule entirely and set up:
single rule that matches event 1 and extracts something from message
1 that indicates the corresponding message 2
single rule that matches message 2 and extracts the unique info that
should be present. checks to see if the context is created (by prior
rule) and if so fires.
single rule that matches a message 3, and deletes the context.
So lets say we have the three messages:
1 starting with ID 1
2 failed on ID 1
3 OK id 1
Only one of 2 or 3 will happen. So we have:
type=single
desc = match message 1
ptype = regexp
pattern = starting with ID (\d+)
action = create message_chain_$1; # make a unique context
add message_chain_$1 $0 # add the triggering message to it
type=single
desc = match message 2
ptype = regexp
pattern = failed on ID (\d+)
context = message_chain_$1
action = add message_chain_$1 $0; # add the failed triggering message to it
report message_chain_$1 mailx -s "failure chain $1" admin; # alert
delete message_chain_$1 # cleanup
type=single
desc = match message 3
ptype = regexp
pattern = OK id (\d+)
context = message_chain_$1
action = delete message_chain_$1 # end the correlation and clean up
now in the sequence
starting with ID 1
starting with ID 2
failed on ID 2
starting with ID 3
OK id 1
failed on ID 3
you will get two failure emails (on 2 and 3) and have no contexts
remaining open.
Note I just sketched this togther so the syntax may be wrong and is
probably incomplete. But hopefully it will lead you down a working
path.
If you don't have something unique (played by the ID in these
messages), and all you can do is say that a type 2 event must occur
within 10 seconds of a type 1 even, and there will never be more than
1 type one event within 10 seconds, change the context statement in
the first rule so that it times out after 10 seconds.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
