Skip to main content
The pages in this section show you how to instrument your application with the OpenTelemetry SDK to send logs and traces to Bronto over OTLP/HTTP. Logs are bridged from your existing logging framework — no log statement rewrites needed. Traces are added by configuring a tracer provider alongside the log provider.

​
Choose your language

Python

Python

.NET

.NET

Java

Java

Kotlin

Kotlin

Node.js / JavaScript

Node.js

Go

Go

Ruby

Ruby

PHP

PHP

Erlang / Elixir

Erlang / Elixir

Rust

Rust

C++

C++

Swift

Swift

​
How OTel logging works

OpenTelemetry provides a Log Bridge API. You attach an OTel handler or appender to your existing logging framework — Logback, Python’s logging, ILogger, Winston, and so on. Every log record your application emits passes through the bridge, which enriches it with structured metadata and forwards it to the OTel exporter. Nothing in your application code changes. logger.info(), log.warn(), console.log() — all of these keep working exactly as before.

​
What the bridge adds

Here is the same log event before and after the bridge: 
Payment failed for user 123
The trace_id and span_id were injected automatically because this log was emitted inside a traced request. The service.name and service.namespace were set once at application startup and are now attached to every log record — no per-statement boilerplate.

​
Why it’s worth adopting

Automatic trace correlation When a log is emitted inside a traced request, the active trace_id and span_id are injected automatically — no manual MDC propagation or context threading needed. In Bronto, trace_id is a queryable field. Click it to jump from a log line directly to the corresponding trace. Structured by default Every OTel log record follows a defined schema: timestamp, severity, body, attributes, resource, and instrumentation_scope. Not “structured if you remembered to configure JSON output” — structured unconditionally, in a format Bronto understands natively. Service identity is automatic service.name and service.namespace are Resource attributes — set once at SDK initialisation, then attached to every log record that process emits. You do not add them to individual log statements. In Bronto, they map directly to Dataset and Collection with no extra configuration. Semantic conventions OTel defines standard attribute names across all languages: http.request.method, exception.type, db.system, user.id, and hundreds more. When all your services use the same attribute names, your Bronto queries work identically regardless of which language or framework emitted the log. One pipeline for logs, traces, and metrics Logs, traces, and metrics all flow through the same OTel SDK and exporter. One endpoint URL, one API key, one exporter configuration. Adding traces later (Phase 2) means extending existing setup — not wiring a new pipeline. Vendor portability OTLP is an open standard. Switching your observability backend requires changing one endpoint URL, not rewriting instrumentation. Zero code churn Adoption is a configuration change, not a refactor. Existing log statements are untouched.

​
How OTel concepts map to Bronto

OTel conceptBronto conceptHow it’s set
service.nameDatasetResource attribute at SDK init
service.namespaceCollectionResource attribute at SDK init
trace_id / span_idQueryable fieldsAutomatic when tracing is active
severityLog levelMapped from OTel SeverityNumber
attributesSearchable fieldsAny key/value on the log record
deployment.environmentSearchable fieldResource attribute at SDK init
No Bronto-specific SDK attributes are needed. Standard OTel Resource attributes are sufficient.

​
Endpoints

RegionLogsTraces
EUhttps://ingestion.eu.bronto.io/v1/logshttps://ingestion.eu.bronto.io/v1/traces
UShttps://ingestion.us.bronto.io/v1/logshttps://ingestion.us.bronto.io/v1/traces
All requests require the header x-bronto-api-key: <YOUR_API_KEY>. See API Keys for how to create one.

​
Two ways to get data into Bronto

Your application exports to a local OTel Collector process, which batches, filters, and forwards to Bronto. The Collector can enrich attributes, route signals to multiple destinations, and apply sampling rules before data leaves your infrastructure. Best for: multi-service environments, existing Collector infrastructure, or pipelines that need transformation or fan-out before ingestion.
See Connect Open Telemetry to Bronto for Collector setup.

​
Direct export

The OTel SDK inside your application exports logs and traces directly to Bronto over OTLP/HTTP. No additional components required. Best for: new projects, simple architectures, or teams that want the least possible operational overhead.