Re: [Simple-evcorr-users] More table like display of stats
On 12/05/2012 05:17 AM, John P. Rouillard wrote:
Currently the output of a state dump (generated with a kill -USR1)
looks like:
Rule 1 at line 31 (Clear EVENT_PROCESSED) has matched 6431597 events
Rule 2 at line 51 (Skip all processing for slapd) has matched 14126179 events
Rule 3 at line 72 (Dispatch firewall accept lines) has matched 483828 events
Rule 4 at line 95 (Dispatch firewall rule lines) has matched 167890 events
Rule 5 at line 115 (jump to timestamp ruleset) has matched 113237 events
Rule 6 at line 134 (jump to pdu ruleset) has matched 2 events
Rule 7 at line 150 (Do normal processing) has matched 7538605 events
I often find myself comparing counts, or summing counts etc. and I am
wondering if other people would also find this format better:
Rule 1 at line 31 matched 6431597 events (Clear EVENT_PROCESSED)
Rule 2 at line 51 matched 14126179 events (Skip all processing for slapd)
Rule 3 at line 72 matched 483828 events (Dispatch firewall accept lines)
Rule 4 at line 95 matched 167890 events (Dispatch firewall rule lines)
Rule 5 at line 115 matched 113237 events (jump to timestamp ruleset)
Rule 6 at line 134 matched2 events (jump to pdu ruleset)
Rule 7 at line 150 matched 7538605 events (Do normal processing)
With this layout it is easier to see that rule 2 is hit the most and
rule 6 the least. Plus I can use awk/perl to pull field 7 and sum
them. This will take a little extra processing due to the right
aligned matched events count, but I don't think this processing would
be excessively burdensome.
Thoughts?
Currently I've changed the code and have two versions.
For the first version the output is looking like this:
Rule 1 at line 1 has matched 0 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 0 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Nevertheless, for making the matched and events strings aligned
across all rows, an extra preliminary loop over the ruleset would be
required, which would establish the maximum length of the line number
and match counter. This extra loop is included in the second version:
Rule 1 at line 1 has matched 30 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 30 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Which one would you prefer? The second one is easier to grasp for a
human eye, but some extra CPU time has to be spent.
kind regards,
risto
--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
Re: [Simple-evcorr-users] More table like display of stats
In message 50c06562.8030...@seb.ee,
Risto Vaarandi writes:
On 12/05/2012 05:17 AM, John P. Rouillard wrote:
Currently the output of a state dump (generated with a kill -USR1)
looks like:
Rule 1 at line 31 (Clear EVENT_PROCESSED) has matched 6431597 events
Rule 2 at line 51 (Skip all processing for slapd) has matched 14126179 events
Rule 3 at line 72 (Dispatch firewall accept lines) has matched 483828 events
Rule 4 at line 95 (Dispatch firewall rule lines) has matched 167890 events
[...]
I often find myself comparing counts, or summing counts etc. and I am
wondering if other people would also find this format better:
Rule 1 at line 31 matched 6431597 events (Clear EVENT_PROCESSED)
Rule 2 at line 51 matched 14126179 events (Skip all processing for slapd)
Rule 3 at line 72 matched 483828 events (Dispatch firewall accept lines)
[...]
With this layout it is easier to see that rule 2 is hit the most and
rule 6 the least. Plus I can use awk/perl to pull field 7 and sum
them. This will take a little extra processing due to the right
aligned matched events count, but I don't think this processing would
be excessively burdensome.
Currently I've changed the code and have two versions.
For the first version the output is looking like this:
Rule 1 at line 1 has matched 0 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 0 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Nevertheless, for making the matched and events strings aligned
across all rows, an extra preliminary loop over the ruleset would be
required, which would establish the maximum length of the line number
and match counter. This extra loop is included in the second version:
Rule 1 at line 1 has matched 30 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 30 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Which one would you prefer? The second one is easier to grasp for a
human eye, but some extra CPU time has to be spent.
I think I prefer the second. More like a table and easier to scan
(ignoring the line wrap I assume was added by the mailer). To cut
down on processing time, would it be worthwhile to:
Cache the max line number (and max rule number) for the rule set
when the ruleset is read in. That way the processing is done at
load time not while you are up and running (yes I am assuming
dynamic reloads will be fewer than status dumps).
Perhaps some similar cache could be done for the match counter to
record the maximum number of hits. But I don't like this as much
as it adds processing steps to the main event processing loop.
Also, to get more info on a line I wonder if the at and has are
required. Is:
Rule 1 line 1 matched 30 events (ssh event)
as readable? (maybe Rule 1, line...).
--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
Re: [Simple-evcorr-users] More table like display of stats
On Thu, 6 Dec 2012, Risto Vaarandi wrote:
Currently I've changed the code and have two versions.
For the first version the output is looking like this:
Rule 1 at line 1 has matched 0 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 0 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Nevertheless, for making the matched and events strings aligned
across all rows, an extra preliminary loop over the ruleset would be
required, which would establish the maximum length of the line number
and match counter. This extra loop is included in the second version:
Rule 1 at line 1 has matched 30 events (ssh event)
Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
Rule 3 at line 18 has matched 30 events ($:{SSH2:time}: SSH login event
for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
Which one would you prefer? The second one is easier to grasp for a
human eye, but some extra CPU time has to be spent.
The first is easier to generate and to parse, but it's not that much harder. I
think the human readability of the second is worth the cost.
David Lang
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
Re: [Simple-evcorr-users] More table like display of stats
I Agree. -Joe On Wed, Dec 5, 2012 at 11:47 AM, Boyles, Gary P gary.p.boy...@intel.com wrote: John, I would say that the 2nd format is most definitely easier to read. Gary Boyles -Original Message- From: John P. Rouillard [mailto:rou...@cs.umb.edu] Sent: Tuesday, December 04, 2012 7:17 PM To: simple-evcorr-users@lists.sourceforge.net Subject: [Simple-evcorr-users] More table like display of stats Currently the output of a state dump (generated with a kill -USR1) looks like: Rule 1 at line 31 (Clear EVENT_PROCESSED) has matched 6431597 events Rule 2 at line 51 (Skip all processing for slapd) has matched 14126179 events Rule 3 at line 72 (Dispatch firewall accept lines) has matched 483828 events Rule 4 at line 95 (Dispatch firewall rule lines) has matched 167890 events Rule 5 at line 115 (jump to timestamp ruleset) has matched 113237 events Rule 6 at line 134 (jump to pdu ruleset) has matched 2 events Rule 7 at line 150 (Do normal processing) has matched 7538605 events I often find myself comparing counts, or summing counts etc. and I am wondering if other people would also find this format better: Rule 1 at line 31 matched 6431597 events (Clear EVENT_PROCESSED) Rule 2 at line 51 matched 14126179 events (Skip all processing for slapd) Rule 3 at line 72 matched 483828 events (Dispatch firewall accept lines) Rule 4 at line 95 matched 167890 events (Dispatch firewall rule lines) Rule 5 at line 115 matched 113237 events (jump to timestamp ruleset) Rule 6 at line 134 matched2 events (jump to pdu ruleset) Rule 7 at line 150 matched 7538605 events (Do normal processing) With this layout it is easier to see that rule 2 is hit the most and rule 6 the least. Plus I can use awk/perl to pull field 7 and sum them. This will take a little extra processing due to the right aligned matched events count, but I don't think this processing would be excessively burdensome. Thoughts? -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
Re: [Simple-evcorr-users] More table like display of stats
easier to read, easier to parse, win-win. David Lang On Wed, 5 Dec 2012, Boyles, Gary P wrote: John, I would say that the 2nd format is most definitely easier to read. Gary Boyles -Original Message- From: John P. Rouillard [mailto:rou...@cs.umb.edu] Sent: Tuesday, December 04, 2012 7:17 PM To: simple-evcorr-users@lists.sourceforge.net Subject: [Simple-evcorr-users] More table like display of stats Currently the output of a state dump (generated with a kill -USR1) looks like: Rule 1 at line 31 (Clear EVENT_PROCESSED) has matched 6431597 events Rule 2 at line 51 (Skip all processing for slapd) has matched 14126179 events Rule 3 at line 72 (Dispatch firewall accept lines) has matched 483828 events Rule 4 at line 95 (Dispatch firewall rule lines) has matched 167890 events Rule 5 at line 115 (jump to timestamp ruleset) has matched 113237 events Rule 6 at line 134 (jump to pdu ruleset) has matched 2 events Rule 7 at line 150 (Do normal processing) has matched 7538605 events I often find myself comparing counts, or summing counts etc. and I am wondering if other people would also find this format better: Rule 1 at line 31 matched 6431597 events (Clear EVENT_PROCESSED) Rule 2 at line 51 matched 14126179 events (Skip all processing for slapd) Rule 3 at line 72 matched 483828 events (Dispatch firewall accept lines) Rule 4 at line 95 matched 167890 events (Dispatch firewall rule lines) Rule 5 at line 115 matched 113237 events (jump to timestamp ruleset) Rule 6 at line 134 matched2 events (jump to pdu ruleset) Rule 7 at line 150 matched 7538605 events (Do normal processing) With this layout it is easier to see that rule 2 is hit the most and rule 6 the least. Plus I can use awk/perl to pull field 7 and sum them. This will take a little extra processing due to the right aligned matched events count, but I don't think this processing would be excessively burdensome. Thoughts? -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
