CODEWITHSUNDEEP
regexexceptionmultilinelogstashgrok
tester
tester

Reputation: 3987

Logstash configuration missing last exception of exception log

I use logstash to parse exception logs which get send over network via TCP. As the exception log is multiline I use a multiline filter to parse the data. Unfortunately the last exception log being send is not recognized as logstash does not know where it ends (due to the multiline pattern). Is it even possible to recognize where it ends? The end of an exception can be anything (how to regex then?). Or is it possible to know somehow because the TCP stream ended which means the exception has also reached its end?

Here is my logstash configuration file:

input { 
    tcp {
        port => 1337
        type => "exception"
    } 
}
filter {
    if [type] == "exception" {
        multiline {
            pattern => "%{TIMESTAMP_ISO8601}"
            negate => true
            what => previous
        }
        grok {
            match => ["message", "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:log_level} \(%{INT:log_level_code}\): exception '%{DATA:exception_name}' with message '%{DATA:exception_message}' in %{PATH:path} Stack trace: %{GREEDYDATA:stack_trace}"]
            remove_field => ["log_level", "log_level_code", "host"]
        }
        date {
            match => ["timestamp", "ISO8601"]
        }  
    }
}
output {
    elasticsearch { host => localhost }
    stdout {}
}

Here is a sample PHP script which sends exceptions via TCP:

<?php
$content = "2014-11-25T20:11:55+00:00 ERR (3):
exception 'Exception' with message 'some error' in /private/var/www/index.php:88
Stack trace:
#0 {main}
2014-11-25T20:11:56+00:00 ERR (3):
exception 'Exception' with message 'some error' in /private/var/www/index.php:88
Stack trace:
#0 {main}";

$fp = stream_socket_client("tcp://127.0.0.1:1337", $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br />\n";
} else {
    fwrite($fp, $content);
    fclose($fp);
}

Running this example will only recognize the first exception as an event log. The second exception is recognized as soon as the next timestamp arrives which will not in this case, as the stream of data ends.

Upvotes: 0

Views: 846

Answers (2)

Corey Cole
Corey Cole

Reputation: 987

1.5.0 (currently available as an RC) corrects this issue, but only with the multiline filter. Original JIRA bug, closed GitHub issue.

I was running into the same issue and happened upon the Jira/GitHub discussion. It took a few tries, but I did get it working. I will say to be patient when waiting for the flush event to occur -- it waits a few seconds.

Upvotes: 0

Alain Collins
Alain Collins

Reputation: 16362

The multiline codec has no support to flush out the last event. The multiline filter has an enable_flush param, but it's listed as not for production use.

Sadly, the only solution is to have more exceptions :)

Upvotes: 1

Related Questions