For the records, JsonTemplateLayout also quotes all escape characters,
including CR and LF characters, in every(!) string value. For instance, the
following test succeeds:
String eventTemplate = writeJson(asMap(
"epochSecs", asMap(
"$resolver", "exception",
"field", "stackTrace",
"stackTrace", asMap(
"stringified", true))));
JsonTemplateLayout layout = JsonTemplateLayout
.newBuilder()
.setConfiguration(CONFIGURATION)
.setEventTemplate(eventTemplate)
.setEventDelimiter("")
.build();
LogEvent logEvent = Log4jLogEvent
.newBuilder()
.setLoggerName(LOGGER_NAME)
.setThrown(new RuntimeException())
.build();
String serializedLogEvent = layout.toSerializable(logEvent);
assertThat(serializedLogEvent).doesNotContain("\n");
Hence, newlines in stack traces or whatever input string there is to be
encoded to JSON, are not a problem for JsonTemplateLayout.
On Fri, Jun 18, 2021 at 7:49 PM Ralph Goers <[email protected]>
wrote:
>
>
> > On Jun 18, 2021, at 10:40 AM, Matt Sicker <[email protected]> wrote:
> >
> > A couple other common log collection setups I've come across over time:
> >
> > * Logging to stdout/stderr in a standard format, then use a log
> > collection API from your orchestration engine (common in the
> > Kubernetes world to avoid logging to a file).
>
> NOT recommended for use with Log4j. See
> http://logging.apache.org/log4j/2.x/manual/cloud.html.
>
> > * Logging to a log file as normal, but running a log forwarding agent
> > alongside (e.g., Splunk, Logstash).
> > * Logging to syslog (typically more important for auditing and
> > security related logs)
> >
> > For the log format itself, JSON template layouts work great here for
> > customizing how much info you need in your logs. It also makes it much
> > easier to create log indices in various log searching products. Which
> > particular one hasn't been as important in my experience as trying to
> > stay consistent.
> >
>
> I happen to like GELF as it neatly solves the problem of Java Exceptions
> having newlines in them. Other formats that use the newline to delimit the
> end of the message require weird rules to be set up in Logstash to glue
> the various lines back together again. Invariably some message will
> violate
> the assumptions the rules are based on.
>
> Ralph
>
>
>
