Not transferring Multiline messages

(Gary Keller) #1

It seems my multiline filter in Filebeat is not working I was
looking at the log file for the multiline messages and found that they
were not being transferred to Elastisearch. My config file is

  # List of prospectors to fetch data.
    # Each - is a prospector. Below are the prospector specific configurations
        - /local/gstapps/development/jboss/domain/servers/axeda68dev/log/server.log
        - /local/gstapps/development/jboss/domain/servers/axeda68dev/log/customobjects.log
      input_type: log
      exclude_lines: ["^$"]
        pattern: '^[[:space:]]+|^Caused by:'
        negate: false
        match: after
      close_older: 15m
  ### Elasticsearch as output
    hosts: [""]
    index: "filebeat-jboss-dev"

A sample from the server.log file is, where the message at 15:20 is tranferred but the message at 15:22 is not.

15:20:30,233 ERROR [com.axeda.drm.config.validation.AbstractCacheClusterValidator] (EHCACHE ClusterValidator Thread) Found cache key when it should have been deleted (invalidated) for validatorType=EHCACHE nodeId=''
15:22:47,141 ERROR [] (ESS-Periodic-Reaper-%d thread-1) Error acquiring MBean server connection, username: GEHC, password: gehcManager, jmxUri: service:jmx:rmi:///jndi/rmi://,service:jmx:rmi:///jndi/rmi://,service:jmx:rmi:///jndi/rmi:// Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: jmxrmi,service:jmx:rmi:///jndi/rmi://,service:jmx:rmi:///jndi/rmi://
    at [rt.jar:1.7.0_75]
    at [rt.jar:1.7.0_75]
    at java.util.concurrent.Executors$ [rt.jar:1.7.0_75]
    at java.util.concurrent.FutureTask.runAndReset( [rt.jar:1.7.0_75]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301( [rt.jar:1.7.0_75]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ [rt.jar:1.7.0_75]
    at java.util.concurrent.ThreadPoolExecutor.runWorker( [rt.jar:1.7.0_75]
    at java.util.concurrent.ThreadPoolExecutor$ [rt.jar:1.7.0_75]
    at [rt.jar:1.7.0_75]
Caused by: javax.naming.NameNotFoundException: jmxrmi,service:jmx:rmi:///jndi/rmi://,service:jmx:rmi:///jndi/rmi://
    at com.sun.jndi.rmi.registry.RegistryContext.lookup( [rt.jar:1.7.0_75]
    at com.sun.jndi.toolkit.url.GenericURLContext.lookup( [rt.jar:1.7.0_75]
    at javax.naming.InitialContext.lookup( [rt.jar:1.7.0_75]
    at [rt.jar:1.7.0_75]
    at [rt.jar:1.7.0_75]
    at [rt.jar:1.7.0_75]
    ... 13 more

(Steffen Siering) #2

any message right after the message from 15:22 ? The event is still actively processed by the multiline filter. It can not detect multiline being over without seen the next log line starting with a timestamp. By default multiline filter has a timeout of 5 seconds. That is, latest on timeout or after timeout the event should be pushed.

P.S.: Please format logs and config files with </> button or three back-ticks to make your post more readable.

(Gary Keller) #3


Thanks for the reply and the tip on formatting the messages. Are you suggesting that I increase that value to more than the default of 5 seconds? There were several messages after the 15:22 message that are withing the 5 second time period.

(Steffen Siering) #4

the messages after the multiline one have been send? You have a more complete log for testing?

(Gary Keller) #5


Yes, I have a more complete log for testing. Can you direct me to documentation on how to send the file. When I tried to upload one before it complained about the file type.

(Gary Keller) #6


I have found the problem, but not the solution. The problem is in the line pattern: '^[[:space:]]+|^Caused by:'. When I remove the Caused by: following the pipe, it will add the "\n\tat " lines to the error message and will create a separate entry for the Caused by: entries.

I have tried several different options to add the additional pattern to the string, and even tried two separate pattern entries, but none of my attempts have worked. Any suggestions?

(Gary Keller) #7


I found the option of using Multiline as an array, so I tried that. The configuration I am using is

        pattern: '^[[:space:]]+'
        negate: false
        match: after
        pattern: '^Caused by:'
        negate: false
        match: after

But this is giving me the error of "ERR Stop Harvesting. Unexpected encoding line reader error: unknown matcher type:"

Is this not supported in Filebeat v 1,3?

(Steffen Siering) #8

The multi-pattern-multiline feature is not implemented in any beat. It has been discussed early on, but not being implemented. I think the implementation originally intended would not be usable the way you expect here, though.

The pattern works for me:
But mileage might vary, as I copied logs from your post.

Here is a multiline test by some community member:

The Caused by: should be no problem. I wonder about when/how the next log line after a stack trace is printed. Sometimes buffering in application logger (not writing content to file) can block the multiline matcher.

(Gary Keller) #9


Here is the abbreviated log file that I am using in my local testing along with the yml file.

Gary D Keller
GE Healthcare, consultant

Office: 262-548-2470 (42470)
Cell: 262-497-6264

(Gary Keller) #10


I found my problem in the filebeat config. I was trying to bypass blank log file lines and it was causing it to discard the complete multiline message. I deleted the exclude_lines: ["^$"] statement and am now able to correctly record the multiline message in the elasticsearch index. I found this out by using the -d "*" option while running filebeat with my abbreviated test file.

Will have to experiment with how to bypass blank lines in my testing.

Thanks for all of your help.

(system) #11

This topic was automatically closed after 21 days. New replies are no longer allowed.