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 <ralph.go...@dslextreme.com>
wrote:

>
>
> > On Jun 18, 2021, at 10:40 AM, Matt Sicker <boa...@gmail.com> 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
>
>
>

Reply via email to