Skip to main content
This page covers instrumenting a Kotlin application with the OpenTelemetry Java SDK to send logs and traces to Bronto over OTLP/HTTP via a local OTel Collector. Both signals are co-equal: logs are bridged via the Logback appender — no log statement changes needed — and traces are emitted via a tracer provider.
If you don’t have a Collector and want to export directly from your application to Bronto, see Direct export to Bronto at the bottom of this page.

Prerequisites

Install dependencies

Use the OpenTelemetry BOM to manage all SDK versions in one place and avoid version conflicts.

Configure the log bridge

Add the OpenTelemetryAppender to your logback.xml. Every log record Logback handles will be forwarded to the OTel pipeline.
logback.xml

Configure the OTLP exporter

Create an OpenTelemetrySdk instance and call OpenTelemetryAppender.install() to wire the Logback appender to the SDK.
OtelConfig.kt
Call configureOtelLogging() once at application startup, before the first log statement.

Set resource attributes

Resource attributes are attached to every log record exported from this process. Two attributes drive how Bronto organises incoming logs: These are set via Resource.create() in the SDK configuration above.

Complete example

main.kt
Existing SLF4J / Logback log statements require no changes.

Verify delivery

After running your application, check both signals in Bronto:
  • Logs: open the Search page and filter by the dataset name you set in service.name — your log records should appear within a few seconds.
  • Traces: open the Explore Traces page and filter by the same service.name — your spans should appear within a few seconds.
If no logs appear, check:
  • The OTel Collector is running and reachable at the configured endpoint.
  • The Collector’s pipeline includes a logs pipeline with an otlp receiver and the Bronto exporter — see Connect Open Telemetry to Bronto.
  • OpenTelemetryAppender.install() is called before the first log statement.
  • BatchLogRecordProcessor exports on a background thread — for short-lived programs, add a shutdown call: loggerProvider.shutdown().

Traces

The OpenTelemetry Java Agent works for Kotlin applications too — attach it with -javaagent:opentelemetry-javaagent.jar to auto-instrument Spring Boot, Hibernate, gRPC, Kafka, and many more frameworks with no code changes.

Configure the tracer provider

No additional packages are needed — opentelemetry-sdk and opentelemetry-exporter-otlp already include tracing support. Create a SdkTracerProvider and combine it with the SdkLoggerProvider in the same OpenTelemetrySdk builder:
OtelConfig.kt
The shared resource ensures service.name and service.namespace are identical on both logs and traces.

Creating spans

Any Logback statement inside an active span will automatically have trace_id and span_id attached.

GenAI semantic conventions

If your application calls an LLM, OpenTelemetry defines GenAI semantic conventions. Kotlin runs on the JVM, so the same OpenTelemetry Java Agent covers Kotlin applications — no separate package. See Java: GenAI semantic conventions for current auto-instrumentation coverage, content-capture configuration, and the manual-span pattern.
This page was verified on July 17, 2026. GenAI libraries and semantic conventions are evolving rapidly, so package configuration and emitted attributes can change between releases. Keep your instrumentation current and verify the fields emitted by the version you deploy.
See LLM Observability for the full recommended gen_ai.* attribute set and how to search and aggregate GenAI fields in Bronto.

Direct export to Bronto

If you are not using an OTel Collector, export directly to Bronto by replacing the exporter configurations with the Bronto OTLP endpoints and your API key:
See API Keys for how to create a key with ingestion permissions. No other changes to the rest of the setup are required.