Log driver for OpenTelemetry

[mikehaller]

Currently, the available log driver implementations in container-management are json-file and none.

For the integration of OpenTelemetry, it would be great to have a log driver implementation speaking OLTP and sending container logs to an OpenTelemetry Collector endpoint.

[e-grigorov]

• OpenTelemetry will bring a bunch of new dependencies i.e. the daemon size will be affected. As a first step here, we have to evaluate the impact.
• Another issue is that Go implementation has to be checked. It seems that logs are not yet implemented.

[antoniyatrifonova]

The OpenTelemetry specification for the Logs is currently not available in a stable state. Fortunately, after a brief research, we can note that the implementation is in an active state. For now, in OpenTelemety specification, the Logs already have a stable data-model and OTLP support. There is an open and active discussion about the API.

In our opinion, for now, it is better to wait for a stable version before looking for alternative options.

[mikehaller]

even getting the logs as a tcp stream from kanto cm would be helpful.

right now, we have to statically define filenames and watch individual files, which is really cumbersome with random uuids in the filepaths

also, there is no api to get the filename of the logfile. if that would be there, we could at least get the proper filepaths for new containers.

[k-gostev]

@mikehaller Isn't that what we did in #98, or I am getting it wrong?
Basically you can use kanto-cm logs <container-id>/-n <container-name> and it will fetch the logs using gRPC streaming. You don't need to know the file paths to get the logs of a container anymore.

[mikehaller]

kant-cm logs is intended for a human user.

how would you do that on a production system where you do not even want to install a cli tool?

how do you want to monitor 50+ containers? spawning 50 separate cli processes just to get the logs? that sounds like an extreme overhead to me.