I have configured several filebeat log inputs with multiline patterns and it works. Next I change the input type to filestream, while following the documentation. However, when starting the beat it fails with this error message:
2021-11-30T10:44:40.888+0100 ERROR instance/beat.go:989 Exiting: Failed to start crawler: creating input reloader failed: error while parsing multiline parser config: unknown matcher type: accessing '0.parsers.0.multiline' accessing '0' (source:'/etc/filebeat/inputs.d/logs.dockerhost.yml')
The relevant configuration is this:
parsers: - multiline: type: pattern # Collects multi-line exceptions - lines that do not match the pattern which comes after a line that matches the pattern pattern: '^([0-9]{4}-[0-9]{2}-[0-9]{2})T[0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3}\s\b(ERROR|SEVERE)' negate: false match: before timeout: 10s max_lines: 50
Best regards
Flemming
type or paste code here
I have reviewed the configuration several time and reread the documentation, but the result is the same. The input type filesstream configures with parsers type pattern does not work despite the filebeat documentation.
I have also looked in the filebeat.yml reference. It does not documents the parsers type pattern.
Next, I kept the input type filestream, but configured the multiline patterns. There several filestream inputs with different multiline patters in the file under the input.d directory.
This configuration seems to work
`
'multiline.type: pattern
# Collects multi-line exceptions - lines that do not match the pattern which comes after a line that matches the pattern
multiline.pattern: '^([0-9]{4}-[0-9]{2}-[0-9]{2})T[0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3}\s\b(ERROR|SEVERE)'
multiline.negate: false
multiline.match: before
multiline.timeout: 10s
multiline.max_lines: 50
Perhaps there is a bug in either the filestream parsers option or the documentation?
I think that filestream input could have slightly different configuration options than log input. Could you elaborate more on what is the difference you applied on your configuration and and how it is missing from the documentation? Then we can fix it in the docs if needed :).
With this configuration Filebeat throws the error shown in my first post and then stop.
When I change the configuration to the one shown in my second post Filebeat does not throw an error nor stops.
From this I conclude the parsers option with multiline pattern does not work as stated in the documentation. Perhaps I am wrong but then I would like to learn how to configure the parsers option with multiline
This is a me-too on this issue... while attempting to update from a (quite elderly) filebeat config which contained a multiline pattern match on one file:
- type: filestream
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- /home/glassfish/glassfish/domains/domain1/logs/server.log
parsers:
- multiline:
type: pattern
pattern: '^\['
negate: true
match: after
it throws the error:
Exiting: Failed to start crawler: starting input failed: Error while initializing input: error while parsing multiline parser config: unknown matcher type: accessing 'filebeat.inputs.1.parsers.0.multiline' accessing 'filebeat.inputs.1' (source:'filebeat.yml')
As with other people, that's my interpretation of the manual for filebeat multiline handling. Which doesn't work as documented. The only difference? I'm running filebeat version 7.16.2
As with fgjensen, modifying the layout to that given in Manage multiline messages | Filebeat Reference [7.16] | Elastic and filebeat starts up... just a question of checking if the layout does what is expected now! Configuration that does allow startup...
- type: filestream
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- /home/glassfish/glassfish/domains/domain1/logs/server.log
multiline.type: pattern
multiline.pattern: '^\['
multiline.negate: true
multiline.match: after
I have had Filebeat 7.15.0 running on several servers with the filestream input type and the multiline pattern configured as both you and I states. It works well with that configuration.
Hi @fgjensen
I've been struggling with this for days, I had the configuration as type: log on Filebeat 7.15 and I started over with version 7.16.2 and the type: filestream.
The documentation is definitely incomplete. It's an indentation issue.
The config that just two min ago worked for me is:
Thank you for the confirmation that the configuration works as per your example… it saved much heartache in rewriting the multiline clause. Now I’ve just got the ‘fun’ of wading through Puppet’s even less usable documentation to make Puppet deploy the Filebeat 7 compatible configuration file. Bad documentation seems to be quite common!
I realized the multiline configuration was accepted by Filebeat at least Filebeat did not stop. However, it just skipped all mulitilines in an exception.
So I change the configuration as @Ruben_Bracamonte suggests and that kind of works. However, some of my following processors are not working. If I comment out the multiline parsers then all processors work.
This quite annoying. Is there an order, so the processors must be configured before the multiline parser?
I guess I just ran into the issue of processors as mentioned by @fgjensen
My paths depend on kubernetes metadata fields, using filestream and configuring multiline as:
multiline.type: pattern
multiline.pattern: '^[[:space:]]+(at|\.{3})[[:space:]]+\b|^Caused by:|^Message History'
multiline.negate: false
multiline.match: after
The filebeat starts up and then error out as it can't access the log file path, which is:
After encountering the same issue and wasting some hours on it, I managed to debug the issue thanks to the fact that filebeat is opensource.
Basically, the error says "unknown matcher type: ". After ':', the code places the value found for multiline.match. As in my case, this space is blank, which means the parsers in unable to find the value specified in the configuration.
There are 2 workarounds to this:
the one you mentioned where you specifically type multiline.match
indent all entries under the multiline statements (and this is actually where the documentation is wrong). Instead of looking like this:
@Emde not sure what exactly is wrong with filestream implementation, but when I'm trying to give multiline.(type/pattern/negate/match) OR as per your suggestion:
Hello together,
I was struggeling with multiline on 7.16, too. My "old" 7.8 filebeat worked well with input "type: log". I nearly tried ALL possibilities I can imagine, but without success.
After just finding this discussion, I immediately tried out the proposals (indenting).
Now I did not get any filebeat starting problems, but multiline is also not working with "parsers".
I "accidentally" put in my "old" config with input "type: logs" again and the "old multiline standard" configuration ... and it works, but only that! ALL other suggestions did NOT work with filebeat 7.16 ...
After at lot of work on this I have Filebeat 7.15.0 configured with 12 different, pretty complex input filestreams. Most of the inputs are also configured with a multiline parser.
The 12 logs in this application are not configured in a similar manner. This adds of course complexity to the inputs. It was also awkward to collect test input from the many logs to cover all the different outcomes.
To sum up: the second workaround from @Emde made my day(s). Besides that I had very good help from these 3 tools:
Great tools, which saved me a lot of tedious testing time. It would be nice, if the Go Playground supports all Filebeat multiline configuration settings. I hope the maintainer reads this!
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.