This is a proposal how to solve issue#676: Separate otlp config for logs and traces.
Motivation: in Kubernetes (while traces are sent efficiently through the push model) applications typically write their logs to stdout/stderr so that they are available for log collectors (they are stored in files on k8s nodes). This way, even in case of application failure, logs will be available.
A new send-logs option is added to the otlp-logger configuration. This option allows the user to control whether logs are sent via gRPC using the OTLP protocol or through the default logger from the logging component.
By default, send-logs is set to true. In this case, the OTLP logger will behave as before, sending both logs and traces using gRPC through the OTLP protocol.
If send-logs is set to false, the OTLP logger will try to use the 'default' logger from the logging component for logs.
Documentation for the new send-logs option and handling of exceptions for both cases were added as well.
This is a proposal how to solve issue#676: Separate otlp config for logs and traces.
Motivation: in Kubernetes (while traces are sent efficiently through the push model) applications typically write their logs to
stdout/stderrso that they are available for log collectors (they are stored in files on k8s nodes). This way, even in case of application failure, logs will be available.A new
send-logsoption is added to the otlp-logger configuration. This option allows the user to control whether logs are sent via gRPC using the OTLP protocol or through the default logger from the logging component.By default,
send-logsis set totrue. In this case, the OTLP logger will behave as before, sending both logs and traces using gRPC through the OTLP protocol.If
send-logsis set tofalse, the OTLP logger will try to use the 'default' logger from the logging component for logs.Documentation for the new
send-logsoption and handling of exceptions for both cases were added as well.