Re: Doppler/Firehose - Multiline Log Entry

Jim CF Campbell

That strategy is going to be hard to sell. Diego's Executor takes the log
lines out of Garden and drops them into dropsonde messages. I doubt they'll
think it's a good idea to implement substitution in that processing. You
can certainly ask Eric - he's very aware of the underlying problem.

After that point, the Loggregator system does it's best to touch messages
as little as possible, and to improve performance and reliability, we have
thinking about the future that will lower the amount of touching ever
further. The next place that log message processing can be done is either
in a nozzle, or the injester of a log aggregator.

I'd vote for those downstream places - a single configuration and
algorithm instead of distributed across runner VMs.

On Tue, Apr 12, 2016 at 2:15 PM, Mike Youngstrom <youngm(a)> wrote:

I was thinking whoever demarcates and submits the original event to
loggregator. dea_logging_agent and the equivalent in Deigo. Doing it at
that point could provide a bit more flexibility. I know this isn't
necessarily the loggregator team's code but I think loggregator team buy
off would be important for those projects to accept such a PR.

Unless you can think of a better place to make that transformation within
the loggregator processing chain?


On Tue, Apr 12, 2016 at 2:02 PM, Jim CF Campbell <jcampbell(a)>

what exactly do you mean by "event creation time"?

On Tue, Apr 12, 2016 at 1:57 PM, Mike Youngstrom <youngm(a)>

Before I submit the CLI issue let me ask one more question.

Would it be better to replace the newline token with /n at event
creation time instead of asking the cli, splunk, anyone listening on the
firehose, etc. to do so?

The obvious downside is this would probably need to be a global
configuration. However, I know my organization wouldn't have a problem
swapping /u2028 with /n for a deployment. The feature would obviously be
off by default.



On Tue, Apr 12, 2016 at 11:24 AM, Mike Youngstrom <youngm(a)>

Sounds good. I'll submit an issue to start the discussion. I imagine
the first question Dies will ask though is if you would support something
like that. :)


On Tue, Apr 12, 2016 at 11:12 AM, Jim CF Campbell <jcampbell(a)
cf logs
is actually maintained by the CLI team under Dies
<>. You can talk to
them. I'll certainly support you by helping explain the need. I'd think we
want a general solution (token in ENV for instance).

On Tue, Apr 12, 2016 at 11:02 AM, Mike Youngstrom <youngm(a)>


If I submitted a CLI PR to change the cf logs command to substitute
/u2028 with /n could the loggregator team get behind that?


On Tue, Apr 12, 2016 at 10:20 AM, Jim CF Campbell <
jcampbell(a)> wrote:


When you get a bit more desperate ;-) here is a nozzle plug in
<> for the CLI. It's
attaches to the firehose to display everything, but would be easy to modify
to just look at a single app, and sub out the magic token for newlines.


On Tue, Apr 12, 2016 at 9:56 AM, Mike Youngstrom <youngm(a)>

Hi David,

The problem for me is that I'm searching for a solution that can
works for development (though less of a priority cause you can switch
config between dev and cf) and for viewing logs via "cf logs" in addition
to a log aggregator. I had hoped that /u2028 would work for viewing logs
via "cf logs" but it doesn't in bash. I'd need to write a plugin or
something for cf logs and train all my users to use it. Certainly possible
but I'm not that desperate yet. :)


On Tue, Apr 12, 2016 at 5:58 AM, David Laing <david(a)>

FWIW, the technique is to have your logging solution (eg, logback,
log4j) log a token (eg, \u2028) other than \n to denote line
breaks in your stack traces; and then have your log aggregation software
replace that token with a \n again when processing the log messages.

If \u2028 doesn't work in your environment; use something else;

On Mon, 11 Apr 2016 at 21:12 Mike Youngstrom <youngm(a)>

Finally got around to testing this. Preliminary testing show
that "\u2028" doesn't function as a new line character in bash
and causes eclipse console to wig out. I don't think "\u2028"
is a viable long term solution. Hope you make progress on a metric format
available to an app in a container. I too would like a tracker link to
such a feature if there is one.


On Mon, Mar 14, 2016 at 2:28 PM, Mike Youngstrom <
youngm(a)> wrote:

Hi Jim,

So, to be clear what we're basically doing is using unicode
newline character to fool loggregator (which is looking for \n) into
thinking that it isn't a new log event right? Does \u2028 work as a new
line character when tailing logs in the CLI? Anyone tried this unicode new
line character in various consoles? IDE, xterm, etc? I'm wondering if
developers will need to have different config for development.


On Mon, Mar 14, 2016 at 12:17 PM, Jim CF Campbell <
jcampbell(a)> wrote:

Hi Mike and Alex,

Two things - for Java, we are working toward defining an
enhanced metric format that will support transport of Multi Lines.

The second is this workaround that David Laing suggested for
Logstash. Think you could use it for Splunk?

With the Java Logback library you can do this by adding
"%replace(%xException){'\n','\u2028'}%nopex" to your logging config[1] ,
and then use the following logstash conf.[2]
Replace the unicode newline character \u2028 with \n, which
Kibana will display as a new line.

mutate {

gsub => [ "[@message]", '\u2028', "

^^^ Seems that passing a string with an actual newline in it is
the only way to make gsub work


to replace the token with a regular newline again so it
displays "properly" in Kibana.



On Mon, Mar 14, 2016 at 11:11 AM, Mike Youngstrom <
youngm(a)> wrote:

I'll let the Loggregator team respond formally. But, in my
conversations with the Loggregator team I think we're basically stuck not
sure what the right thing to do is on the client side. How does the client
trigger in loggregator that this is a multi line log message or what is the
right way for loggregator to detect that the client is trying to send a
multi line log message? Any ideas?


On Mon, Mar 14, 2016 at 10:25 AM, Aliaksandr Prysmakou <
prysmakou(a)> wrote:

Hi guys,
Are there any updates about "Multiline Log Entry" issue? How
correctly deal with stacktraces?
Links to the tracker to read?
Alex Prysmakou / Altoros
Tel: (617) 841-2121 ext. 5161 | Toll free: 855-ALTOROS
Skype: aliaksandr.prysmakou | |

Jim Campbell | Product Manager | Cloud Foundry | |

Jim Campbell | Product Manager | Cloud Foundry | |

Jim Campbell | Product Manager | Cloud Foundry | |

Jim Campbell | Product Manager | Cloud Foundry | |
Jim Campbell | Product Manager | Cloud Foundry | | 303.618.0963

Join { to automatically receive all group messages.