Thanks for clarifying, that was not clear to me.
That sounds fine to me, given that it just adds extra information, not
changes existing one.
On Wed, May 6, 2020 at 9:06 AM Till Rohrmann wrote:
> Just for clarifications and as Yang already pointed out: The discussion
> here is about also
Just for clarifications and as Yang already pointed out: The discussion
here is about also creating the log, out and err files as well as keeping
writing to STDOUT and STDERR.
Hence, there should be no regression for K8s users. The main problem, as
Chesnay pointed out, could be the increased disk
Hi Thomas Weise,
I am not sure why this change will break the existing K8s/container-based
setup.
Since it will output the logs to stdout and log files at the same time, you
could still
use the `kubectl logs` to view the logs. And log collection could just work
as before.
What we could benefit
The downside of change to the default behavior is the breakage of existing
k8s or other container-based production setups.
Logs that are emitted to stdout are visible through kubectl logs and
infrastructure is setup for log collection.
Thanks,
Thomas
On Tue, May 5, 2020 at 6:31 AM Arvid Heise
>From my previous experience with K8s, I'd assume that the cluster itself
already has some ELK attached to it and all stdout/err is collected
automatically.
So if you want to also add logs, I'd make that configurable and I'm torn
what the default should be as both make sense.
However, thinking a
@Patrick could you chime in?
We should at least understand the original motivation before simply
changing the way it works.
On Tue, May 5, 2020 at 2:49 PM Stephan Ewen wrote:
> I think Patrick originally introduced the foreground mode, and I believe
> it had indeed something to do with
I think Patrick originally introduced the foreground mode, and I believe it
had indeed something to do with container use and logging.
IIRC the default assumption in docker and Kubernetes is that the logs come
on stdout (or stderr) so after "principle of least astonishment" the idea
was to give a
I like this idea because it should improve the experience (and reduce
confusion) for folks having their first flink experience via one of the
docker playgrounds. Right now it gives the impression that something is
broken out-of-the-box.
Regards,
David
On Mon, May 4, 2020 at 6:01 PM Till Rohrmann
Hi everyone,
thanks for starting this discussion Chesnay.
I think it would be nice if we also displayed the logs when starting the
process in the foreground.
The repercussions could be mitigated if the default logger configurations
would contain file rolling with a max log file size.
@Yang I
Thanks for Chesnay starting this discussion.
In FLINK-17166 implementation[1], we are trying to use "tee" instead of
introducing the stream redirection(redirect the out/err to files). However,
a side effect is that the logging will be duplicated both in .log and .out
files.
Then it may consume
Currently, processes started in the foreground (like in the case of
Docker) output all logging/stdout directly to the console, without
creating any logging files.
The downside of this approach, as outlined in FLIP-111, is that the
WebUI is not able to display the logs since it relies on these
11 matches
Mail list logo
