-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Log4j 2 example #222
base: main
Are you sure you want to change the base?
Conversation
- Switch from deprecated JSON Layout to its successor JSON Template Layout - Use variable names in capitals (the recommended convention by Log4j) - Explain configuration using AsciiDoc callouts
@jsvd, is there anything else I can provide further to get this merged and/or speed things up? |
docs/index.asciidoc
Outdated
<1> Using Socket Appender to write logs to a TCP socket – make sure to *change the `host` attribute* to match your setup | ||
<2> Using https://logging.apache.org/log4j/2.x/manual/json-template-layout.html[JSON Template Layout] to encode log events in JSON | ||
<3> Using the ECS (Elastic Common Schema) layout bundled with JSON Template Layout | ||
<4> Configuring that written log events should be terminated with a null (i.e., `\0`) character |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is surprising to me, and results in errors.
From the JsonTemplateLayout
docs, nullEventDelimiterEnabled=true
will cause a null to be appended after each eventDelimiter
.
When the TCP input is configured with codec => json
or codec => json_lines
, it uses the json_lines
codec, which splits the input on newline. This means that the post-eventDelimiter
null byte will be the first byte of each subsequent sequence passed to the codec, which results in json parse failures.
For example, if I start Logstash minimally:
bin/logstash -e 'input { tcp { codec => json port => 9887 } }'
And then send it json that is both newline and null delimited:
echo $'{"this":"that"}\n\0{"foo":"bar"}\n\0' | nc 127.0.0.1 9887
The null bytes cause _jsonparsefailure
s:
{ "@version" => "1", "@timestamp" => 2025-02-18T17:37:51.852917Z, "this" => "that" } { "message" => "\u0000{\"foo\":\"bar\"}", "tags" => [ [0] "_jsonparsefailure" ], "@version" => "1", "@timestamp" => 2025-02-18T17:37:51.855102Z } { "message" => "\u0000", "tags" => [ [0] "_jsonparsefailure" ], "@version" => "1", "@timestamp" => 2025-02-18T17:37:51.855359Z }
These issues do not occur if we do not have the post-eventDelimiter
null byte:
echo $'{"this":"that"}\n{"foo":"bar"}\n' | nc 127.0.0.1 9887
{ "@version" => "1", "@timestamp" => 2025-02-18T17:47:34.570363Z, "this" => "that" } { "@version" => "1", "@timestamp" => 2025-02-18T17:47:34.570605Z, "foo" => "bar" }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right – I've confused it with the GELF Input Plugin, which requires null termination.
As a matter of fact, we have an IT for ELK:
docker-maven-plugin
is used to bootstrap the ELK stack- GELF Layout is configured with a null terminator
- ECS Layout isn't provided any delimiter, hence, falls back to the default, i.e., a newline
Also, in apache/logging-log4j2@fef8af8, fixed our SOA page guiding users on ELK integration.
Removed the mention of null delimiter from this PR in 5116d68.
Co-authored-by: Ry Biesemeyer <[email protected]>
This work is delivered as a part of apache/logging-log4j2#2510.