Proposal of Outputting Unified Logging to TCP socket

[Koichi Sakata]

Hello,

I would like to propose outputting unified logging (UL) to the TCP 
socket. I know that this has been discussed before [1]. However, 
circumstances have changed. Asynchronous logging was added to UL. If we 
output logs to TCP with async mode, we will be able to solve some issues 
raised in the past discussion (e.g. lag of log() calls). So I will take 
up this subject again.

This feature is useful, especially in the container environment. Take 
Kubernetes for example, there are many containers. It is recommended 
that containers send logs to standard output, but the mixture of Java 
application logs and UL logs in stdout is not handy to parse or search 
in a log aggregator like Elasticsearch. I believe that it's beneficial 
to deal with each type of log individually.

When we have files of UL logs, we have another issue. That is where to 
persist those files. As you know, we lose logs when pods are removed. I 
would rather not use volumes like Persistent Volume because of the cost 
of using volumes and the effort of managing files. When using the 
volume, we need to determine the file size and the volume size and put 
many log files of containers in it.

UL via TCP socket answers these issues. In the Kubernetes example, we 
use a log forwarder like Fluent Bit, Filebeat or something as a 
DaemonSet. It gets UL logs from the socket, gets application logs from 
stdout, and sends each log to corresponding log aggregators. As a 
result, we don't have UL log files and volumes to persist them anymore. 
This is premised on asynchronous logging. So the lag will not be a 
problem, I think.

For these reasons, I would like to propose outputting UL logs to TCP 
inputs. It seems to be unnecessary for traditional java applications, 
but it's of great use for applications in container environments. This 
makes it easier to build and operate applications on Kubernetes. There 
is also a bonus that this is os independent.

I will create a prototype of this proposal if it is worth trying.

By the way, there is a network stream class that is used to send node 
information to Ideal Graph Visualizer via socket. I'm not sure whether 
we can divert it or not for this new feature.

Best Regards,
Koichi Sakata

[1] 
https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2020-November/043221.html