Having attempted to debug issues where application logs get dropped, I
would welcome an option to have TCP used. In the current system, you never
know if logs are dropped because the datagram never reached the target or
because it got hung up in some component along the way.

I would think that the concerns about back pressure from TCP could be
dealt with in the clients using mechanisms similar to what you already have
with the syslog sinks.

On Fri, Sep 18, 2015 at 5:22 PM, Erik Jasiak <mjasiak(a)pivotal.io> wrote:

Greetings again CF community!

As part of the new dropsonde point proposal[1], the team would have to
implement some tough sizing choices related to UDP packets, and the
likelihood of larger packets getting dropped.

Alternatively, we could finally add tcp support for Metron; this has
several pros (among them: much lower chance of lossiness) and cons (among
them: puts a component at risk of failure from backpressure if the system
is sized wrong).

* Would operators be interested in TCP support, even if it means a higher
risk of component failure if the loggregator system and message-producing
component weren't tuned correctly?

* Would you prefer there be an option to choose TCP or UDP at bosh deploy
time? We'd be open to this option, but are more likely to be biased in
supporting only one choice over time.

Thanks again,
Erik Jasiak
PM - Loggregator

[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/765VT4CLXL3F2KCGR4PUO2LHPV73USTB/

--
Matthew Sykes
matthew.sykes(a)gmail.com