OpenTelemetry Logs

Logs record something that happened at a specific point in time within an application. This page describes how to configure the logging support in OpenTelemetry.

Learn more about logs in the OpenTelemetry documentation.

Enabling/Disabling Logs

Support for OpenTelemetry Logs is enabled by default. You can disable it via configuration properties.

arconia:
  otel:
    logs:
      enabled: false

Configuration Properties

You can configure the support for OpenTelemetry Logs via configuration properties.

Log Limits

Constraints for the data captured by log records.

Table 1. Log Limits Configuration Properties
Property	Default	Description
`arconia.otel.logs.log-limits.max-attribute-value-length`	-	The maximum length of an attribute value.
`arconia.otel.logs.log-limits.max-number-of-attributes`	`128`	The maximum number of attributes that can be attached to a log record.

Log Record Processor

Configuration for the batch log record processor.

Table 2. Log Record Processor Configuration Properties
Property	Default	Description
`arconia.otel.logs.processor.export-timeout`	`30s`	The maximum allowed time to export log records.
`arconia.otel.logs.processor.max-export-batch-size`	`512`	The maximum number of log records to export in a single batch.
`arconia.otel.logs.processor.max-queue-size`	`2048`	The maximum number of log records that can be queued before batching.
`arconia.otel.logs.processor.metrics`	`false`	Whether to generate metrics for the log record processor.
`arconia.otel.logs.processor.schedule-delay`	`1s`	The interval between two consecutive exports.

OpenTelemetry Environment Variables

Arconia supports the OpenTelemetry Environment Variable Specification, so you can configure the support for OpenTelemetry Logs using environment variables as well.

This support is especially useful during deployment, where you can use the same set of standard environment variables to configure OpenTelemetry Logs across different languages and frameworks.

OpenTelemetry Java System Properties

Arconia supports the OpenTelemetry Java System Properties in alignment with the OpenTelemetry Java SDK Autoconfigure module. So you can configure the support for OpenTelemetry Logs using system properties as well.

This support is especially useful if you’re migrating from the OpenTelemetry-own Spring Boot Starter to Arconia OpenTelemetry, and you want to minimize the changes in your configuration. Check our migration guide for more information.

When possible, we recommend using the Arconia-specific properties instead of the OpenTelemetry Java system properties since they offer a more consistent configuration experience familiar to Spring Boot users.

Programmatic Configuration

You can further customize the auto-configured SdkLoggerProvider instance via the SdkLoggerProviderBuilderCustomizer API.

@FunctionalInterface
public interface SdkLoggerProviderBuilderCustomizer {

    void customize(SdkLoggerProviderBuilder builder);

}

Disabling the Auto-Configuration

The auto-configuration provided by Arconia for OpenTelemetry Logs is enabled by default, but you can disable it as explained in the Enabling/Disabling Logs section.

If you define a custom SdkLoggerProvider bean, the auto-configuration will back off, and your custom bean will be used instead.

@Configuration(proxyBeanMethods = false)
public class MyLoggingConfiguration {

  @Bean
  public SdkLoggerProvider myLoggerProvider() {
    ...
  }

}

You can also disable the auto-configuration entirely by excluding the io.arconia.opentelemetry.autoconfigure.sdk.logs.OpenTelemetryLoggingAutoConfiguration class from the Spring Boot auto-configuration:

spring:
  autoconfigure:
    exclude:
      - io.arconia.opentelemetry.autoconfigure.sdk.logs.OpenTelemetryLoggingAutoConfiguration

Exporting Logs

By default, logs are enabled and exported via OTLP, but you can change the type of exporter. If you set the exporter type to none, the corresponding signal will be disabled from exporting.

Table 3. General Logs Exporter Configuration Properties
Property	Default	Description
`arconia.otel.logs.exporter.type`	`otlp`	The type of OpenTelemetry exporter to use for logs. Options: `console`, `otlp`, `none`.

For more information on exporting logs to the console, refer to Console Exporter.

OTLP

When logs are exported via OTLP (default behavior), you can configure the following properties.

If a value is not provided specifically for logs, the value configured for the general OTLP export is used, if available. See OTLP.

Table 4. OTLP Logs Exporter Configuration Properties
Property	Default	Description
`arconia.otel.logs.exporter.otlp.compression`	`gzip`	Compression type to use for OTLP requests. Options: `none`, `gzip`.
`arconia.otel.logs.exporter.otlp.connect-timeout`	`10s`	The maximum waiting time for the exporter to establish a connection to the endpoint.
`arconia.otel.logs.exporter.otlp.endpoint`	`http://localhost:4317` (gPRC) or `http://localhost:4318/v1/logs` (HTTP)	The endpoint to which telemetry data will be sent.
`arconia.otel.logs.exporter.otlp.headers`	-	Additional headers to include in each request to the endpoint.
`arconia.otel.logs.exporter.otlp.metrics`	`false`	Whether to generate metrics for the exporter itself.
`arconia.otel.logs.exporter.otlp.protocol`	`http-protobuf`	Transport protocol to use for OTLP requests. Options: `grpc`, `http-protobuf`.
`arconia.otel.logs.exporter.otlp.timeout`	`10s`	The maximum waiting time for the exporter to send each telemetry batch.

The default OTLP exporter uses HTTP/Protobuf. If you’d like to use gRPC, refer to OTLP gRPC.

Logback Appender Bridge

Java applications typically configure logging via SLF4J and use one of the popular implementations such as Logback or Log4J2. The Arconia OpenTelemetry Spring Boot Starter provides a bridge that allows you to convert log events generated by Logback to OpenTelemetry Logs and export them via OTLP.

Enabling/Disabling the Bridge

The bridge logic is provided by the OpenTelemetry Java Instrumentation for Logback Appender and can be disabled selectively via configuration properties.

arconia:
  otel:
    instrumentation:
      logback-appender:
        enabled: false

Note: Refer to the Instrumentation section for more information on how Arconia integrates the OpenTelemetry Java Instrumentation.

Configuration Properties

The Logback Appender Bridge can be configured via configuration properties.

Table 5. Logback Appender Bridge Configuration Properties
Property	Default	Description
`arconia.otel.instrumentation.logback-appender.capture-arguments`	`false`	Enable the capture of Logback logger arguments.
`arconia.otel.instrumentation.logback-appender.capture-code-attributes`	`false`	Enable the capture of source code attributes. Note that capturing source code attributes at logging sites might add a performance overhead.
`arconia.otel.instrumentation.logback-appender.capture-experimental-attributes`	`false`	Enable the capture of experimental log attributes `thread.name` and `thread.id`.
`arconia.otel.instrumentation.logback-appender.capture-key-value-pair-attributes`	`false`	Enable the capture of Logback key value pairs as attributes.
`arconia.otel.instrumentation.logback-appender.capture-logger-context`	`false`	Enable the capture of Logback logger context properties as attributes.
`arconia.otel.instrumentation.logback-appender.capture-logstash-attributes`	`false`	Enable the capture of Logstash attributes, added to logs via `Markers.append()`, `Markers.appendEntries()`, `Markers.appendArray()` and `Markers.appendRaw()` methods.
`arconia.otel.instrumentation.logback-appender.capture-marker-attribute`	`false`	Enable the capture of Logback markers as attributes.
`arconia.otel.instrumentation.logback-appender.capture-mdc-attributes`	``	Comma separated list of MDC attributes to capture. Use the wildcard character `*` to capture all attributes.
`arconia.otel.instrumentation.logback-appender.num-logs-captured-before-otel-install`	`1000`	Log telemetry is emitted after the initialization of the OpenTelemetry Logback appender with an OpenTelemetry object. This setting allows you to modify the size of the cache used to replay the first logs. `thread.id` attribute is not captured.