<br><div class="gmail_quote">On Wed, Jun 23, 2010 at 11:34 PM, Hendrik Pahl <span dir="ltr">&lt;<a href="mailto:pahl@team-datentechnik.de">pahl@team-datentechnik.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
...<br>
&gt; That said, it does not soundlike you need to use it for what you&#39;re<br>
&gt; trying to do.<br>
<br>
Okay, i already had the feeling patterndb was not the one really<br>
giving me a solution. I simply need something to bring down the<br>
relevant loglines, since 1.5M lines/month in a logfile/different<br>
logfiles are simply much to much to monitor/read.<br>
<br>
Grepping after &quot;error&quot; or &quot;warning&quot; or &quot;failure&quot; is just one approach,<br>
but never will be the only one, since this might kick out things i<br>
wanna definitely see.<br>
<br>
currently i&#39;m looking at logfiles and size down the amount of lines by<br>
piping the cat output into sed, which kicks out the informational and<br>
overhead lines. this ia an iterative apporach, since i refine the sed<br>
expression time to time.<br>
<br>
How are others managing this issue?<br>
<div><div></div><div class="h5"><br><br></div></div></blockquote><div><br></div><div>Also, aside from the essay I just wrote :), take a look at <a href="http://crunchtools.com/software/petit/">http://crunchtools.com/software/petit/</a> . It should be very useful for any manual log parsing.</div>
<div> </div></div>-- <br>Lance Laursen<br>Demonware Systems Engineer<br>