Prerequisites
- Java 8 or later
- Maven or Gradle
- A running OTel Collector configured to forward logs and traces to Bronto — see Connect Open Telemetry to Bronto
- OpenTelemetry Java SDK documentation
Install dependencies
Using Log4j2 instead of Logback? Replace the appender dependency with
opentelemetry-log4j-appender-2.17 from io.opentelemetry.instrumentation.Configure the log bridge
Add theOpenTelemetryAppender to your logback.xml. Every log record Logback handles will be forwarded to the OTel pipeline.
logback.xml
captureExperimentalAttributes includes thread name and logger name as OTel attributes. captureCodeAttributes includes the source file, class, method, and line number.
Configure the OTLP exporter
Create anOpenTelemetrySdk instance with a SdkLoggerProvider and install it as the global instance. Call OpenTelemetryAppender.install() to wire the Logback appender to the SDK.
OtelConfig.java
OtelConfig.configure() 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.java
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.
- The OTel Collector is running and reachable at the configured endpoint.
- The Collector’s pipeline includes a
logspipeline with anotlpreceiver and the Bronto exporter — see Connect Open Telemetry to Bronto. OpenTelemetryAppender.install()is called before the first log statement.BatchLogRecordProcessorexports on a background thread — for short-lived programs, add a shutdown hook:loggerProvider.shutdown().
Traces
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.java
resource ensures service.name and service.namespace are identical on both logs and traces.
Creating spans
Get a tracer from the global instance and use it to create spans:trace_id and span_id attached.
GenAI semantic conventions
If your application calls an LLM, OpenTelemetry defines GenAI semantic conventions for model, token usage, and prompt/response content.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.
Auto-instrumentation
The OpenTelemetry Java Agent includes GenAI instrumentation for the OpenAI Java client and AWS SDK v2 Bedrock calls — no extra instrumentation dependency is needed. Model calls carrygen_ai.provider.name, gen_ai.request.model, and token-usage attributes instead of only a plain HTTP client span.
GenAI instrumentation coverage in the Java agent is newer and narrower than Python’s — check the agent’s supported libraries list for your provider/framework. If it isn’t covered, use manual spans below.
Experimental: capturing prompt and response content
For the Java agent’s OpenAI and AWS SDK instrumentations, content capture is off by default:Manual spans
Where the agent doesn’t cover your provider or framework, set thegen_ai.* attributes yourself:
gen_ai.input.messages / gen_ai.output.messages, 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.

